Xorg Mailing List 2004 August

From Stuart.Kreitman at Sun.
COM Sun Aug 1 08:49:19 2004

From: Stuart.Kreitman at Sun.COM (Stuart Kreitman)
Date: Sun Aug 1 09:03:18 2004
Subject: [Xorg] Xevie addition to libXext
In-Reply-To: <E1Br12n-0005Nd-6F@evo.keithp.com>
References: <E1Br12n-0005Nd-6F@evo.keithp.com>
Message-ID: <410D10FF.3030306@sun.com>
Keith Packard wrote:
>Around 22 o'clock on Jul 31, Matthieu Herrb wrote:
>
>
>
>>>Added files:
>>> xc/lib/Xext/:
>>> Xevie.c
>>>
>>>
>>This addition requires a minor library revision number increment.
>>
sure, prolly want to establish rule for this in architecture committee
>>
>>
>
>I think it's better to have separate libraries for each extension; can we
>do that in this case? What do other people think?
>
>-keith
>
>
just a packaging issue. I was operating under the impression that Xext
was a general purpose place to put small extensions,
at least it has been for our Solaris work on lib and server side. We
should start a writeup on packaging extensions. Does something
like that already exist?
skk
From carl at personnelware.com Sun Aug 1 10:53:40 2004
From: carl at personnelware.com (Carl Karsten)
Date: Sun Aug 1 10:53:00 2004
Subject: [Xorg] tinderbox lite
Message-ID: <012c01c477f0$7add0ce0$1e01a8c0@cnt496>
Having watched a few tinderboxs for a few days now, I see that they use
considerable resources: cpu, disk access and internet bandwidth.
The bandwidth issue is causing me to take down my boxes during business hours.
The cpu usage prevents me from running on anything but a dedicated box.
The disk access makes me hesitant to recommend others join in.
So if I could get a version that would
A) not whack the tree before each run
B) Throttle the downloads
C) wait for a change to be posted before doing a CVS pull. This one will be a
bit harder to implement - not sure if it is worth the trouble: checking
timestamps on 6400 .c files, and then having make do its thing on 30,000 files
takes a hit even if there isn't anything to do.
Make the process a bit less resource intensive and I can put a few more boxes on
line.
Carl K
http://www.personnelware.com/carl/resume.html
From jonsmirl at yahoo.com Sun Aug 1 11:20:58 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Aug 1 11:21:01 2004
In-Reply-To: <012c01c477f0$7add0ce0$1e01a8c0@cnt496>
Message-ID: <20040801182058.58439.qmail@web14929.mail.yahoo.com>
Could you have a script watch the cvs-commit mailing list?
--- Carl Karsten <carl@personnelware.com> wrote:
> C) wait for a change to be posted before doing a CVS pull. This one
> will be a
> bit harder to implement - not sure if it is worth the trouble:
> checking
> timestamps on 6400 .c files, and then having make do its thing on
> 30,000 files
> takes a hit even if there isn't anything to do.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
From ajax at nwnk.net Sun Aug 1 11:21:32 2004
From: ajax at nwnk.net (Adam Jackson)
Date: Sun Aug 1 11:21:38 2004
References: <012c01c477f0$7add0ce0$1e01a8c0@cnt496>
Message-ID: <200408011421.33610.ajax@nwnk.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 01 August 2004 13:53, Carl Karsten wrote:
> Having watched a few tinderboxs for a few days now, I see that they use
> considerable resources: cpu, disk access and internet bandwidth.
>
> The bandwidth issue is causing me to take down my boxes during business
> hours. The cpu usage prevents me from running on anything but a dedicated
> box. The disk access makes me hesitant to recommend others join in.
>
> So if I could get a version that would
> A) not whack the tree before each run
> B) Throttle the downloads
> C) wait for a change to be posted before doing a CVS pull. This one will
> be a bit harder to implement - not sure if it is worth the trouble:
> checking timestamps on 6400 .c files, and then having make do its thing on
> 30,000 files takes a hit even if there isn't anything to do.
Have you considered running a local CVS repo mirror and having your
tinderclients pull from that?
You could also do commit notifications by watching xorg-commit.
- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBDTSsW4otUKDs0NMRAmlIAJ9tD6FxVzIt57EPKQywHQmJNYRpgACggQTx
2TtPr0lbnqBVsTASWKhXLKs=
=njwO
-----END PGP SIGNATURE-----
From daniel at freedesktop.org Sun Aug 1 11:23:27 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Aug 1 11:23:29 2004
Message-ID: <20040801182327.GA22865@fooishbar.org>
On Sun, Aug 01, 2004 at 12:53:40PM -0500, Carl Karsten wrote:
> C) wait for a change to be posted before doing a CVS pull. This one will be a
> bit harder to implement - not sure if it is worth the trouble: checking
> timestamps on 6400 .c files, and then having make do its thing on 30,000 files
Stuff CVS, just rsync over a working tree; if nothing's changed, don't
run a new build.
--
Daniel Stone <daniel@freedesktop.org>
freedesktop.org: powering your desktop http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/a9298a2c/attach
ment.pgp
From keithp at keithp.com Sun Aug 1 15:53:22 2004
From: keithp at keithp.com (Keith Packard)
Date: Sun Aug 1 15:53:44 2004
In-Reply-To: Your message of "Sun, 01 Aug 2004 08:49:19 PDT."
<410D10FF.3030306@sun.com>
Message-ID: <E1BrPCl-0005pB-JE@evo.keithp.com>
Around 8 o'clock on Aug 1, Stuart Kreitman wrote:
> just a packaging issue. I was operating under the impression that Xext
> was a general purpose place to put small extensions,
Yes, a tradition started before systems generally had shared libaries
though. I think it's a bad plan, although it's probably at least partially
my fault.
> We should start a writeup on packaging extensions. Does something like
> that already exist?
I think the modular tree has a reasonably clear structure for extensions
and I've been following that for the last several I've done:
FooExt/ - headers and specs (no Xlib dependency allowed)
foo.h - constants needed by server, library and apps
fooproto.h - protocol structures need by server and library
foo.pc - pkg-config file
Xfoo/ - C library (including library headers)
Xfoo.h - library header
libXfoo.so - shared library
xfoo.pc - pkg-config file
server/foo - X server implementation
One trick is to make sure foo.h and fooproto.h headers don't depend at all
on Xlib, and to make sure apps needn't use fooproto.h.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040801/1fad15a5/attach
ment.pgp
From roland.mainz at nrubsig.org Sun Aug 1 16:25:28 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Sun Aug 1 16:25:44 2004
Subject: [Xorg] Anyone added a 2min timer recently ?
Message-ID: <410D7BE8.42627B52@nrubsig.org>
Hi!
----
Did anyone checkin something (as part of DMX, XEVI, XFIXES or something
else) recently which uses something like a 2min timer/timeout/etc. (or
changed something on the DPMS or screensaver code) ? I am currently
stuck in https://freedesktop.org/bugzilla/show_bug.cgi?id=964 and don't
exactly understand what may have caused this... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From eta at lclark.edu Sun Aug 1 16:56:46 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sun Aug 1 16:56:49 2004
Message-ID: <1091404606.896.5.camel@leguin>
On Sun, 2004-08-01 at 10:53, Carl Karsten wrote:
> Having watched a few tinderboxs for a few days now, I see that they use
> considerable resources: cpu, disk access and internet bandwidth.
>
> The bandwidth issue is causing me to take down my boxes during business hours.
> The cpu usage prevents me from running on anything but a dedicated box.
> The disk access makes me hesitant to recommend others join in.
>
> So if I could get a version that would
> A) not whack the tree before each run
It might be nice to make Everything whenever possible, though I don't
really like the idea of not starting from a clean tree (build issues
related to files moving in the tree could slip through). Note that
ccache can help reduce build times significantly. If someone had it
working with the Everything target and a periodic World like before,
that'd be great though.
> B) Throttle the downloads
> C) wait for a change to be posted before doing a CVS pull. This one will be a
> bit harder to implement - not sure if it is worth the trouble: checking
> timestamps on 6400 .c files, and then having make do its thing on 30,000 files
I'm not sure how this would work with the tinderbox scripts we have, but
it would be really useful. Also, using cvsup to fetch the entire
repository is highly recommended if you're running more than one
tinderbox.
--
Eric Anholt eta@lclark.edu
http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
From Jim.Gettys at hp.com Sun Aug 1 17:31:31 2004
From: Jim.Gettys at hp.com (Jim Gettys)
Date: Sun Aug 1 18:02:36 2004
In-Reply-To: <E1BrPCl-0005pB-JE@evo.keithp.com>
References: <E1BrPCl-0005pB-JE@evo.keithp.com>
Message-ID: <1091406690.3076.6.camel@localhost.localdomain>
The other problem is that packaging extensions into
a common library is that it means you can't deprecate/withdraw
that extension without breaking applications that use
unrelated extensions.
As history shows (PEX, XIE, to name a few) not all extensions
succeed, and having such unrelated interdependencies are bad
engineering.
And then versioning also becomes interdependent between
libraries, also potentiall causing havoc.
So I'd package them separately.
- Jim
On Sun, 2004-08-01 at 18:53, Keith Packard wrote:
> Around 8 o'clock on Aug 1, Stuart Kreitman wrote:
>
> > just a packaging issue. I was operating under the impression that Xext
> > was a general purpose place to put small extensions,
>
> Yes, a tradition started before systems generally had shared libaries
> though. I think it's a bad plan, although it's probably at least partially
> my fault.
>
> > We should start a writeup on packaging extensions. Does something like
> > that already exist?
>
> I think the modular tree has a reasonably clear structure for extensions
> and I've been following that for the last several I've done:
>
> FooExt/ - headers and specs (no Xlib dependency allowed)
> foo.h - constants needed by server, library and apps
> fooproto.h - protocol structures need by server and library
> foo.pc - pkg-config file
> Xfoo/ - C library (including library headers)
> Xfoo.h - library header
> libXfoo.so - shared library
> xfoo.pc - pkg-config file
> server/foo - X server implementation
>
> One trick is to make sure foo.h and fooproto.h headers don't depend at all
> on Xlib, and to make sure apps needn't use fooproto.h.
>
> -keith
>
>
>
> ______________________________________________________________________
> _______________________________________________
> xorg mailing list
> xorg@freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
From alexdeucher at gmail.com Sun Aug 1 21:45:39 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Sun Aug 1 21:45:41 2004
Subject: [Xorg] Savage DRI DDX to xorg merge
Message-ID: <a728f9f90408012145739c3fb1@mail.gmail.com>
I just finished the preliminary merge. It seems to work ok in limited
testing. for those interested the patch is here:
http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
the code still needs the "develdri" #ifdefs added. I'm not sure
exactly where those need to go off hand. also the savage dri is still
only in mesa.
At this point this can probably wait until after the next release for merging.
Alex
Date: Sun Aug 1 22:42:55 2004
Subject: [Xorg] The continuing misadventures of freetype-cthulhu
Hash: SHA1
This freetype build nonsense is no longer funny. Let's see if I've got this
all correct:
1 - Xorg in CVS requires >=2.1.8 to build, either externally or from our own
copy.
2 - We cannot force users to upgrade to >=2.1.8 because it has known rendering
issues and breaks the build of many other packages (quite the stunning
revelation there).
3 - Users who don't upgrade to >=2.1.8 have slow CJKV core fonts.
4 - (Personal experience here) Users who work around the build breakage by
saying HasFreetype2 NO to use our copy, will get a brand new libfreetype.so
in /usr/X11R6/lib. This libfreetype will cause firefox and others to crash
repeatably. (yes the latest version, and if you really want the 60M cores
from firefox as proof i'll be more than happy to generate one for you.)
5 - Statically linking freetype to X is not an option, for the usual reasons.
Those are facts. Here begins opinion.
If performance fights correctness, correctness wins. Correctness here means
not making huge core dumps out of apps that used to work in 6.7.0, however
slowly. There's no winning choice if we argue based on good citizenship -
forcing the upgrade breaks external packages, but omitting the optimization
that requires 2.1.8 makes core CJKV painfully slow - so any argument down
those lines is invalid.
So the best choice, the one where we best fit the environment the user has
chosen, is the one where we wrap the fix for bug 307 in an appropriate
#if/#else/#endif for the user's freetype version and move on with our lives.
We need this fixed, and soon, it's embarassing.
- - ajax
iD8DBQFBDdRYW4otUKDs0NMRApbDAKDdyJJlhxy4Fj9B83sq2/PLYO6ChwCfT6iN
DlsexKpPdv+oC1iyt2jkx1E=
=ZY3G
From Nicolas.Mailhot at laPoste.net Mon Aug 2 01:51:13 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon Aug 2 02:12:42 2004
Subject: [Xorg] OLS and console rearchitecture: second pass
In-Reply-To: <20040729194618.81879.qmail@web14929.mail.yahoo.com>
References: <20040729194618.81879.qmail@web14929.mail.yahoo.com>
Message-ID: <1091436674.26238.7.camel@ulysse.olympe.o2t>
On jeu, 2004-07-29 at 12:46 -0700, Jon Smirl wrote:
> 11) OOPs will cause an immediate screen clear and painting of the
> system console including the OOPs data. It is not needed to change the
> video mode.
Very often these days OOPs data is too long to fit on a 80?25 screen.
If the system console could safely use whatever video mode allows to
cram as much data as possible on the screen you'd catch a lot more
problems.
Another problem is screens that blank after a while to save energy and
can not be woken up to display oops data (because the system is toast).
Again if it can safely be done disabling DPMS on oops would help a lot.
Cheers,
--
Nicolas Mailhot
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/3bd83125/attach
ment.pgp
From eich at pdx.freedesktop.org Mon Aug 2 05:02:59 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Aug 2 05:04:31 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has
nomembernamed `find_sbit_image'
In-Reply-To: eta@lclark.edu wrote on Friday, 30 July 2004 at 14:09:08 -0700
References: <16650.43069.354192.53013@xf11.fra.suse.de>
<E1BqeR3-0002sp-42@evo.keithp.com>
<20040730210005.GB25118@fooishbar.org> <410AB7F2.2090802@sun.com>
<1091221747.43156.15.camel@leguin>
Message-ID: <16654.11636.55368.324651@xf11.fra.suse.de>
Eric Anholt writes:
> On Fri, 2004-07-30 at 14:04, Stuart Kreitman wrote:
> > Could someone please give me a trivial way to get past this build error?
> > We have other fires to fight at the moment..
> > skk
>
> Set
>
> #define HasFreetype2 NO
>
> in host.def. This will result in overwriting your distribution's
> freetype2, which may result in other pain.
>
It shouldn't as the code should install in /usr/X11R6/lib not /usr/lib.
Egbert.
From zakki at peppermint.jp Mon Aug 2 06:33:50 2004
From: zakki at peppermint.jp (Kensuke Matsuzaki)
Date: Mon Aug 2 06:34:03 2004
Subject: [Xorg] [PATCH] Japanese ctext conversion bug fix patch
Message-ID: <7jshll4x.wl%zakki@peppermint.jp>
Hi,
Compound Text Encoding say below
> Once a GL or GR set has been defined, all further octets in that range (except
within control sequences and
> extended segments) are interpreted with respect to that character set encoding
, until the GL or GR set is
> redefined. GL and GR sets can be defined independently, they do not have to be
defined in pairs.
But in sjis_cttombs, sjis_ctstowcs, euc_ctstowcs and euc_ctstombs,
once GL or GR set is defined, the other set becomes undefined.
Ctext.patch will fix this. ctext.patch is written Toshio Takabe.
> Note that when actually using a character set encoding as the GR set, you must
force the most significant
> bit (08/00) of each octet to be a one, so that it falls in the range 10/00 to
15/15.
sjis.patch fixs the problem that sjis_mbstocts doesn't set the most
significant bit to be a one. I wrote sjis.patch.
--
Kensuke Matsuzaki
mailto:zakki@peppermint.jp
http://peppermint.jp
-------------- next part --------------
Name: ctext.diff
Type: application/octet-stream
Size: 5089 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/0a936427/ctext-
0001.obj
-------------- next part --------------
Name: sjis.diff
Size: 609 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/0a936427/sjis-0
001.obj
From otaylor at redhat.com Mon Aug 2 07:03:37 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Mon Aug 2 07:05:00 2004
In-Reply-To: <1091406690.3076.6.camel@localhost.localdomain>
References: <E1BrPCl-0005pB-JE@evo.keithp.com>
<1091406690.3076.6.camel@localhost.localdomain>
On Sun, 2004-08-01 at 20:31, Jim Gettys wrote:
> The other problem is that packaging extensions into
> a common library is that it means you can't deprecate/withdraw
> that extension without breaking applications that use
> unrelated extensions.
>
> As history shows (PEX, XIE, to name a few) not all extensions
> succeed, and having such unrelated interdependencies are bad
> engineering.
>
So, say we decide two releases from now that XEVIE was a mistake
and it needs to be withdrawn.
- If we remove libxevie from the packages that we distribute
any app that requires XEVIE will no longer work.
- If we remove the XEVIE symbols from libXext, any app that
requires XEVIE will no longer work.
What's the difference?
> And then versioning also becomes interdependent between
> libraries, also potentiall causing havoc.
If you believe that minor library version numbers have value,
then yes, having separate libraries allows them to be
bumped separately.
I've never seen any evidence that minor library numbers do
any good. Because even in places like Linux that "have" them
they have no representation in the file format. I can link
a program against libxevie.so.1.1 and run it against
libxevie.so.1.0.
If fine-grained tracking of versions and capabilities are
needed then ELF symbol versioning is a much more powerful
tool. (I mean the basic Solaris style grouping symbols into
versions, not the GNU extension that allows multiple versions
of the same symbol.)
And as far as major version numbers go, the rule should be
simple. Don't change them! :-)
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/b2bb2f2b/attach
ment.pgp
Date: Mon Aug 2 07:05:58 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no
membernamed `find_sbit_image'
In-Reply-To: keithp@keithp.com wrote on Friday, 30 July 2004 at 13:44:23 -0700
<E1BqeEp-0002r9-7o@evo.keithp.com>
Keith Packard writes:
>
> Around 21 o'clock on Jul 30, Egbert Eich wrote:
>
> > I remember discussing CVS policies however I don't remember that this
> > has ever been a major issue in these discussions. You may see it as
> > a corollary of what was discussed.
>
> We certainly haven't come up with a completely concrete CVS policy yet.
> It's nice to see minor issues like this one that we can use as examples of
> how such a policy should work. Instead of letting problems fester for a
> week or more, it would be nice to see them addressed promptly and
> decisively so that each user won't have to learn about the 'official
> workaround'.
Agreed.
The polices we have applied were decided in an ad-hoc fashion.
However I would like avoid that people who have tried to adhere to
these policies subsequently don't get the feeling that they
are changing randomly and in favour of certain individuals.
I therefore had preferred if the problem was communicated to Chisato
explaining that the previous policy was flawed - especially since the
solution is so simple.
>
> The problem with 2.1.7 was that it was not ABI compatible with 2.1.6, so
> code compiled against 2.1.6 would run incorrectly against 2.1.7, and code
> compiled against 2.1.7 would not run at all against 2.1.6.
>
> I don't know if this was completely clear during the 6.7.0 discussions
> though; the precise nature of the problem is complicated.
The same problem seems to arise with freetype 2.1.7 vs. freetype 2.1.8.
The versions don't seem to be binary compatible.
>
> > I just don't like to see unequal treatment of groups that are not as vocal
> > here as you and me and thus easily get ignored.
>
> Yes, we need to respect the needs of all of our users and make informed
> decisions about what the software does. That's why we should work hard to
> get this feature into the release for that group of people still stuck with
> core-font based applications.
>
> Getting a patch into the code which supports FreeType 2.1.7 seems like a
> practical and non-discriminatory plan.
>
Right. I bet Chisato would have been happy to do this if we had
asked him right away.
Now he feels like as if we wanted to drop his changes. After all,
this - rather small - change allows us to drop support for a second
truetype font renderer ;-)
Cheers,
Egbert.
Date: Mon Aug 2 07:16:47 2004
In-Reply-To: <E1Br12n-0005Nd-6F@evo.keithp.com>
References: <E1Br12n-0005Nd-6F@evo.keithp.com>
On Sat, 2004-07-31 at 17:05, Keith Packard wrote:
> Around 22 o'clock on Jul 31, Matthieu Herrb wrote:
>
> > > Added files:
> > > xc/lib/Xext/:
> > > Xevie.c
> >
> > This addition requires a minor library revision number increment.
>
> I think it's better to have separate libraries for each extension; can we
> do that in this case? What do other people think?
There are tradeoffs either way. Separate libraries has the (somewhat
small) advantage that dependencies of apps on the new library are more
visible to tools such as RPM. And does help keep maintainership modular.
But anybody considering such a split has to be aware of a fundamental
property of ELF shared libraries: adding symbols does not increase
the per-symbol cost of resolution, adding libraries does.
In rough terms ELF symbol resolution is specified as a linked list of
hash tables.
Two questions:
* Is the code going to be maintained separately? Is it going to have
separate releases? separate security fixes? a different set of
people handling bug reports. If code should be in a different
package, it needs to be in a separate shared library. I'm not
sure that the answer to this should ever be yes for such a small
chunk of code as XEVIE.
* Does the code have different sets of dependencies? If a library
brings in new dependency libraries that's often a good reason
to keep it separate. (E.g., libpangoxft is a separate shared
library from libpango because it pulls in the X libraries.)
If the answer to both is no, then making a separate shared object
seems to have little value.
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/99a888de/attach
ment.pgp
Date: Mon Aug 2 07:18:05 2004
In-Reply-To: <16654.11636.55368.324651@xf11.fra.suse.de>
<20040730210005.GB25118@fooishbar.org>
<410AB7F2.2090802@sun.com> <1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
On Mon, 2004-08-02 at 08:02, Egbert Eich wrote:
> Eric Anholt writes:
> > On Fri, 2004-07-30 at 14:04, Stuart Kreitman wrote:
> > > Could someone please give me a trivial way to get past this build error?
> > > We have other fires to fight at the moment..
> > > skk
> >
> > Set
> >
> > #define HasFreetype2 NO
> >
> > in host.def. This will result in overwriting your distribution's
> > freetype2, which may result in other pain.
> >
>
> It shouldn't as the code should install in /usr/X11R6/lib not /usr/lib.
Please, please, please, I beg you, do *not* encourage people to install
a second libfreetype.so on their system.
It won't overwrite the distribution's version, no. It *will* cause the
person to submit a Pango bug report 6 months from now because configure
tests are running against one libfreetype and Pango is linking against
the other, or because Pango is linking against one libfreetype and
running against the other, or some other weirdness that the user has
no chance at all of being able to debug correctly.
Thanks,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/b601b552/attach
ment.pgp
From daniel at freedesktop.org Mon Aug 2 08:01:14 2004
Date: Mon Aug 2 08:01:16 2004
<20040730210005.GB25118@fooishbar.org>
<16654.11636.55368.324651@xf11.fra.suse.de>
Message-ID: <20040802150114.GD437@fooishbar.org>
On Mon, Aug 02, 2004 at 02:02:59PM +0200, Egbert Eich wrote:
> Eric Anholt writes:
> > On Fri, 2004-07-30 at 14:04, Stuart Kreitman wrote:
> > > Could someone please give me a trivial way to get past this build error?
> > > We have other fires to fight at the moment..
> > > skk
> >
> > Set
> >
> > #define HasFreetype2 NO
> >
> > in host.def. This will result in overwriting your distribution's
> > freetype2, which may result in other pain.
>
> It shouldn't as the code should install in /usr/X11R6/lib not /usr/lib.
... so? It's still three versions.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040803/20786e2a/attach
ment.pgp
From ajax at nwnk.net Mon Aug 2 08:36:26 2004
Date: Mon Aug 2 08:36:33 2004
References: <200408020142.49302.ajax@nwnk.net>
<16654.15754.244056.116043@xf11.fra.suse.de>
Hash: SHA1
On Monday 02 August 2004 09:11, Egbert Eich wrote:
> Adam Jackson writes:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > This freetype build nonsense is no longer funny. Let's see if I've got
> > this all correct:
> >
> > 1 - Xorg in CVS requires >=2.1.8 to build, either externally or from our
> > own copy.
> > 2 - We cannot force users to upgrade to >=2.1.8 because it has known
> > rendering issues and breaks the build of many other packages (quite the
> > stunning revelation there).
>
> I have asked around and noone I've asked could come up with rendering
> problems with 2.1.8. The build breaks for those packages that have used
> freetype internal defines (appearantly from a non public header). This
> defines have been renamed to bear the prefix FT.
http://freedesktop.org/~ajax/ft2.1.8-badness.png
Notice how the headlines are inconsistent. The fragments at the top of the
third headline were caused by scrolling; presumably the glyph metrics
magically changed between the first and second render passes, so firefox
didn't repaint a big enough area.
What the screenshot doesn't show is the extremely poor load time and the N
cores I generated trying to take the screenshot. Moving the freetype libs
in /usr/X11R6/lib out of my ld.so search path makes the problem go away.
- - ajax
iD8DBQFBDl96W4otUKDs0NMRAkR9AJ9JrqDjBvZEyJtZBNvGuuLcFwzi6QCfRwk6
ptcquFWYDw2A61eCvcAr+qU=
=ciJR
From jbarnes at engr.sgi.com Mon Aug 2 09:19:42 2004
From: jbarnes at engr.sgi.com (Jesse Barnes)
Date: Mon Aug 2 09:21:12 2004
Subject: [Xorg] Debrix troubles on Linux/ppc
In-Reply-To: <1091191100.32370.21.camel@localhost>
References: <200407281830.45096.jbarnes@engr.sgi.com>
<200407291814.21571.jbarnes@engr.sgi.com>
<1091191100.32370.21.camel@localhost>
Message-ID: <200408020919.42891.jbarnes@engr.sgi.com>
On Friday, July 30, 2004 5:38 am, Michel D?nzer wrote:
> On Thu, 2004-07-29 at 18:14 -0700, Jesse Barnes wrote:
> > On Thursday, July 29, 2004 5:44 pm, Jesse Barnes wrote:
> > > On Thursday, July 29, 2004 4:43 pm, Daniel Stone wrote:
> > > > Huh, weird. We should be setting X_ENDIAN_ORDER right in
> > > > configure.ac; I'll need to look into this at some stage.
> > >
> > > It looks like part of the config is working, but some of it is broken:
> > >
> > > jbarnes@mill:~/working/debrix--devel--0.1--patch-11$ grep -r ENDIAN
> > > include/* include/config.h:#define WORDS_BIGENDIAN 1
> > > include/config.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> > > include/config.h.in:#undef WORDS_BIGENDIAN
> > > include/debrix.h:#define WORDS_BIGENDIAN 1
> > > include/debrix.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> > > include/servermd.h:#if defined(__BIG_ENDIAN__)
> >
> > After fixing these up by hand, things get a little further--the server
> > hangs right after loading the vgahw module.
>
> I guess that needs more endianness/powerpc specific fixing.
>
> What about the fbdev driver?
After fixing configure.ac to generate the right define for X_BYTE_ORDER with a
fix something like (sorry I don't have the real patch handy, it's at home):
-AC_C_BIGENDIAN
+AC_C_BIGENDIAN([ENDIAN=X_BIG_ENDIAN],[ENDIAN=X_LITTLE_ENDIAN])
the ati driver behaves the same as the fbdev driver. The server starts and
the screen turns black, and then hangs. I haven't debugged it further.
Thanks,
Jesse
Date: Mon Aug 2 10:54:24 2004
In-Reply-To: otaylor@redhat.com wrote on Monday,
2 August 2004 at 10:07:34 -0400
<1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
Owen Taylor writes:
>
> Please, please, please, I beg you, do *not* encourage people to install
> a second libfreetype.so on their system.
>
> It won't overwrite the distribution's version, no. It *will* cause the
> person to submit a Pango bug report 6 months from now because configure
> tests are running against one libfreetype and Pango is linking against
> the other, or because Pango is linking against one libfreetype and
> running against the other, or some other weirdness that the user has
> no chance at all of being able to debug correctly.
>
I know, having multiple versions of a library installed in different
places in the library search path begs for problems. If one doesn't
know exactly what he is doing the results may be quite strange.
I don't encourage this solution and therefore fixed the problem
by adding #ifdefs to build the new code conditionally.
Please let me test my changes then I'll submit them.
Cheers,
Egbert.
Date: Mon Aug 2 10:56:44 2004
In-Reply-To: ajax@nwnk.net wrote on Monday, 2 August 2004 at 11:36:26 -0400
<16654.15754.244056.116043@xf11.fra.suse.de>
<200408021136.27107.ajax@nwnk.net>
Adam Jackson writes:
>
> http://freedesktop.org/~ajax/ft2.1.8-badness.png
>
> Notice how the headlines are inconsistent. The fragments at the top of the
> third headline were caused by scrolling; presumably the glyph metrics
> magically changed between the first and second render passes, so firefox
> didn't repaint a big enough area.
>
> What the screenshot doesn't show is the extremely poor load time and the N
> cores I generated trying to take the screenshot. Moving the freetype libs
> in /usr/X11R6/lib out of my ld.so search path makes the problem go away.
>
OK, looks like a problem.
How did you compile the code? With freetype 2.1.8 or freetype 2.1.7?
It looks like there may be a binary compatibility problem between the
two versions.
Cheers,
Egbert.
From pma at anderson.fc.hp.com Mon Aug 2 12:14:40 2004
From: pma at anderson.fc.hp.com (Paul Anderson)
Date: Mon Aug 2 12:27:12 2004
Subject: [Xorg] What happened to xorg-bugzilla-noise?
Message-ID: <200408021914.NAA11658@anderson.fc.hp.com>
I noticed that I haven't received any e-mail from bugzilla to the
xorg-bugzilla-noise list since July 14. Does anyone know why?
Was the configuration changed somewhere?
-paul
Date: Mon Aug 2 12:50:48 2004
In-Reply-To: eich@pdx.freedesktop.org wrote on Monday,
2 August 2004 at 16:04:36 +0200
<16654.18932.755325.937060@xf11.fra.suse.de>
I made the necessary modifications so that the code build also with
freetype 2.1.7. I hope this makes everyone happy now so that this issue
doesn't need to be discussed any longer.
Chisato, would you please get the latest bits from X.Org to check
if I screwed up? I don't want to break you fix so shortly before the
release. Thanks a lot!
Cheers,
Egbert.
From rasa at gmx.ch Mon Aug 2 13:33:48 2004
From: rasa at gmx.ch (Raffaele Sandrini)
Date: Mon Aug 2 13:40:28 2004
Subject: [Xorg] Contrast problems using the radeon driver
Message-ID: <1091478828.7335.8.camel@uranos.rnt.ch>
Hi
I used the xorg radeon driver for my Radeon 9600XT without problems till
i switched to a 2 screen env (using Xinerama). Now, the primary screen
shows up with a very weak contrast (i.e. the GNOME 2.6 splash screen is
completly while in the background). The second screen works perfectly.
I first though its a hw prob so i switched monitors. Since the contrast
problem didn't switch to (stayed on the new primary screen) i thought
its a problem of my graphic hardware. To test that i startet up WinXP
and it worked perfect there (with a Catalyst installed). The picture was
perfect (except of the content :)). So its finally seems to be a sw
problem... I actually never tried it with the binary radeon driver yet.
Is this known to any one here?
My specs:
Saphire Radeon 9600XT
2x Samsung 710N tft monitor
cheers,
Raffaele
From matthieu.herrb at laas.fr Mon Aug 2 14:27:47 2004
From: matthieu.herrb at laas.fr (Matthieu Herrb)
Date: Mon Aug 2 14:27:58 2004
no membernamed `find_sbit_image'
References: <16650.42846.746016.823955@xf11.fra.suse.de> <E1BqeEp-0002r9-
7o@evo.keithp.com> <16654.18932.755325.937060@xf11.fra.suse.de>
<16654.39449.256424.372416@xf11.fra.suse.de>
Message-ID: <410EB1D3.7090607@laas.fr>
Egbert Eich wrote:
> I made the necessary modifications so that the code build also with
> freetype 2.1.7. I hope this makes everyone happy now so that this issue
> doesn't need to be discussed any longer.
>
Your patch uses preprocessor directives inside of a macro argument,
which is not supported by gcc 2.95's cpp.
The attached patch is an attempt to fix it.
--
Matthieu
-------------- next part --------------
Index: ftfuncs.c
===================================================================
RCS file: /cvs/xorg/xc/lib/font/FreeType/ftfuncs.c,v
retrieving revision 1.4
diff -u -r1.4 ftfuncs.c
--- ftfuncs.c 2 Aug 2004 19:35:07 -0000 1.4
+++ ftfuncs.c 2 Aug 2004 21:25:31 -0000
@@ -25,7 +25,7 @@
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
*/
-/* $XdotOrg: xc/lib/font/FreeType/ftfuncs.c,v 1.4 2004/08/02 19:35:07 eich Exp
$ */
+/* $XdotOrg: xc/lib/font/FreeType/ftfuncs.c,v 1.3 2004/05/04 18:47:31 gisburn E
xp $ */

/* $XFree86: xc/lib/font/FreeType/ftfuncs.c,v 1.43 2004/02/07 04:37:18 dawes Ex
p $ */

@@ -1049,6 +1049,7 @@
else{
int new_width;
double ratio;
+ int factor;
#if (FREETYPE_VERSION < 2001008)
int try_very_lazy=correct;
if( try_very_lazy ) {
@@ -1077,6 +1078,7 @@
* instance->ttcap.scaleBBoxWidth / 6
4.0 + .5);
ascent = metrics->horiBearingY / 64;
descent = (metrics->height - metrics->horiBearingY) / 64 ;
+ factor = metrics->horiAdvance;
#else
if( ! (instance->load_flags & FT_LOAD_NO_BITMAP) ) {
if( FT_Do_SBit_Metrics(face->face,instance->size,instance->strik
e_index,
@@ -1110,6 +1112,7 @@
* instance->ttcap.scaleBBoxWidth / 6
4.0 + .5);
ascent = bitmap_metrics->horiBearingY / 64;
descent = (bitmap_metrics->height - bitmap_metrics->horiBearingY
) / 64 ;
+ factor = bitmap_metrics->horiAdvance;
#endif
/* */
new_width = characterWidth;
@@ -1127,12 +1130,7 @@
leftSideBearing += instance->ttcap.lsbShiftOfBitmapAutoItalic;
/* */
rawCharacterWidth =
- (unsigned short)(short)(floor(1000
-#if (FREETYPE_VERSION < 2001008)
- * metrics->horiAdvance
-#else
- * bitmap_metrics->horiAdvance
-#endif
+ (unsigned short)(short)(floor(1000 * factor
* instance->ttcap.scaleBBoxWid
th * ratio / 64.
/ instance->pixel_size));
}
From sandmann at daimi.au.dk Mon Aug 2 13:40:54 2004
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: Mon Aug 2 14:29:58 2004
Subject: [Xorg] Get rid of checkerboard
Message-ID: <ye8r7qps27d.fsf@ec10.daimi.au.dk>
Would anyone object if I commit a patch to remove the initial
checkerboard pattern you see between the time the X server starts up
and the ?dm starts drawing the background?
S?ren
From Alan.Coopersmith at Sun.COM Mon Aug 2 14:33:22 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Mon Aug 2 14:33:26 2004
In-Reply-To: <ye8r7qps27d.fsf@ec10.daimi.au.dk>
References: <ye8r7qps27d.fsf@ec10.daimi.au.dk>
Message-ID: <410EB322.4030209@Sun.COM>
Soeren Sandmann wrote:
> Would anyone object if I commit a patch to remove the initial
> checkerboard pattern you see between the time the X server starts up
> and the ?dm starts drawing the background?
Isn't that in there already - just start with -br to set it black instead
of to the grey weave?
--
-Alan Coopersmith- alan.coopersmith@sun.com
Sun Microsystems, Inc. - X Window System Engineering
Date: Mon Aug 2 14:38:19 2004
In-Reply-To: <ye8r7qps27d.fsf@ec10.daimi.au.dk>
References: <ye8r7qps27d.fsf@ec10.daimi.au.dk>
Message-ID: <410EB430.9070408@laas.fr>
>
There's already such an option (-br). Please don't remove the X pattern as
a possible default background. It's really a good test for monitors and
a good calibration pattern for the 'autocalibration' feature of most
flat panel screens.
--
Matthieu
From infinitycool at shaw.ca Mon Aug 2 13:29:09 2004
From: infinitycool at shaw.ca (Jason McGeachie)
Date: Mon Aug 2 14:44:38 2004
Subject: [Xorg] xorgcfg
Message-ID: <410EA415.8070009@shaw.ca>
Hey could anyone point me to the correct directory in the source for the
xorgcfg &| xorgconfig?
I'm a little new,
Jason
Date: Mon Aug 2 14:47:26 2004
Subject: [Xorg] xorgcfg
In-Reply-To: <410EA415.8070009@shaw.ca>
References: <410EA415.8070009@shaw.ca>
Message-ID: <410EB66A.9030108@Sun.COM>
Jason McGeachie wrote:
> Hey could anyone point me to the correct directory in the source for the
> xorgcfg &| xorgconfig?
xc/programs/Xserver/hw/xfree86/xf86config
xc/programs/Xserver/hw/xfree86/xf86cfg
--
From carl at personnelware.com Mon Aug 2 14:49:44 2004
Date: Mon Aug 2 14:49:18 2004
Subject: [Xorg] libXfont.so: undefined reference to `ft_isdigit'
Message-ID: <079101c478da$a21008e0$1e01a8c0@cnt496>
http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=51&logfile=20040
802125633.log
making all in programs/bdftopcf...
make[4]: Entering directory `/home/carl/src/XMonolithic/xc/programs/bdftopcf'
gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wp
ointer-arith -Wundef -I../../include/fonts -I../../lib/font/include -I../../li
b/font/bitmap -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_S
OURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVID_SOUR
CE -D_GNU_SOURCE -DFUNC
PROTO=15 -DNARROWPROTO -c -o bdftopcf.o
bdftopcf.c
rm -f bdftopcf
gcc -m32 -o
bdftopcf -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wp
ointer-arith -Wundef -L../../exports/lib
dftopcf.o -lXfont -lfntstubs -lfreetype -lz -lm -Wl,-rpath-link,../../export
s/lib
../../exports/lib/libXfont.so: undefined reference to `ft_isdigit'
collect2: ld returned 1 exit status
make[4]: *** [bdftopcf] Error 1Not sure what the state of freetype fun is. on
this box:# qpkg -I -v | grep freetypemedia-libs/freetype-2.1.5-r1
*http://www.personnelware.com/carl/resume.html
From krh at bitplanet.net Mon Aug 2 14:55:50 2004
From: krh at bitplanet.net (=?ISO-8859-1?Q?Kristian_H=F8gsberg?=)
Date: Mon Aug 2 14:57:47 2004
In-Reply-To: <410EB430.9070408@laas.fr>
References: <ye8r7qps27d.fsf@ec10.daimi.au.dk> <410EB430.9070408@laas.fr>
Message-ID: <410EB866.60002@bitplanet.net>
Matthieu Herrb wrote:
> Soeren Sandmann wrote:
>
>> Would anyone object if I commit a patch to remove the initial
>> checkerboard pattern you see between the time the X server starts up
>> and the ?dm starts drawing the background?
>>
>
> There's already such an option (-br). Please don't remove the X pattern as
> a possible default background. It's really a good test for monitors and
> a good calibration pattern for the 'autocalibration' feature of most
> flat panel screens.
Surely you could use an application for that; paint the pattern in a
fullscreen window. There's no need for that to be the first thing the
user sees when he logs in. At least the option logic could be reversed
so it defaults to a black screen.
Kristian
Date: Mon Aug 2 15:00:47 2004
<200408021136.27107.ajax@nwnk.net>
<16654.32778.111431.935466@xf11.fra.suse.de>
Hash: SHA1
On Monday 02 August 2004 13:55, Egbert Eich wrote:
> Adam Jackson writes:
> > http://freedesktop.org/~ajax/ft2.1.8-badness.png
> >
> > Notice how the headlines are inconsistent. The fragments at the top of
> > the third headline were caused by scrolling; presumably the glyph
> > metrics magically changed between the first and second render passes, so
> > firefox didn't repaint a big enough area.
> >
> > What the screenshot doesn't show is the extremely poor load time and the
> > N cores I generated trying to take the screenshot. Moving the freetype
> > libs in /usr/X11R6/lib out of my ld.so search path makes the problem go
> > away.
>
> OK, looks like a problem.
>
> How did you compile the code? With freetype 2.1.8 or freetype 2.1.7?
> It looks like there may be a binary compatibility problem between the
> two versions.
Firefox was built against 2.1.4, apparently. This is the minimum gentoo's
xorg-x11 package requires, odd in light of the 2.1.7 requirement for 6.7.0
I've heard mentioned here...
- - ajax
iD8DBQFBDrgOW4otUKDs0NMRAmg2AKC9HoYtSiJcIK3OJo5cD4Qbln+NRgCfSkZ8
8MG2O4cP3qa8OxLz6Cx1HEw=
=y0SX
From alan at lxorguk.ukuu.org.uk Mon Aug 2 13:59:52 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Mon Aug 2 15:02:34 2004
In-Reply-To: <410EB866.60002@bitplanet.net>
<410EB866.60002@bitplanet.net>
On Llu, 2004-08-02 at 22:55, Kristian H?gsberg wrote:
> Surely you could use an application for that; paint the pattern in a
> fullscreen window. There's no need for that to be the first thing the
> user sees when he logs in. At least the option logic could be reversed
> so it defaults to a black screen.
Black screen is about the worst possible default you can have. A lot of
older analogue tfts can't sync to it. Blue, purple, yellow whatever
would all be better, even I suspect grey (not tested that).
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Mon Aug 2 15:19:30 2004
Message-ID: <410EBD7D.9000404@bitplanet.net>
Alan Cox wrote:
> On Llu, 2004-08-02 at 22:55, Kristian H?gsberg wrote:
>
>>Surely you could use an application for that; paint the pattern in a
>>fullscreen window. There's no need for that to be the first thing the
>>user sees when he logs in. At least the option logic could be reversed
>>so it defaults to a black screen.
>
>
> Black screen is about the worst possible default you can have. A lot of
> older analogue tfts can't sync to it. Blue, purple, yellow whatever
> would all be better, even I suspect grey (not tested that).
But the checkerboard pattern isn't shown for long, then the desktop
environment kicks in and sets the background. So it's only an iusse if
the user starts the X server without setting the background.
If there's a problem with the server, the user could be instructed to
run the server with the pattern enables, much like enabling debug output.
Kristian
From keithp at keithp.com Mon Aug 2 15:26:01 2004
Date: Mon Aug 2 15:26:19 2004
In-Reply-To: Your message of "02 Aug 2004 22:40:54 +0200."
<ye8r7qps27d.fsf@ec10.daimi.au.dk>
Message-ID: <E1BrlFp-0001EN-ON@evo.keithp.com>
Around 22 o'clock on Aug 2, Soeren Sandmann wrote:
There's already a command line option to select a black background. Do
you intend something different? Or do you just want that to be the
default?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/58b56a09/attach
ment.pgp
Date: Mon Aug 2 15:35:22 2004
In-Reply-To: Your message of "Mon, 02 Aug 2004 21:59:52 BST."
Message-ID: <E1BrlOi-0001F0-R6@evo.keithp.com>
Around 21 o'clock on Aug 2, Alan Cox wrote:
> Black screen is about the worst possible default you can have. A lot of
> older analogue tfts can't sync to it. Blue, purple, yellow whatever
> would all be better, even I suspect grey (not tested that).
For the 'default' background (xsetroot defualt), you get your choice of
any pattern you like as long as it contains only white and black pixels.
I suspect most people would prefer something other than white...
Currently, the X server starts with the root set to that pattern, but we
could change that to some solid pixel value (tiles would be a lot harder).
This is completely trivial on read-only visuals. For read-write visuals,
you could count on the Render extension to allocate a reasonable spread of
pixels and pick a non-black/white pixel value if you like.
gdm uses a dark grey, which appears to make at least my LCD screens happy
enough in analog mode.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/d440f2a8/attach
ment.pgp
From Jim.Gettys at hp.com Mon Aug 2 16:07:31 2004
Date: Mon Aug 2 16:07:44 2004
In-Reply-To: <410EB430.9070408@laas.fr>
On Mon, 2004-08-02 at 17:37, Matthieu Herrb wrote:
> Soeren Sandmann wrote:
>
> > Would anyone object if I commit a patch to remove the initial
> > checkerboard pattern you see between the time the X server starts up
> > and the ?dm starts drawing the background?
> >
>
> There's already such an option (-br). Please don't remove the X pattern as
> a possible default background. It's really a good test for monitors and
> a good calibration pattern for the 'autocalibration' feature of most
> flat panel screens.
Yup.
This pattern, has through the years, done wonders to keep
monitor manufacturers honest.
Remember, if your monitor can't handle the pattern, there
is something wrong with the monitor....
- Jim
Date: Mon Aug 2 17:12:34 2004
Subject: [Xorg] XInput Hotplug Additions
Message-ID: <410ED7FC.5030401@bitplanet.net>
Hi,
I've been doing some work on the XInput hotplug functionality that was
discussed on this list some weeks ago. I have put a patch in bugzilla,
http://freedesktop.org/bugzilla/show_bug.cgi?id=971. At this point,
I've added two requests to XInput:
extern int XAddInputDevice(
Display* /* display */,
_Xconst char* /* name */,
_Xconst char* /* driver */,
XDeviceOption* /* options */,
int /* nOptions */
);

extern int XRemoveInputDevice(
Display* /* display */,
_Xconst char* /* name */
);
with
typedef struct {
char *name;
char *value;
} XDeviceOption;

The idea is that the arguments given to XAddInputDevice() corresponds to
the options you can give in an xorg.conf InputDevice section, e.g.
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
EndSection
could be configured at runtime from an X client as
XDeviceOption options[] = {
{ "Protocol", "IMPS/2" },
{ "Device", "/dev/input/mice" },
{ "ZAxisMapping", "4 5" },
};
XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
Which will load the "mouse" driver if it's not already present, and add
the device "Mouse0".
When a new device is added, a DevicePresenceNotify event is sent to
interested clients. The event does not contain any information about
the change, clients should use XListInputDevices() to find out what
devices are available.
I've also attached a tar-file with a few sample applications: xadddev
and xrmdev are commandline utils to add and remove input devices,
get-event demonstrates how to select the DevicePresenceNotify event and
finally, input-daemon, which is a simple example of how a daemon could
listen for system hotplug events using HAL and add and remove input
devices accordingly.
I think it would be cool if we could have this or similar functionality
in the next release again (i.e. not the one scheduled for August). At
the moment I guess people are busy with the upcoming release, but I
would greatly appreciate comments and feedback on this stuff.
Kristian
Date: Mon Aug 2 17:19:46 2004
In-Reply-To: <410ED7FC.5030401@bitplanet.net>
References: <410ED7FC.5030401@bitplanet.net>
Message-ID: <410EDA19.50704@Sun.COM>
Kristian H?gsberg wrote:
> The idea is that the arguments given to XAddInputDevice() corresponds to
> the options you can give in an xorg.conf InputDevice section, e.g.
>
> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "IMPS/2"
> Option "Device" "/dev/input/mice"
> Option "ZAxisMapping" "4 5"
> EndSection
>
> could be configured at runtime from an X client as
>
> XDeviceOption options[] = {
> { "Protocol", "IMPS/2" },
> { "Device", "/dev/input/mice" },
> { "ZAxisMapping", "4 5" },
> };
>
> XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
So this extension is only usable by the Xorg server and other X servers
with their own configuration methods will not be able to use it?
--
Date: Mon Aug 2 17:21:39 2004
In-Reply-To: <410EBD7D.9000404@bitplanet.net>
<410EBD7D.9000404@bitplanet.net>
On Llu, 2004-08-02 at 23:17, Kristian H?gsberg wrote:
> But the checkerboard pattern isn't shown for long, then the desktop
> environment kicks in and sets the background. So it's only an iusse if
> the user starts the X server without setting the background.
By the time the desktop appears the setups I've looked at have already
mis-synced with black as background. I'm not unique in this either,
there are a couple of hate mails in the Red Hat bugzilla about it
> If there's a problem with the server, the user could be instructed to
> run the server with the pattern enables, much like enabling debug output.
You seriously overestimate the average user. Try "hey my desktop is
wonky, this software sucks".
Date: Mon Aug 2 17:28:34 2004
In-Reply-To: Your message of "Mon, 02 Aug 2004 17:19:37 PDT."
<410EDA19.50704@Sun.COM>
Message-ID: <E1BrnAF-0001Lh-SI@evo.keithp.com>
Around 17 o'clock on Aug 2, Alan Coopersmith wrote:
> So this extension is only usable by the Xorg server and other X servers
> with their own configuration methods will not be able to use it?
It does appear to rely a bit too heavily on the existing input device
configuration mechanism and device handling.
Even on Linux, I'd like to see the various protocol details handled
exclusively by the kernel (this is already true with kernel 2.6) and have
the X server use only "standard" /dev/input devices for input. This
should eliminate almost all of the options listed in that request, leaving
us with:
XAddInputDevice (dpy, "/dev/input/event0");
Configuration of the axis->button mapping should use the existing XInput
device manipulation primitives, rather than being hard-coded when the
device is added. This way all devices can be reconfigured on the fly
without needing to go through a gratuitous unplug/plug cycle.
Detection of appropriate drivers and protocols should be left to the X
server/kernel. I'm not sure what we should do about naming; if the
hotplug daemon can't even tell what kind of device is attached, it's going
to have a hard time coming up with a reasonable name. On the other hand,
having the X server attempt to construct a name means we'll be stuck with
useless names most of the time.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/a5209cc7/attach
ment.pgp
Date: Mon Aug 2 17:52:54 2004
In-Reply-To: <410EDA19.50704@Sun.COM>
References: <410ED7FC.5030401@bitplanet.net> <410EDA19.50704@Sun.COM>
Message-ID: <410EE170.30207@bitplanet.net>
Alan Coopersmith wrote:
> Kristian H?gsberg wrote:
>
>> The idea is that the arguments given to XAddInputDevice() corresponds
>> to the options you can give in an xorg.conf InputDevice section, e.g.
>>
>> Section "InputDevice"
>> Identifier "Mouse0"
>> Driver "mouse"
>> Option "Protocol" "IMPS/2"
>> Option "Device" "/dev/input/mice"
>> Option "ZAxisMapping" "4 5"
>> EndSection
>>
>> could be configured at runtime from an X client as
>>
>> XDeviceOption options[] = {
>> { "Protocol", "IMPS/2" },
>> { "Device", "/dev/input/mice" },
>> { "ZAxisMapping", "4 5" },
>> };
>>
>> XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
>
>
> So this extension is only usable by the Xorg server and other X servers
> with their own configuration methods will not be able to use it?
No, that wasn't the intention. The XAddInputDevice() API was clearly
inspired by to xorg.conf file, but is was my hope that the
device+driver+options would be general enough that it would work for
other servers too. If that is not the case, I would like to get
feedback on how to change the API so several server implementations
could be accomodated.
Even so, the available drivers and options will be server specific, and
the client must know what server it is talking to and use options that
work with the server in question.
As an alternative, the XAddInputDevice() and XRemoveInputDevice()
requests could be moved to an Xorg speficic extension, e.g. Xorg-Hotplug.
Kristian
Date: Mon Aug 2 18:52:21 2004
In-Reply-To: <E1BrnAF-0001Lh-SI@evo.keithp.com>
References: <E1BrnAF-0001Lh-SI@evo.keithp.com>
Message-ID: <410EEF5E.9080701@bitplanet.net>
> Around 17 o'clock on Aug 2, Alan Coopersmith wrote:
>
>
>>So this extension is only usable by the Xorg server and other X servers
>>with their own configuration methods will not be able to use it?
>
>
> It does appear to rely a bit too heavily on the existing input device
> configuration mechanism and device handling.
>
> Even on Linux, I'd like to see the various protocol details handled
> exclusively by the kernel (this is already true with kernel 2.6) and have
> the X server use only "standard" /dev/input devices for input. This
> should eliminate almost all of the options listed in that request, leaving
> us with:
>
> XAddInputDevice (dpy, "/dev/input/event0");
I was aiming for a solution that would work with the existing range of
input drivers, but if that's not strictly needed, that's cool. It's
certainly easier and a more clean solution to let the X server probe the
device, but it requires that the OS provides such devices with
sufficient meta data available.
Anyway, I've mostly written the linux evdev driver, see
http://freedesktop.org/bugzilla/show_bug.cgi?id=968. It uses ioctl()'s
to discover what events the linux input device can generate and then
adds adds a server input device with the corresponding input classes.
It works for mice and keyboards at the moment, and I plan to add support
for absolute events, which should add touch screen support also.
> Configuration of the axis->button mapping should use the existing XInput
> device manipulation primitives, rather than being hard-coded when the
> device is added. This way all devices can be reconfigured on the fly
> without needing to go through a gratuitous unplug/plug cycle.
>
> Detection of appropriate drivers and protocols should be left to the X
> server/kernel. I'm not sure what we should do about naming; if the
> hotplug daemon can't even tell what kind of device is attached, it's going
> to have a hard time coming up with a reasonable name. On the other hand,
> having the X server attempt to construct a name means we'll be stuck with
> useless names most of the time.
The HAL based input-daemon example I have use the HAL UDI (unique device
identifier), which is a perfect example of a useless name. But it could
do better, it has the vendor name and product name available. But that
information is also available from the linux input device through
ioctl()'s, so the X server could also construct a better name.
Kristian
Date: Mon Aug 2 20:41:43 2004
In-Reply-To: Your message of "Tue, 03 Aug 2004 03:50:22 +0200."
<410EEF5E.9080701@bitplanet.net>
Message-ID: <E1BrqB7-0001Ox-Nm@evo.keithp.com>
Around 3 o'clock on Aug 3, =?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?= wrote:
> I was aiming for a solution that would work with the existing range of
> input drivers, but if that's not strictly needed, that's cool.
Yeah, I don't see any reason to continue to support user-level device
drivers when few (any?) systems need them any more. If you want hot-plug,
then you get to create a reasonable input system. For really broken
environments, a user-level process could open the device and submit
standard format events through some back-channel.
> But that information is also available from the linux input device through
> ioctl()'s, so the X server could also construct a better name.
Hmm. If the X server is responsible for building a name, then we have the
situation where an app adds a device and then has to guess what name it
has. Is there some other way of identifying the device?
I guess there's no idea solution.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040802/a7985db0/attach
ment.pgp
From daniel at freedesktop.org Mon Aug 2 20:46:57 2004
Date: Mon Aug 2 20:46:59 2004
In-Reply-To: <E1BrqB7-0001Ox-Nm@evo.keithp.com>
References: <410EEF5E.9080701@bitplanet.net> <E1BrqB7-0001Ox-Nm@evo.keithp.com>
Message-ID: <20040803034657.GG17302@fooishbar.org>
On Mon, Aug 02, 2004 at 08:41:29PM -0700, Keith Packard wrote:
> Yeah, I don't see any reason to continue to support user-level device
> drivers when few (any?) systems need them any more. If you want hot-plug,
> then you get to create a reasonable input system. For really broken
> environments, a user-level process could open the device and submit
> standard format events through some back-channel.
I think the current horrific mess of os-support, random crap strewn
through imake, and common/ (so-called 'common') is a testament to why we
should force as much stuff over to the underlying system as possible.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040803/fd4e98c0/attach
ment.pgp
From dominatus at gmail.com Mon Aug 2 18:00:57 2004
From: dominatus at gmail.com (Anthony Romano)
Date: Mon Aug 2 23:27:42 2004
Subject: [Xorg] Build Error with Composite
Message-ID: <d3ca5069040802180012992fb2@mail.gmail.com>
I have the most recent cvs and added in my host.def
#define BuildComposite YES
I also have BuildDamage and BuildXFixes set to YES as well, I wasn't
sure if they were built by default. When I try to build it I get the
following error:
cpp -undef -traditional
-D__apploaddir__=/usr/X11R6/lib/X11/app-defaults -D__appmansuffix__=1x
-D__filemansuffix__=5x -D__libmansuffix__=3x -D__miscmansuffix__=7
-D__drivermansuffix__=4 -D__adminmansuffix__=8
-D__projectroot__=/usr/X11R6 -D__xconfigfile__=xorg.conf
-D__xconfigdir__=/usr/X11R6/lib/X11 -D__xlogfile__=Xorg
-D__xservername__=Xorg -D__xorgversion__='"" ""'
-D__vendorversion__="ècho 6 7 0 | sed -e 's/ /./g' -e 's/^/Version\\\
/'` X.Org" \
< Xdmx.man | sed -e '/^# *[0-9][0-9]* *.*$/d'
-e '/^#line *[0-9][0-9]* *.*$/d' -e '/^[
]*XCOMM$/s/XCOMM/#/' -e '/^[
]*XCOMM[â-zA-Z0-9_]/s/XCOMM/#/' -e '/^[
]*XHASH/s/XHASH/#/' -e '/\@\@$/s/\@\@$/\\/'
>Xdmx._man; \
fi
rm -f Xdmx.1x.html Xdmx.1x-html
../../../../config/util/rman -f HTML < Xdmx._man \
> Xdmx.1x-html && mv -f Xdmx.1x-html Xdmx.1x.html
make[5]: Leaving directory `/home/tony/xcbuild/programs/Xserver/hw/dmx'
gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
-pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o
../../programs/Xserver/hw/xfree86/common/xf86Init.o
../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
../../programs/Xserver/hw/xfree86/common/libxf86.a
../../programs/Xserver/hw/xfree86/parser/libxf86config.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
../../programs/Xserver/hw/xfree86/loader/libloader.a
../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a
os/libos.a ../../lib/font/fontbase.o
../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a
Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a
../../programs/Xserver/hw/xfree86/common/libxf86.a
Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a
randr/librandr.a render/librender.a xfixes/libxfixes.a
damageext/libdamage.a miext/damage/libdamage.a
composite/libcomposite.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a
xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a
render/librender.a xfixes/libxfixes.a damageext/libdamage.a
miext/damage/libdamage.a composite/libcomposite.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
-lXau -lXdmcp -rdynamic -ldl
-Wl,-rpath-link,../../exports/lib
gcc -m32 -o Xprt -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
-pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
Xprint/ddxInit.o Xprint/miinitext.o Xprint/dpmsstubs.o
os/libcwrapper.o dix/libdix.a os/libos.a Xprint/libprinter.a
Xprint/raster/libraster.a Xprint/pcl/libpcl.a Xprint/pcl-mono/libpcl.a
Xprint/ps/libps.a mfb/libmfb.a cfb/libcfb.a cfb32/libcfb32.a
mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a
Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
xfixes/libxfixes.a damageext/libdamage.a
miext/damage/libdamage.a composite/libcomposite.a Xext/libext.a
dbe/libdbe.a record/librecord.a GL/glx/libglx.a
GL/mesa/GLcore/libGLcore.a XTrap/libxtrap.a
../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -lm
-lXau -lXdmcp -Wl,-rpath-link,../../exports/lib
Xprint/ps/libps.a(psout_ftpstype1.o)(.text+0x6f): In function
`PsOut_DownloadFreeType1':
: the use of `tempnam' is dangerous, better use `mkstemp'
composite/libcomposite.a(compext.o)(.text+0x3b6): In function
`ProcCompositeCreateRegionFromBorderClip':
: undefined reference to `XFixesRegionCopy'
composite/libcomposite.a(compext.o)(.text+0x3e6): In function
`ProcCompositeCreateRegionFromBorderClip':
: undefined reference to `RegionResType'
composite/libcomposite.a(compwindow.o)(.text+0xa55): In function
`compCopyWindow':
: undefined reference to `DamageDamageRegion'
composite/libcomposite.a(compwindow.o)(.text+0xea2): In function
`compSetRedirectBorderClip':
composite/libcomposite.a(compwindow.o)(.text+0x1015): In function
`compWindowUpdateAutomatic':
: undefined reference to `DamageRegion'
composite/libcomposite.a(compwindow.o)(.text+0x117f): In function
`compWindowUpdateAutomatic':
: undefined reference to `DamageEmpty'
composite/libcomposite.a(compalloc.o)(.text+0x180): In function
`compRedirectWindow':
: undefined reference to `DamageUnregister'
composite/libcomposite.a(compalloc.o)(.text+0x1d1): In function
`compRedirectWindow':
: undefined reference to `DamageCreate'
composite/libcomposite.a(compalloc.o)(.text+0x35c): In function
`compFreeClientWindow':
: undefined reference to `DamageRegister'
composite/libcomposite.a(compalloc.o)(.text+0x3cd): In function
: undefined reference to `DamageDestroy'
composite/libcomposite.a(compalloc.o)(.text+0x57d): In function
`compRedirectSubwindows':
: undefined reference to `DamageExtSetCritical'
`compFreeClientSubwindows':
: undefined reference to `DamageExtSetCritical'
`compAllocPixmap':
: undefined reference to `DamageRegister'
composite/libcomposite.a(compalloc.o)(.text+0xa21): In function
`compFreePixmap':
: undefined reference to `DamageUnregister'
make[4]: *** [Xprt] Error 1
make[4]: Leaving directory `/home/tony/xcbuild/programs/Xserver'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/tony/xcbuild/programs'
make[2]: Leaving directory `/home/tony/xcbuild'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/tony/xcbuild'
make: *** [World] Error 2
If I leave out BuildComposite it builds fine. Is the composite manager
just not read to be built yet, or am I missing a step. (I couldn't
find anywhere online on steps to build x.org with the new composite
manager.
From eta at lclark.edu Mon Aug 2 23:34:54 2004
Date: Mon Aug 2 23:35:01 2004
In-Reply-To: <d3ca5069040802180012992fb2@mail.gmail.com>
References: <d3ca5069040802180012992fb2@mail.gmail.com>
On Mon, 2004-08-02 at 18:00, Anthony Romano wrote:
> I have the most recent cvs and added in my host.def
>
> #define BuildComposite YES
>
> I also have BuildDamage and BuildXFixes set to YES as well, I wasn't
> sure if they were built by default. When I try to build it I get the
> following error:
>
> cpp -undef -traditional
> -D__apploaddir__=/usr/X11R6/lib/X11/app-defaults -D__appmansuffix__=1x
> -D__filemansuffix__=5x -D__libmansuffix__=3x -D__miscmansuffix__=7
> -D__drivermansuffix__=4 -D__adminmansuffix__=8
> -D__projectroot__=/usr/X11R6 -D__xconfigfile__=xorg.conf
> -D__xconfigdir__=/usr/X11R6/lib/X11 -D__xlogfile__=Xorg
> -D__xservername__=Xorg -D__xorgversion__='"" ""'
> -D__vendorversion__="ècho 6 7 0 | sed -e 's/ /./g' -e 's/^/Version\\\
> /'` X.Org" \
> < Xdmx.man | sed -e '/^# *[0-9][0-9]* *.*$/d'
> -e '/^#line *[0-9][0-9]* *.*$/d' -e '/^[
> ]*XCOMM$/s/XCOMM/#/' -e '/^[
> ]*XCOMM[â-zA-Z0-9_]/s/XCOMM/#/' -e '/^[
> ]*XHASH/s/XHASH/#/' -e '/\@\@$/s/\@\@$/\\/'
> >Xdmx._man; \
> fi
> rm -f Xdmx.1x.html Xdmx.1x-html
> ../../../../config/util/rman -f HTML < Xdmx._man \
> > Xdmx.1x-html && mv -f Xdmx.1x-html Xdmx.1x.html
> make[5]: Leaving directory `/home/tony/xcbuild/programs/Xserver/hw/dmx'
> gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
> xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o
> ../../programs/Xserver/hw/xfree86/common/xf86Init.o
> ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
> ../../programs/Xserver/hw/xfree86/common/libxf86.a
> ../../programs/Xserver/hw/xfree86/parser/libxf86config.a
> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
> ../../programs/Xserver/hw/xfree86/loader/libloader.a
> ../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a
> os/libos.a ../../lib/font/fontbase.o
> ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a
> Xi/libxinput.a lbx/liblbx.a
> ../../lib/lbxutil/liblbxutil.a
> ../../programs/Xserver/hw/xfree86/common/libxf86.a
> Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
> lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a
> randr/librandr.a render/librender.a xfixes/libxfixes.a
> damageext/libdamage.a miext/damage/libdamage.a
> composite/libcomposite.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a
> xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
> ../../lib/lbxutil/liblbxutil.a randr/librandr.a
> render/librender.a xfixes/libxfixes.a damageext/libdamage.a
> miext/damage/libdamage.a composite/libcomposite.a
> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
> -lXau -lXdmcp -rdynamic -ldl
> -Wl,-rpath-link,../../exports/lib
> gcc -m32 -o Xprt -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
> Xprint/ddxInit.o Xprint/miinitext.o Xprint/dpmsstubs.o
> os/libcwrapper.o dix/libdix.a os/libos.a Xprint/libprinter.a
> Xprint/raster/libraster.a Xprint/pcl/libpcl.a Xprint/pcl-mono/libpcl.a
> Xprint/ps/libps.a mfb/libmfb.a cfb/libcfb.a cfb32/libcfb32.a
> mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a
> Xi/libxinput.a lbx/liblbx.a
> ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
> xfixes/libxfixes.a damageext/libdamage.a
> miext/damage/libdamage.a composite/libcomposite.a Xext/libext.a
> dbe/libdbe.a record/librecord.a GL/glx/libglx.a
> GL/mesa/GLcore/libGLcore.a XTrap/libxtrap.a
> ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -lm
> -lXau -lXdmcp -Wl,-rpath-link,../../exports/lib
> Xprint/ps/libps.a(psout_ftpstype1.o)(.text+0x6f): In function
> `PsOut_DownloadFreeType1':
> : the use of `tempnam' is dangerous, better use `mkstemp'
> composite/libcomposite.a(compext.o)(.text+0x3b6): In function
> `ProcCompositeCreateRegionFromBorderClip':
> : undefined reference to `XFixesRegionCopy'
> composite/libcomposite.a(compext.o)(.text+0x3e6): In function
> `ProcCompositeCreateRegionFromBorderClip':
> : undefined reference to `RegionResType'
> composite/libcomposite.a(compwindow.o)(.text+0xa55): In function
> `compCopyWindow':
> : undefined reference to `DamageDamageRegion'
> composite/libcomposite.a(compwindow.o)(.text+0xea2): In function
> `compSetRedirectBorderClip':
> composite/libcomposite.a(compwindow.o)(.text+0x1015): In function
> `compWindowUpdateAutomatic':
> : undefined reference to `DamageRegion'
> composite/libcomposite.a(compwindow.o)(.text+0x117f): In function
> `compWindowUpdateAutomatic':
> : undefined reference to `DamageEmpty'
> composite/libcomposite.a(compalloc.o)(.text+0x180): In function
> `compRedirectWindow':
> : undefined reference to `DamageUnregister'
> composite/libcomposite.a(compalloc.o)(.text+0x1d1): In function
> `compRedirectWindow':
> : undefined reference to `DamageCreate'
> composite/libcomposite.a(compalloc.o)(.text+0x35c): In function
> `compFreeClientWindow':
> : undefined reference to `DamageRegister'
> composite/libcomposite.a(compalloc.o)(.text+0x3cd): In function
> : undefined reference to `DamageDestroy'
> composite/libcomposite.a(compalloc.o)(.text+0x57d): In function
> `compRedirectSubwindows':
> : undefined reference to `DamageExtSetCritical'
> `compFreeClientSubwindows':
> : undefined reference to `DamageExtSetCritical'
> `compAllocPixmap':
> : undefined reference to `DamageRegister'
> composite/libcomposite.a(compalloc.o)(.text+0xa21): In function
> `compFreePixmap':
> : undefined reference to `DamageUnregister'
> collect2: ld returned 1 exit status
> make[4]: *** [Xprt] Error 1
> make[4]: Leaving directory `/home/tony/xcbuild/programs/Xserver'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/home/tony/xcbuild/programs'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/tony/xcbuild'
> make[1]: *** [World] Error 2
> make[1]: Leaving directory `/home/tony/xcbuild'
> make: *** [World] Error 2
>
>
> If I leave out BuildComposite it builds fine. Is the composite manager
> just not read to be built yet, or am I missing a step. (I couldn't
> find anywhere online on steps to build x.org with the new composite
> manager.
This is why BuildComposite isn't the default. I haven't figured out
what causes this yet. Note that there are no compositing managers
(that's the name for a client program using the Composite extension to
draw the screen) in the tree -- BuildComposite controls the inclusion of
the extension in the server.
--
From eich at pdx.freedesktop.org Tue Aug 3 00:02:40 2004
Date: Tue Aug 3 00:04:04 2004
In-Reply-To: eich@pdx.freedesktop.org wrote on Monday,
2 August 2004 at 16:04:36 +0200
<16654.18932.755325.937060@xf11.fra.suse.de>
I made the necessary modifications so that the code build also with
freetype 2.1.7. I hope this makes everyone happy now so that this issue
doesn't need to be discussed any longer.
Chisato, would you please get the latest bits from X.Org to check
if I screwed up? I don't want to break you fix so shortly before the
release. Thanks a lot!
Cheers,
Egbert.
Date: Tue Aug 3 01:05:16 2004
In-Reply-To: ajax@nwnk.net wrote on Monday, 2 August 2004 at 17:54:22 -0400
<200408021136.27107.ajax@nwnk.net>
<16654.32778.111431.935466@xf11.fra.suse.de>
<200408021754.23777.ajax@nwnk.net>
Adam Jackson writes:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Firefox was built against 2.1.4, apparently. This is the minimum gentoo's
> xorg-x11 package requires, odd in light of the 2.1.7 requirement for 6.7.0
> I've heard mentioned here...
>
2.1.4 of course is 4 patchlevels earlier providing several opportunities
for breaking ABI compatibility.
Just for curiostiy: Could you please build firefox against freetype 2.1.8
and see if the problem still happens?
The freetype folks keep breaking their ABI between versions. And that
often happens in a not immediately obvious way.
Cheers,
Egbert.
Date: Tue Aug 3 01:28:31 2004
In-Reply-To: otaylor@redhat.com wrote on Monday,
2 August 2004 at 10:07:34 -0400
<1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
Owen Taylor writes:
> It won't overwrite the distribution's version, no. It *will* cause the
> person to submit a Pango bug report 6 months from now because configure
> tests are running against one libfreetype and Pango is linking against
> the other, or because Pango is linking against one libfreetype and
> running against the other, or some other weirdness that the user has
> no chance at all of being able to debug correctly.
>
Thinking about this issue some more:
In the past FreeType has broken binary compatibility more than once.
We may be able to help educate them in for the future but we cannot
change the past.
This however means that it is not possible to install a later version
of libfreetype without requiring that all applications that build on it
need rebuilding.
We agree that installing a different version of libfreetype (with the
same major version number) into another directory calls for trouble.
There seems to be a consense that linking against libfreetype statically
is a bad idea as security fixes would require to rebuild any application.
(Which may have to be done anyway if one chooses to supply fixes by
providing a later version of the lib).
Effectively this means that it is impossible to build components of
X on a system with with freetype version x that have a dependency on
a version y with y > x.
This begs the question what we should do:
I can think of three solutions:
1. We add more ifdefs to support earlier versions of freetype.
The code can be build against the installed version of the lib
and nothing needs to be updated.
2. We ask the freetype folks to use ELF symbol versioning to provide
ABI compatibility to earlier versions. This way FreeType has the
trouble and we can keep our code relatively clean.
3. FreeType bumps the major version number and assures that new versions
of their lib will provide binary compatibility as long as this major
version number is in use. This will not solve really solve the problems
of the past but it allows the user to install a new version of freetype
and build against it while still keeping the original one for all
older applications.
Egbert.
From keith at tungstengraphics.com Tue Aug 3 01:06:12 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Tue Aug 3 01:37:26 2004
References: <16650.42846.746016.823955@xf11.fra.suse.de> <E1BqeEp-0002r9-
7o@evo.keithp.com> <16654.18932.755325.937060@xf11.fra.suse.de>
<16655.14480.409961.819294@xf11.fra.suse.de>
Message-ID: <410F4774.8090201@tungstengraphics.com>
Egbert Eich wrote:
> I made the necessary modifications so that the code build also with
> freetype 2.1.7. I hope this makes everyone happy now so that this issue
> doesn't need to be discussed any longer.
>
> Chisato, would you please get the latest bits from X.Org to check
> if I screwed up? I don't want to break you fix so shortly before the
> release. Thanks a lot!
It's interesting to see X.org work this problem through. One thing that
strikes me about the process is that people here are bending over backwards to
avoid suprising the user, which is laudable. What strikes me is that we
aren't getting the same support from our 'upstream' projects - while there has
been some flamage within X.org, I can't help but thinking freetype needs a
boot up the backside if they really are introducing API changes and binary
incompatibilities in point releases -- what's going on, what's being done
about it, who takes responsibility?
Keith
Date: Tue Aug 3 02:11:31 2004
In-Reply-To: cyamauch@a.phys.nagoya-u.ac.jp wrote on Tuesday,
3 August 2004 at 16:18:35 +0900
References: <E1BqeEp-0002r9-7o@evo.keithp.com>
<16654.18932.755325.937060@xf11.fra.suse.de>
<16655.14480.409961.819294@xf11.fra.suse.de>
<20040803.161835.74736016.cyamauch@a.phys.nagoya-u.ac.jp>
Hi Chisato,
I've applied your patch. It is much nicer.
Thanks!
Cheers,
Egbert.
Chisato Yamauchi writes:
>
> ftfuncs.c of version 1.4 is disfigured. We should keep our
> code simple. I propose a patch based on version 1.3:
>
> ================================
> --- ftfuncs.c.1.3 2004-08-03 15:06:12.000000000 +0900
> +++ ftfuncs.c 2004-08-03 16:06:23.000000000 +0900
> @@ -69,6 +69,8 @@
> #include "ftfuncs.h"
> #include "xttcap.h"
>
> +#define FREETYPE_VERSION (FREETYPE_MAJOR * 1000000 + FREETYPE_MINOR * 1000 +
FREETYPE_PATCH)
> +
> /* Work around FreeType bug */
> #define WORK_AROUND_UPM 2048
>
> @@ -90,6 +92,12 @@
> #define DEFAULT_VERY_LAZY 2 /* Multi-byte only */
> /* #define DEFAULT_VERY_LAZY 256 */ /* Unicode only */
>
> +#if (FREETYPE_VERSION < 2001008)
> +#ifdef DEFAULT_VERY_LAZY
> +#undef DEFAULT_VERY_LAZY
> +#endif
> +#endif
> +
> /* Does the X accept noSuchChar? */
> #define X_ACCEPTS_NO_SUCH_CHAR
> /* Does the XAA accept NULL noSuchChar.bits?(dangerous) */
> @@ -906,6 +914,7 @@
> FT_Do_SBit_Metrics( FT_Face ft_face, FT_Size ft_size, FT_ULong strike_index,
> FT_UShort glyph_index, FT_Glyph_Metrics *metrics_return )
> {
> +#if (FREETYPE_VERSION >= 2001008)
> SFNT_Service sfnt;
> TT_Face face;
> FT_Error error;
> @@ -969,6 +978,9 @@
>
> Exit:
> return error;
> +#else /* if (FREETYPE_VERSION < 2001008) */
> + return -1;
> +#endif
> }
>
> int
> ================================
>
> I think that this is enough for non-CJK users. Please test!
>
> In addition, sfnt->set_sbit_strike() is public in freetype-2.1.7.
> So we don't have to change FreeTypeOpenInstance() function.
>
> ------------------------------------------------------------
> Chisato Yamauchi
Date: Tue Aug 3 03:01:43 2004
In-Reply-To: keith@tungstengraphics.com wrote on Tuesday,
3 August 2004 at 09:06:12 +0100
<16654.18932.755325.937060@xf11.fra.suse.de>
<16655.14480.409961.819294@xf11.fra.suse.de>
<410F4774.8090201@tungstengraphics.com>
Keith Whitwell writes:
> Egbert Eich wrote:
>
> It's interesting to see X.org work this problem through. One thing that
> strikes me about the process is that people here are bending over backwards t
o
> avoid suprising the user, which is laudable. What strikes me is that we
> aren't getting the same support from our 'upstream' projects - while there ha
s
> been some flamage within X.org, I can't help but thinking freetype needs a
> boot up the backside if they really are introducing API changes and binary
> incompatibilities in point releases -- what's going on, what's being done
> about it, who takes responsibility?
>
Keith,
you are right. We have several people here who have interacted with
the freetype folks in the past. Maybe they would volunteer to do
that. I'd also take responsibility however I feel we should first
discuss what we should ask them for and what we can offer to help
them.
It is not easy to always ensure full ABI compatibility. With the
short release cycles of the freetype project there is not much
time to give their code thorough testing.
Cheers,
Egbert.
From alexander.gottwald at s1999.tu-chemnitz.de Tue Aug 3 03:28:02 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Tue Aug 3 03:28:05 2004
In-Reply-To: <1091514894.885.110.camel@leguin>
References: <d3ca5069040802180012992fb2@mail.gmail.com>
<1091514894.885.110.camel@leguin>
Message-ID: <Pine.LNX.4.58.0408031224530.9508@odoaker.hrz.tu-chemnitz.de>
On Mon, 2 Aug 2004, Eric Anholt wrote:
> > If I leave out BuildComposite it builds fine. Is the composite manager
> > just not read to be built yet, or am I missing a step. (I couldn't
> > find anywhere online on steps to build x.org with the new composite
> > manager.
>
> This is why BuildComposite isn't the default. I haven't figured out
> what causes this yet. Note that there are no compositing managers
> (that's the name for a client program using the Composite extension to
> draw the screen) in the tree -- BuildComposite controls the inclusion of
> the extension in the server.
I've got composite to build for cygwin quite easily. But it does crash
the server as soon as compmgr and a client are connected. And after
server reset the color of the gray hatch changed to a new color (blue,
purple, green, pink ...)

bye
ago
--
Alexander.Gottwald@s1999.tu-chemnitz.de
http://www.gotti.org ICQ: 126018723
From Jim.Gettys at hp.com Tue Aug 3 04:56:54 2004
Date: Tue Aug 3 04:57:08 2004
References: <E1BrqB7-0001Ox-Nm@evo.keithp.com>
On Mon, 2004-08-02 at 23:41, Keith Packard wrote:
> Around 3 o'clock on Aug 3, =?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?= wrote:
>
> > I was aiming for a solution that would work with the existing range of
> > input drivers, but if that's not strictly needed, that's cool.
>
We'll need this for network transparent input devices anyway.
- Jim
From kdrive_dev at hotmail.com Tue Aug 3 05:54:41 2004
From: kdrive_dev at hotmail.com (Kdrive Dev)
Date: Tue Aug 3 05:56:45 2004
Subject: [Xorg] Accelerating KDrive via KAA
Message-ID: <BAY8-F84wrblZz02H67000424c1@hotmail.com>
I'm currently trying to write a chunk of kaa code to accelerate blits and
copies. I was wondering if anyone could point me in the right direction for
some documentation as to how to go about this. I'm trying to figure out how
to get pixmaps allocated in an area of memory that the card can access. I
cant seem to divine that from the examples that I have (trident etc.)
This message has some pointers but doesn't let us know how to put pixmaps
where we want them....
http://xfree86.desiato.de/xfree86/pipermail/xpert/2001-May/008548.html
Any help appreciated
George Harker
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
From otaylor at redhat.com Tue Aug 3 06:06:28 2004
Date: Tue Aug 3 06:07:22 2004
<20040730210005.GB25118@fooishbar.org>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
On Tue, 2004-08-03 at 04:27, Egbert Eich wrote:
> Owen Taylor writes:
> > It won't overwrite the distribution's version, no. It *will* cause the
> > person to submit a Pango bug report 6 months from now because configure
> > tests are running against one libfreetype and Pango is linking against
> > the other, or because Pango is linking against one libfreetype and
> > running against the other, or some other weirdness that the user has
> > no chance at all of being able to debug correctly.
> >
>
> Thinking about this issue some more:
>
> In the past FreeType has broken binary compatibility more than once.
> We may be able to help educate them in for the future but we cannot
> change the past.
It should be noted that ftfuncs.c is including *internal* FreeType
headers, and I believe that changes in these headers are what
caused these problems. The main education that the FreeType developers
perhaps need is that if you install internal headers people will use
them.
(Pango also uses internal headers but with implicit acceptance of
the risk that if you upgrade FreeType you may also need to upgrade
Pango.)
> This however means that it is not possible to install a later version
> of libfreetype without requiring that all applications that build on it
> need rebuilding.
In general I don't think that's a problem.
> We agree that installing a different version of libfreetype (with the
> same major version number) into another directory calls for trouble.
>
> There seems to be a consense that linking against libfreetype statically
> is a bad idea as security fixes would require to rebuild any application.
> (Which may have to be done anyway if one chooses to supply fixes by
> providing a later version of the lib).
>
> Effectively this means that it is impossible to build components of
> X on a system with with freetype version x that have a dependency on
> a version y with y > x.
I wouldn't really agree with that. Upgrading a core system library
like FreeType isn't something you want to ask the user to do lightly...
but it could be done.
> This begs the question what we should do:
>
> I can think of three solutions:
>
> 1. We add more ifdefs to support earlier versions of freetype.
> The code can be build against the installed version of the lib
> and nothing needs to be updated.
If you can manage this, this is by far the best. The other thing
I'd strongly advise is figuring out how to avoid using internal
headers in xorg.
> 2. We ask the freetype folks to use ELF symbol versioning to provide
> ABI compatibility to earlier versions. This way FreeType has the
> trouble and we can keep our code relatively clean.
The problem here is changes to internal structures ... not something
that is easily worked around with symbol versioning.
> 3. FreeType bumps the major version number and assures that new versions
> of their lib will provide binary compatibility as long as this major
> version number is in use. This will not solve really solve the problems
> of the past but it allows the user to install a new version of freetype
> and build against it while still keeping the original one for all
> older applications.
I think if you eliminate uses of internal headers in X the FreeType
maintainers will have no trouble guaranteeing compatibility...
The problems I've generally seen with installing new versions of
FreeType aren't backwards compatibility problems but straightforward
problems from having multiple versions of FreeType around. These
are going to occur whether X is installing its copy of FreeType
in /usr/X11R6/lib or the user installs one into /usr/local/lib.
Regards,
Owen
[ I'll certainly loudly oppose the motion if you encourage the FreeType
maintainers to bump the major version number :-). That would be
a horrible pain for distributors ]
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040803/9eb7bc3d/attach
ment.pgp
From krh at bitplanet.net Tue Aug 3 06:05:50 2004
Date: Tue Aug 3 06:07:47 2004
In-Reply-To: <20040803034657.GG17302@fooishbar.org>
References: <410EEF5E.9080701@bitplanet.net> <E1BrqB7-0001Ox-Nm@evo.keithp.com>
<20040803034657.GG17302@fooishbar.org>
Message-ID: <410F8DAE.1060804@bitplanet.net>
Daniel Stone wrote:
> On Mon, Aug 02, 2004 at 08:41:29PM -0700, Keith Packard wrote:
>
>>Yeah, I don't see any reason to continue to support user-level device
>>drivers when few (any?) systems need them any more. If you want hot-plug,
>>then you get to create a reasonable input system. For really broken
>>environments, a user-level process could open the device and submit
>>standard format events through some back-channel.
>
>
> I think the current horrific mess of os-support, random crap strewn
> through imake, and common/ (so-called 'common') is a testament to why we
> should force as much stuff over to the underlying system as possible.
Btw. I have a debrix version of the evdev driver in my archive, it's in
debrix-input-evdev--krh--0.1.
Kristian
From sandmann at daimi.au.dk Tue Aug 3 06:22:48 2004
Date: Tue Aug 3 06:29:11 2004
In-Reply-To: <E1BrlFp-0001EN-ON@evo.keithp.com>
References: <E1BrlFp-0001EN-ON@evo.keithp.com>
Message-ID: <ye865802w5z.fsf@horse06.daimi.au.dk>
Keith Packard <keithp@keithp.com> writes:
> Around 22 o'clock on Aug 2, Soeren Sandmann wrote:
>
> > Would anyone object if I commit a patch to remove the initial
> > checkerboard pattern you see between the time the X server starts up
> > and the ?dm starts drawing the background?
>
> There's already a command line option to select a black background. Do
> you intend something different? Or do you just want that to be the
> default?
Yeah just making that the default, and add a -nobr option that will
get the checkerboard.
S?ren
From alan at lxorguk.ukuu.org.uk Tue Aug 3 05:37:05 2004
Date: Tue Aug 3 06:39:42 2004
In-Reply-To: <ye865802w5z.fsf@horse06.daimi.au.dk>
<ye865802w5z.fsf@horse06.daimi.au.dk>
Why not just do the one line change in gdm instead of changing an X
default and confusing existing setups ?
Date: Tue Aug 3 06:43:16 2004
In-Reply-To: <ye865802w5z.fsf@horse06.daimi.au.dk>
On Tue, 3 Aug 2004, Soeren Sandmann wrote:
> Keith Packard <keithp@keithp.com> writes:
>
> > Around 22 o'clock on Aug 2, Soeren Sandmann wrote:
> >
> > > Would anyone object if I commit a patch to remove the initial
> > > checkerboard pattern you see between the time the X server starts up
> > > and the ?dm starts drawing the background?
> >
> > There's already a command line option to select a black background. Do
> > you intend something different? Or do you just want that to be the
> > default?
>
> Yeah just making that the default, and add a -nobr option that will
> get the checkerboard.
Having only a black screen on errors will give no indication if video setup
failed or xdmcp is just too slow. The gray pattern has always been the first
indication of the running xserver and changing it will only confuse those who
work with X for years.
If some distributation don't want the user to notice the pattern they can
change the Xservers file of xdm (or similar for other dm) and add -br there.
bye
ago
--
Date: Tue Aug 3 06:58:53 2004
In-Reply-To: otaylor@redhat.com wrote on Tuesday,
3 August 2004 at 09:06:28 -0400
<1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
Owen Taylor writes:
> On Tue, 2004-08-03 at 04:27, Egbert Eich wrote:
> > Owen Taylor writes:
> > > It won't overwrite the distribution's version, no. It *will* cause the
> > > person to submit a Pango bug report 6 months from now because configure
> > > tests are running against one libfreetype and Pango is linking against
> > > the other, or because Pango is linking against one libfreetype and
> > > running against the other, or some other weirdness that the user has
> > > no chance at all of being able to debug correctly.
> > >
> >
> > Thinking about this issue some more:
> >
> > In the past FreeType has broken binary compatibility more than once.
> > We may be able to help educate them in for the future but we cannot
> > change the past.
>
> It should be noted that ftfuncs.c is including *internal* FreeType
> headers, and I believe that changes in these headers are what
> caused these problems. The main education that the FreeType developers
> perhaps need is that if you install internal headers people will use
> them.
We removed the dependency on internal headers. However the question
arises what is an internal header. If you install a header in
/usr/include/... it is no longer internal.
>
> (Pango also uses internal headers but with implicit acceptance of
> the risk that if you upgrade FreeType you may also need to upgrade
> Pango.)
This issue should be fixed with the freetype folks. If interfaces are
exposed thru the headers in /usr/include/.. they should not be considered
internally. If one needs the freetype sources (we did prior to X.Org 6.7)
to build because he needs a header file that doesn't get installed,
one should talk to FreeType to make this information public.
That's what Chisato did.
>
> > This however means that it is not possible to install a later version
> > of libfreetype without requiring that all applications that build on it
> > need rebuilding.
>
> In general I don't think that's a problem.
What do you mean?
You don't think it is a problem for the average user if he has to
rebuild half of the packages he has installed.
Or
Normally upgrading of a library like freetype should not be required.
> > Effectively this means that it is impossible to build components of
> > X on a system with with freetype version x that have a dependency on
> > a version y with y > x.
>
> I wouldn't really agree with that. Upgrading a core system library
> like FreeType isn't something you want to ask the user to do lightly...
> but it could be done.
Right. It would be easier if the ABI compatibility issue was resolved.
>
> > This begs the question what we should do:
> >
> > I can think of three solutions:
> >
> > 1. We add more ifdefs to support earlier versions of freetype.
> > The code can be build against the installed version of the lib
> > and nothing needs to be updated.
>
> If you can manage this, this is by far the best. The other thing
> I'd strongly advise is figuring out how to avoid using internal
> headers in xorg.
Then we probably should go further back than 2.1.7 as there are still
many systems installed that use earlier versions of libfreetype.
>
> > 2. We ask the freetype folks to use ELF symbol versioning to provide
> > ABI compatibility to earlier versions. This way FreeType has the
> > trouble and we can keep our code relatively clean.
>
> The problem here is changes to internal structures ... not something
> that is easily worked around with symbol versioning.
Then this begs the question why people have to access internal structures
and why they are exposed thru external headers in the first place.
>
> > 3. FreeType bumps the major version number and assures that new versions
> > of their lib will provide binary compatibility as long as this major
> > version number is in use. This will not solve really solve the problems
> > of the past but it allows the user to install a new version of freetype
> > and build against it while still keeping the original one for all
> > older applications.
>
> I think if you eliminate uses of internal headers in X the FreeType
> maintainers will have no trouble guaranteeing compatibility...
>
> The problems I've generally seen with installing new versions of
> FreeType aren't backwards compatibility problems but straightforward
> problems from having multiple versions of FreeType around. These
> are going to occur whether X is installing its copy of FreeType
> in /usr/X11R6/lib or the user installs one into /usr/local/lib.
>
I can see a problem when the later one is used during build while the
earlier version is used during run time.
The other way around shouldn't be a problem provided the backward
compatibility issue is resolved.
>
> [ I'll certainly loudly oppose the motion if you encourage the FreeType
> maintainers to bump the major version number :-). That would be
> a horrible pain for distributors ]
>
This has happend with other libs before and has forced distributors to
ship old versions of these libs along with the newest ones anyhow.
Cheers,
Egbert.
Date: Tue Aug 3 07:09:54 2004
In-Reply-To: sandmann@daimi.au.dk wrote on , 3 August 2004 at 15:22:48 +0200
Soeren Sandmann writes:
> Keith Packard <keithp@keithp.com> writes:
>
> > Around 22 o'clock on Aug 2, Soeren Sandmann wrote:
> >
> > > Would anyone object if I commit a patch to remove the initial
> > > checkerboard pattern you see between the time the X server starts up
> > > and the ?dm starts drawing the background?
> >
> > There's already a command line option to select a black background. Do
> > you intend something different? Or do you just want that to be the
> > default?
>
> Yeah just making that the default, and add a -nobr option that will
> get the checkerboard.
>
X is usually started from a script (like startx) or from a display manager
which should come with a config file where the Xserver command line can be
specified. So this can easily be fixed there.
It is started as a stand alon binary mostly for debugging purposes, for this
I prefer the checkerboard.
Egbert.
Date: Tue Aug 3 07:45:24 2004
In-Reply-To: cyamauch@a.phys.nagoya-u.ac.jp wrote on Tuesday,
3 August 2004 at 18:32:07 +0900
<16655.21967.413224.662497@xf11.fra.suse.de>
> From: Egbert Eich <eich@suse.de>
> Subject: Re: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no member
named `find_sbit_image'
> Date: Tue, 3 Aug 2004 11:07:27 +0200
>
> > I've applied your patch. It is much nicer.
> > Thanks!
>
> Thank you.
>
> But is version 1.5 broken? Here is a patch for fix:
This was from a patch form Matthieu Herrb. I think it was done
intentionally to get the correct type. Otherwise it would not
make much sense to use a dummy variable there.
Maybe Matthieu can comment on this.
Cheers,
Egbert.
Date: Tue Aug 3 08:06:37 2004
<20040730210005.GB25118@fooishbar.org>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
<16655.39353.293945.865812@xf11.fra.suse.de>
> > On Tue, 2004-08-03 at 04:27, Egbert Eich wrote:
> > > Owen Taylor writes:
> > > > It won't overwrite the distribution's version, no. It *will* cause the
> > > > person to submit a Pango bug report 6 months from now because configur
e
> > > > tests are running against one libfreetype and Pango is linking against
> > > > the other, or because Pango is linking against one libfreetype and
> > > > running against the other, or some other weirdness that the user has
> > > > no chance at all of being able to debug correctly.
> > > >
> > >
> > > Thinking about this issue some more:
> > >
> > > In the past FreeType has broken binary compatibility more than once.
> > > We may be able to help educate them in for the future but we cannot
> > > change the past.
> >
> > It should be noted that ftfuncs.c is including *internal* FreeType
> > headers, and I believe that changes in these headers are what
> > caused these problems. The main education that the FreeType developers
> > perhaps need is that if you install internal headers people will use
> > them.
>
> We removed the dependency on internal headers.
Really? I still see the inclusion in:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/lib/font/FreeType/ftfuncs.c?r
ev=1.5&view=auto
> However the question
> arises what is an internal header. If you install a header in
> /usr/include/... it is no longer internal.
And if you install a header into
/usr/include/freetype2/freetype/internal/?
While I wouldn't recommend installing internal headers, I think if
an application does:

#include FT_INTERNAL_TRUETYPE_TYPES_H
They are definitely asking for trouble.
> > (Pango also uses internal headers but with implicit acceptance of
> > the risk that if you upgrade FreeType you may also need to upgrade
> > Pango.)
>
> This issue should be fixed with the freetype folks. If interfaces are
> exposed thru the headers in /usr/include/.. they should not be considered
> internally. If one needs the freetype sources (we did prior to X.Org 6.7)
> to build because he needs a header file that doesn't get installed,
> one should talk to FreeType to make this information public.
> That's what Chisato did.
The Pango question is a little different - Pango includes a big hunk of
table reading code from FreeType 1 ported to Pango 2. The plan is to get
it back into the FreeType project, but that's a long term thing.
Anyways, not really the subject here...
> > > This however means that it is not possible to install a later version
> > > of libfreetype without requiring that all applications that build on it
> > > need rebuilding.
> >
> > In general I don't think that's a problem.
>
> What do you mean?
> You don't think it is a problem for the average user if he has to
> rebuild half of the packages he has installed.
I don't think that the rebuilding half the packages installed is
will be necessary. FreeType-2.0 => FreeType-2.1 might have required
rebuilding Pango (I don't recall at this point.) I'm pretty sure
we didn't need to rebuild anything else in the distribution.
And no other upgrades of FreeType required rebuilding packages.
[...]
> > > This begs the question what we should do:
> > >
> > > I can think of three solutions:
> > >
> > > 1. We add more ifdefs to support earlier versions of freetype.
> > > The code can be build against the installed version of the lib
> > > and nothing needs to be updated.
> >
> > If you can manage this, this is by far the best. The other thing
> > I'd strongly advise is figuring out how to avoid using internal
> > headers in xorg.
>
> Then we probably should go further back than 2.1.7 as there are still
> many systems installed that use earlier versions of libfreetype.
>
> >
> > > 2. We ask the freetype folks to use ELF symbol versioning to provide
> > > ABI compatibility to earlier versions. This way FreeType has the
> > > trouble and we can keep our code relatively clean.
> >
> > The problem here is changes to internal structures ... not something
> > that is easily worked around with symbol versioning.
>
> Then this begs the question why people have to access internal structures
> and why they are exposed thru external headers in the first place.
Well if you look at why ftfuncs.c is using internal headers, I think
it's because new functionality was written as if it was part of
FreeType - probably so it could be submitted as an addition to FreeType.
We could certainly campaign to have FreeType move more stuff to the
public supported API... to make FreeType a more extensible library.
But I think new functionality is seldom going to be *required* for X,
so a better approach is probably:

- When new functionality is useful, submit a patch to freetype to
add that functionality.
- Add conditionalization to X to use that functionality when
there and fallback when not.
> > > 3. FreeType bumps the major version number and assures that new versions
> > > of their lib will provide binary compatibility as long as this major
> > > version number is in use. This will not solve really solve the problem
s
> > > of the past but it allows the user to install a new version of freetyp
e
> > > and build against it while still keeping the original one for all
> > > older applications.
> >
> > I think if you eliminate uses of internal headers in X the FreeType
> > maintainers will have no trouble guaranteeing compatibility...
> >
> > The problems I've generally seen with installing new versions of
> > FreeType aren't backwards compatibility problems but straightforward
> > problems from having multiple versions of FreeType around. These
> > are going to occur whether X is installing its copy of FreeType
> > in /usr/X11R6/lib or the user installs one into /usr/local/lib.
> >
>
> I can see a problem when the later one is used during build while the
> earlier version is used during run time.
> The other way around shouldn't be a problem provided the backward
> compatibility issue is resolved.
If the mismatch happens the right way, there's no problem. But it
happens the wrong way roughly 50% of the time...
> > [ I'll certainly loudly oppose the motion if you encourage the FreeType
> > maintainers to bump the major version number :-). That would be
> > a horrible pain for distributors ]
> >
>
> This has happend with other libs before and has forced distributors to
> ship old versions of these libs along with the newest ones anyhow.
Yes, but usually major version number changes go along with significant
API changes. A new major version of a library more than doubles the
maintenance for distributions (I have to *backport* fixes to the
old version...). Having that cost for no real gain isn't pretty.
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040803/89cccc54/attach
ment.pgp
Date: Tue Aug 3 08:19:42 2004
On Tue, 2004-08-03 at 08:37, Alan Cox wrote:
> Why not just do the one line change in gdm instead of changing an X
> default and confusing existing setups ?
>
I agree, Alan.
And it preserves a valid way to hold monitor vendors
feet to the fire... The value of this checkerboard
has been quite high in the past... I refused to change it
when Digital's monitors people asked years ago, and the next
generation monitors had decent video amplifiers as a result.
So I think "fixing" this outside the window system makes the
most sense.
- Jim
From andrew at digital-domain.net Tue Aug 3 08:42:16 2004
From: andrew at digital-domain.net (Andrew Clayton)
Date: Tue Aug 3 08:42:25 2004
Message-ID: <1091547736.2238.17.camel@alpha.digital-domain.net>
On Tue, 2004-08-03 at 16:19, Jim Gettys wrote:
> On Tue, 2004-08-03 at 08:37, Alan Cox wrote:
> > Why not just do the one line change in gdm instead of changing an X
> > default and confusing existing setups ?
> >
>
> I agree, Alan.
>
> And it preserves a valid way to hold monitor vendors
> feet to the fire... The value of this checkerboard
> has been quite high in the past... I refused to change it
> when Digital's monitors people asked years ago, and the next
> generation monitors had decent video amplifiers as a result.
>
> So I think "fixing" this outside the window system makes the
> most sense.
> - Jim
>
>
FWIW, I fully agree with this.
Unfortunately it seems that the xorg in FC2 shows a black background
whether given the -br option or not :(.

From carl at personnelware.com Tue Aug 3 09:05:23 2004
Date: Tue Aug 3 09:05:06 2004
Subject: [Xorg] Debian/unstable tinderbox
References: <Pine.LNX.4.43.0407281952160.24109-100000@pilchuck.reedmedia.net>
Message-ID: <0d8501c47973$b25a5180$1e01a8c0@cnt496>
whoever has this box:
cl012-Debian-unstable Linux 2.6.0-test7
needs to install flex
/bin/sh: line 1: flex: command not found
803081339.log
Carl K
----- Original Message -----
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: <xorg@freedesktop.org>
Sent: Wednesday, July 28, 2004 9:56 PM
Subject: Re: [Xorg] Debian/unstable tinderbox
> On Wed, 28 Jul 2004, Jim Gettys wrote:
>
> > We have N versions of *BSD, Linux, Solaris, Cygwin, Darwin etc, on x86,
> > x86-64, Itanium, ARM, Alpha, etc.
>
> I possibly can help with NetBSD and other *BSDs.
>
> I may have overlooked it, but where is the quick
> how-to-get-started-with-tinderbox guide for Xorg?
>
> I don't really know what tinderbox other than what I am beginning to read
> at http://www.mozilla.org/tinderbox.html
>
> NetBSD (as far as I know) doesn't have a packaged tinderbox client.
>
> I also don't see a tinderbox client for FreeBSD (it is not in "ports"
> collection).
>
> Maybe I can package it for others once I find the source ...
>
> Jeremy C. Reed
>
> technical support & remote administration
> http://www.pugetsoundtechnology.com/
>
> _______________________________________________
> xorg mailing list
>
From eich at suse.de Tue Aug 3 09:12:52 2004
From: eich at suse.de (Egbert Eich)
Date: Tue Aug 3 09:14:35 2004
In-Reply-To: cyamauch@a.phys.nagoya-u.ac.jp wrote on Wednesday,
4 August 2004 at 00:08:11 +0900
<16655.41829.679398.704894@xf11.fra.suse.de>
> From: Egbert Eich <eich@pdx.freedesktop.org>
> Subject: Re: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no member
named `find_sbit_image'
> Date: Tue, 3 Aug 2004 16:38:29 +0200
>
> > > But is version 1.5 broken? Here is a patch for fix:
> >
> > This was from a patch form Matthieu Herrb. I think it was done
> > intentionally to get the correct type. Otherwise it would not
> > make much sense to use a dummy variable there.
> > Maybe Matthieu can comment on this.
>
> Basically Matthieu's patch(561) has no problem.
> The problem is your merged patch. It is very easy
> to understand it. See line 1080 and 1081 of version 1.5:
>
Oh, sorry. Stupid me. This was a cut'n paste error.
I've just fixed it.
Thanks!
Egbert.
From gene.heskett at verizon.net Tue Aug 3 09:25:31 2004
From: gene.heskett at verizon.net (Gene Heskett)
Date: Tue Aug 3 09:27:30 2004
In-Reply-To: <1091547736.2238.17.camel@alpha.digital-domain.net>
<1091547736.2238.17.camel@alpha.digital-domain.net>
Message-ID: <200408031225.31892.gene.heskett@verizon.net>
On Tuesday 03 August 2004 11:42, Andrew Clayton wrote:
>On Tue, 2004-08-03 at 16:19, Jim Gettys wrote:
>> On Tue, 2004-08-03 at 08:37, Alan Cox wrote:
>> > Why not just do the one line change in gdm instead of changing
>> > an X default and confusing existing setups ?
>>
>> I agree, Alan.
>>
>> And it preserves a valid way to hold monitor vendors
>> feet to the fire... The value of this checkerboard
>> has been quite high in the past... I refused to change it
>> when Digital's monitors people asked years ago, and the next
>> generation monitors had decent video amplifiers as a result.
>>
>> So I think "fixing" this outside the window system makes the
>> most sense.
>> - Jim
>
>FWIW, I fully agree with this.
>
>Unfortunately it seems that the xorg in FC2 shows a black background
>whether given the -br option or not :(.
>
Ahh, I'm not seeing that pattern here at startx time either. Running a
mostly FC2 system now including your x.org version. Using
kde3.3-beta2 also. Where would I remove the -nobr or whatever that
would enable this. My monitor is, after 10 years, beginning to show
a wee bit of ageing. NEC 5FG, pretty good in its day...
>
>
>
>_______________________________________________
>xorg mailing list
>xorg@freedesktop.org
>http://freedesktop.org/mailman/listinfo/xorg
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
From reed at reedmedia.net Tue Aug 3 09:42:01 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Tue Aug 3 09:42:25 2004
Subject: [Xorg] Debian/unstable tinderbox
In-Reply-To: <0d8501c47973$b25a5180$1e01a8c0@cnt496>
Message-ID: <Pine.LNX.4.43.0408030940380.11735-100000@pilchuck.reedmedia.net>
On Tue, 3 Aug 2004, Carl Karsten wrote:
> whoever has this box:
>
> cl012-Debian-unstable Linux 2.6.0-test7
>
> needs to install flex
>
> /bin/sh: line 1: flex: command not found
> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=49&logfile=200
40803081339.log
You sent that email to me. It is not my box.
Jeremy C. Reed
open source, Unix, *BSD, Linux training
http://www.pugetsoundtechnology.com/
From fcatrin at tuxpan.com Tue Aug 3 09:39:59 2004
From: fcatrin at tuxpan.com (Franco Catrin)
Date: Tue Aug 3 09:44:41 2004
Message-ID: <1091551199.8861.10.camel@shamancito.txp>
El mar, 03-08-2004 a las 11:42, Andrew Clayton escribi?:
> Unfortunately it seems that the xorg in FC2 shows a black background
> whether given the -br option or not :(.
FC2 has a specific patch on xorg-x11 package to remove the checkerboard
background
--
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin/es
From daniel at freedesktop.org Tue Aug 3 09:47:03 2004
Date: Tue Aug 3 09:47:06 2004
<20040730210005.GB25118@fooishbar.org>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
Message-ID: <20040803164703.GM17302@fooishbar.org>
On Tue, Aug 03, 2004 at 10:27:07AM +0200, Egbert Eich wrote:
> > It won't overwrite the distribution's version, no. It *will* cause the
> > person to submit a Pango bug report 6 months from now because configure
> > tests are running against one libfreetype and Pango is linking against
> > the other, or because Pango is linking against one libfreetype and
> > running against the other, or some other weirdness that the user has
> > no chance at all of being able to debug correctly.
> >
>
> Thinking about this issue some more:
>
> In the past FreeType has broken binary compatibility more than once.
> We may be able to help educate them in for the future but we cannot
> change the past.
Right. I think they got the point after 2.1.6/2.1.7, however.
> This however means that it is not possible to install a later version
> of libfreetype without requiring that all applications that build on it
> need rebuilding.
... later than a few versions.
> We agree that installing a different version of libfreetype (with the
> same major version number) into another directory calls for trouble.
Yes.
> There seems to be a consense that linking against libfreetype statically
> is a bad idea as security fixes would require to rebuild any application.
> (Which may have to be done anyway if one chooses to supply fixes by
> providing a later version of the lib).
Yes, and that reasoning is also true for having a separate shared
library, as well.
> Effectively this means that it is impossible to build components of
> X on a system with with freetype version x that have a dependency on
> a version y with y > x.
Yes.
That means that if they have 2.1.6, then it gets built against 2.1.6,
and everyone's happy. If they have 2.1.8, good for them.
> This begs the question what we should do:
>
> I can think of three solutions:
>
> 1. We add more ifdefs to support earlier versions of freetype.
> The code can be build against the installed version of the lib
> and nothing needs to be updated.
Yay, yes.
> 2. We ask the freetype folks to use ELF symbol versioning to provide
> ABI compatibility to earlier versions. This way FreeType has the
> trouble and we can keep our code relatively clean.
(Or stop breaking ABI?)
After 2.1.6/2.1.7, I don't think they're in a hurry to change ABI any
time soon.
> 3. FreeType bumps the major version number and assures that new versions
> of their lib will provide binary compatibility as long as this major
> version number is in use. This will not solve really solve the problems
> of the past but it allows the user to install a new version of freetype
> and build against it while still keeping the original one for all
> older applications.
That would be nifty, but it gets messy. In particular, I think libgal is
already up to soversion 20.x.x or something.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040804/84a16045/attach
ment.pgp
Date: Tue Aug 3 09:50:09 2004
Message-ID: <20040803165008.GN17302@fooishbar.org>
On Tue, Aug 03, 2004 at 04:42:16PM +0100, Andrew Clayton wrote:
> FWIW, I fully agree with this.
>
> Unfortunately it seems that the xorg in FC2 shows a black background
> whether given the -br option or not :(.
Yes, the stipple has been patched out of existence; I think it's been
replaced with a nice easy grey.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040804/8d218ec7/attach
ment.pgp
From gene.heskett at verizon.net Tue Aug 3 09:50:36 2004
Date: Tue Aug 3 09:50:39 2004
In-Reply-To: <1091551199.8861.10.camel@shamancito.txp>
<1091551199.8861.10.camel@shamancito.txp>
On Tuesday 03 August 2004 12:39, Franco Catrin wrote:
>El mar, 03-08-2004 a las 11:42, Andrew Clayton escribi?:
>> Unfortunately it seems that the xorg in FC2 shows a black
>> background whether given the -br option or not :(.
>
>FC2 has a specific patch on xorg-x11 package to remove the
> checkerboard background
Humm, that means we go hold somebody on the fedora-list's feet to the
fire I guess.
Thanks for the advisory.
--
Cheers, Gene
From sandmann at daimi.au.dk Tue Aug 3 09:42:40 2004
Date: Tue Aug 3 10:29:31 2004
In-Reply-To: <200408031225.31892.gene.heskett@verizon.net>
<200408031225.31892.gene.heskett@verizon.net>
Message-ID: <ye8smb4yxz3.fsf@ec07.daimi.au.dk>
Gene Heskett <gene.heskett@verizon.net> writes:
> Ahh, I'm not seeing that pattern here at startx time either. Running a
> mostly FC2 system now including your x.org version. Using
> kde3.3-beta2 also. Where would I remove the -nobr or whatever that
> would enable this. My monitor is, after 10 years, beginning to show
> a wee bit of ageing. NEC 5FG, pretty good in its day...
Well, that's the point. Fedora has a patch to remove the checkerboard,
and I wanted to get it upstream. But it is probably better to just fix
it to use the command line option instead.
S?ren
Date: Tue Aug 3 10:29:43 2004
<16654.18932.755325.937060@xf11.fra.suse.de>
<16655.14480.409961.819294@xf11.fra.suse.de>
<410F4774.8090201@tungstengraphics.com>
<16655.25121.811766.458376@xf11.fra.suse.de>
I think the solution to these problems lay on the shoulders of
both us and Freetype. We've accepted the dependency; it
is incumbent on us to also help in the testing and work
in the freetype project to help the situation.
I think we can/should help the process; by better testing of
Freetype CVS we can help reduce the breakage caused by
unintended changes upstream. I think by working with/in
the freetype project the situation can be improved.
One thing we can/should do is have several of
our tinderbox systems configured to be using freetype CVS
(one 32 bit, one 64 bit); then at least compilation issues
can be discovered before they are shipped, and monitored easily
by Freetype developers (or if freetype prefers, they'd be
welcome to run X tinderclients).
Other sorts of bugs, of course, will remain, but at least
incomptible build situations should't appear to surprise us.
Given the slow release cycle of X in the past and only
occasional testing this approach has not been feasible in
the past; it is now, and we should seize the opportunity.
Note, however, that much this current issue arose mostly because
we asked that the changes be pushed upstream (the interface
used privately to become public), and we flailed around dealing
with whether to support older-rev freetypes.
- Jim
> Keith Whitwell writes:
> > Egbert Eich wrote:
> >
> > It's interesting to see X.org work this problem through. One thing that
> > strikes me about the process is that people here are bending over backwards
to
> > avoid suprising the user, which is laudable. What strikes me is that we
> > aren't getting the same support from our 'upstream' projects - while there
has
> > been some flamage within X.org, I can't help but thinking freetype needs a
> > boot up the backside if they really are introducing API changes and binary
> > incompatibilities in point releases -- what's going on, what's being done
> > about it, who takes responsibility?
> >
>
> Keith,
>
> you are right. We have several people here who have interacted with
> the freetype folks in the past. Maybe they would volunteer to do
> that. I'd also take responsibility however I feel we should first
> discuss what we should ask them for and what we can offer to help
> them.
> It is not easy to always ensure full ABI compatibility. With the
> short release cycles of the freetype project there is not much
> time to give their code thorough testing.
>
> Cheers,
> Egbert.
>
>
>
>
> _______________________________________________
> xorg mailing list
From krahn at niehs.nih.gov Tue Aug 3 11:00:09 2004
From: krahn at niehs.nih.gov (Joe Krahn)
Date: Tue Aug 3 11:00:17 2004
References: <E1BrqB7-0001Ox-Nm@evo.keithp.com>
Message-ID: <410FD2A9.5020105@niehs.nih.gov>
>
My concept is that the back-channel is just the X-server XInput
protocol. That way, one server can be set up to proxy access to a
device on another server, or to a "micro server" that uses the
X-server protocol - assuming that a really bare bones server
with no screens is not too difficult or verbose for just sending
device events.
Also, I think user drivers are still useful if you have a
device not supported by non-Windows OSes. Of course, the newer USB
HID based devices should mean mot things are automatically supported.
Joe Krahn
Date: Tue Aug 3 11:16:52 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure
hasno membernamed `find_sbit_image'
References: <16650.42846.746016.823955@xf11.fra.suse.de><E1BqeEp-0002r9-7o@evo.k
eithp.com><16654.18932.755325.937060@xf11.fra.suse.de><16655.14480.409961.819294
@xf11.fra.suse.de><410F4774.8090201@tungstengraphics.com><16655.25121.811766.458
376@xf11.fra.suse.de>
Message-ID: <0e6501c47986$19e51a80$1e01a8c0@cnt496>
> One thing we can/should do is have several of
> our tinderbox systems configured to be using freetype CVS
> (one 32 bit, one 64 bit); then at least compilation issues
> can be discovered before they are shipped, and monitored easily
> by Freetype developers (or if freetype prefers, they'd be
> welcome to run X tinderclients).
on this box: cfk.w2k.v2-cygwin1.5.1 WINNT 5.0 Clb
export CVSROOT=:pserver:anonymous@cvs.freetype.org:/cvs/freetype
cvs login (pw = anonymous)
cvs checkout freetype2
./configure && make && make install
and back to tindering....
Carl K
From eta at lclark.edu Tue Aug 3 12:20:38 2004
Date: Tue Aug 3 12:20:41 2004
Subject: [Xorg] Accelerating KDrive via KAA
In-Reply-To: <BAY8-F84wrblZz02H67000424c1@hotmail.com>
References: <BAY8-F84wrblZz02H67000424c1@hotmail.com>
On Tue, 2004-08-03 at 05:54, Kdrive Dev wrote:
> I'm currently trying to write a chunk of kaa code to accelerate blits and
> copies. I was wondering if anyone could point me in the right direction for
> some documentation as to how to go about this. I'm trying to figure out how
> to get pixmaps allocated in an area of memory that the card can access. I
> cant seem to divine that from the examples that I have (trident etc.)
>
> This message has some pointers but doesn't let us know how to put pixmaps
> where we want them....
>
> http://xfree86.desiato.de/xfree86/pipermail/xpert/2001-May/008548.html
First of all, be sure that you're working from xserver CVS
(http://xserver.freedesktop.org/), not the old versions of kdrive you
can find in the X.Org or XFree86 trees. Then, don't look at trident,
since it hasn't been updated. The ati driver is the most complete, and
mga and mach64 are pretty close up there. Between those, you should
have good examples of what you need to do.
If you set up the screen like ati, mach64, and mga do, and set
KAA_OFFSCREEN_PIXMAPS, pixmaps will automatically get allocated in
screen memory by kaa and accelerated.
--
Date: Tue Aug 3 12:32:49 2004
In-Reply-To: <410ED7FC.5030401@bitplanet.net>
Hi Kristian,
First, I applaud your wading in and making progress.
But I'm seriously wondering if XAddInputDevice is the
right approach.
Somehow or another, the X server needs to be informed
of new devices, (and their removal to their control).
It might seem natural to do this by extending the X protocol
directly, as you've done. The particular suggestion you've made
has a lot of configuration file specific sorts of information
in it; others have expressed concerns here.
But I'm suspecting this will beg a lot of other questions best
left unasked, particularly around security.
X is generally a priviledged process (currently root
on most Linux systems), and does not run as the user's
protection domain.
So by exposing the device name and/or drivers to clients, there is
an immediate need to deal with security consequences of doing
so. Otherwise, unpriviledged X clients can start playing
nasty games that they should't be able to, by accessing
files/drivers they shouldn't.
Now X in general needs better security than it currently does; but
right now, we don't have the right expertise in the community
to take these on directly. We can probably make some cookie
mechanism work here, if we have to.
But here is an alternative approach, that keeps all this
from being exposed to clients directly and keeps OS independence.
0) The X server listens for new input devices somehow
(say unix domain socket).
1) A new device appears. The systems' hotplug facility
interacts with the user, and determines that the device is
to be assigned to the particular X server for this session
(or every time the system boots).
This also allows the hotplug facility to do lots around
device initialization and configuration, driver loading,
etc; it can be priviledged, change protections, ownership,
etc, on the user's behalf as hotplug generally does.
This device might be local, or remote.
2) Via some protocol over this socket (might be dbus, might be
some other protocol, as simple as the current name/value pairs
used in the current configuration file nightmare), the X server
is told to set up the new input device).
3) If so, after initialization,
the socket associated with the device gets sent to
the X server (via send()), along with some information to allow
the X server to filter the byte stream (or do the right IOCTL's),
via some interface, for delivery of events after the device
has been initialised.
There would likely be three such filters (on Linux):
a) existing serial devices (if we care)
b) evdev devices.
c) remote devices via some (yet to be determined) wire
protocol.
4) The socket closing signals the X server that the device has
gone away.
Events would be sent to (interested) clients notifying them
of new devices coming and going.
The big issue I see is figuring out how device calibration
and configuration should occur; we'd like X UI's to be
buildable to share as much as they can across different
device classes. I need to study the X Input
extension further.
In any case, I'm suspecting that keeping the hotplug
details invisible from clients can avoid many security issues,
and in fact, isn't much harder to implement... The ddx
interface for XInput didn't look all that daunting (as oppossed
to the 10K lines of mess of the serial drivers themselves, for
N different devices)...
- Jim
On Mon, 2004-08-02 at 20:10, Kristian H?gsberg wrote:
> Hi,
>
> I've been doing some work on the XInput hotplug functionality that was
> discussed on this list some weeks ago. I have put a patch in bugzilla,
> http://freedesktop.org/bugzilla/show_bug.cgi?id=971. At this point,
> I've added two requests to XInput:
>
> extern int XAddInputDevice(
> Display* /* display */,
> _Xconst char* /* name */,
> _Xconst char* /* driver */,
> XDeviceOption* /* options */,
> int /* nOptions */
> );
>
>
> extern int XRemoveInputDevice(
> Display* /* display */,
> _Xconst char* /* name */
> );
>
> with
>
> typedef struct {
> char *name;
> char *value;
> } XDeviceOption;
>
>
> The idea is that the arguments given to XAddInputDevice() corresponds to
> the options you can give in an xorg.conf InputDevice section, e.g.
>
> Driver "mouse"
> Option "Protocol" "IMPS/2"
> EndSection
>
> could be configured at runtime from an X client as
>
> XDeviceOption options[] = {
> { "Protocol", "IMPS/2" },
> { "Device", "/dev/input/mice" },
> { "ZAxisMapping", "4 5" },
> };
>
> XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
>
> Which will load the "mouse" driver if it's not already present, and add
> the device "Mouse0".
>
> When a new device is added, a DevicePresenceNotify event is sent to
> interested clients. The event does not contain any information about
> the change, clients should use XListInputDevices() to find out what
> devices are available.
>
> I've also attached a tar-file with a few sample applications: xadddev
> and xrmdev are commandline utils to add and remove input devices,
> get-event demonstrates how to select the DevicePresenceNotify event and
> finally, input-daemon, which is a simple example of how a daemon could
> listen for system hotplug events using HAL and add and remove input
> devices accordingly.
>
> I think it would be cool if we could have this or similar functionality
> in the next release again (i.e. not the one scheduled for August). At
> the moment I guess people are busy with the upcoming release, but I
> would greatly appreciate comments and feedback on this stuff.
>
> Kristian
> _______________________________________________
> xorg mailing list
From sndirsch at suse.de Tue Aug 3 12:31:28 2004
From: sndirsch at suse.de (Stefan Dirsch)
Date: Tue Aug 3 12:58:12 2004
Subject: [Xorg] How to enable Composite extension
Message-ID: <20040803193128.GA25031@suse.de>
Hi
Any hints how to enable Composite extension? I know you can enable it
already with "+extension Composite" command line option but I think
there exists also "Extensions" section to enable/disable extensions
like this.
And where can Composite be enabled by default in the code itself?
Stefan
Public Key available
----------------------------------------------------
Stefan Dirsch (Res. & Dev.) SUSE LINUX AG
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 N?rnberg
http://www.suse.de Germany
----------------------------------------------------
From svetljo at gmx.de Tue Aug 3 13:12:16 2004
From: svetljo at gmx.de (Svetoslav Slavtchev)
Date: Tue Aug 3 13:12:22 2004
References: <20040803193128.GA25031@suse.de>
Message-ID: <32270.1091563936@www52.gmx.net>
> Hi
>
> Any hints how to enable Composite extension? I know you can enable it
> already with "+extension Composite" command line option but I think
> there exists also "Extensions" section to enable/disable extensions
> like this.
add smth like this :
Section "Extensions"
# Option "XEVIE" "Enable"
# Option "Composite" "Enable"
# Option "Composite" "Disable"
EndSection
> And where can Composite be enabled by default in the code itself?
no idea,
but i wouldn't do it for now
here X wont start with it enabled
best,
svetljo
--
NEU: WLAN-Router fr 0,- EUR* - auch fr DSL-Wechsler!
GMX DSL = supergnstig & kabellos http://www.gmx.net/de/go/dsl
Date: Tue Aug 3 13:17:53 2004
Subject: [Xorg] graphics driver binary compatibilty broken again ...
Hi
Looks like the graphics driver binary compatibility has been broken
again. nvidia driver cannot be started any more. :-(
More details: Bug #976
--> http://freedesktop.org/bugzilla/show_bug.cgi?id=976
Stefan
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
From dominatus at gmail.com Tue Aug 3 13:33:43 2004
Date: Tue Aug 3 13:33:46 2004
In-Reply-To: <32270.1091563936@www52.gmx.net>
References: <20040803193128.GA25031@suse.de> <32270.1091563936@www52.gmx.net>
Message-ID: <d3ca506904080313333db1e254@mail.gmail.com>
I've gotten it to start with GNOME, but the xcompmgr program crashes
the server (It starts up but then freezes everything, all keys lock up
and a reboot is required) With Enlightenment, the server crashes with
just the extension enabled.
On Tue, 3 Aug 2004 22:12:16 +0200 (MEST), Svetoslav Slavtchev
<svetljo@gmx.de> wrote:
> > Hi
> >
> > Any hints how to enable Composite extension? I know you can enable it
> > already with "+extension Composite" command line option but I think
> > there exists also "Extensions" section to enable/disable extensions
> > like this.
>
> add smth like this :
> Section "Extensions"
> # Option "XEVIE" "Enable"
> # Option "Composite" "Enable"
> # Option "Composite" "Disable"
> EndSection
>
>
> > And where can Composite be enabled by default in the code itself?
>
> no idea,
> but i wouldn't do it for now
> here X wont start with it enabled
>
> best,
>
> svetljo
>
> --
> NEU: WLAN-Router f?r 0,- EUR* - auch f?r DSL-Wechsler!
> GMX DSL = superg?nstig & kabellos http://www.gmx.net/de/go/dsl
>
>
>
> _______________________________________________
> xorg mailing list
>
Date: Tue Aug 3 13:33:53 2004
In-Reply-To: <32270.1091563936@www52.gmx.net>
On Tue, Aug 03, 2004 at 10:12:16PM +0200, Svetoslav Slavtchev wrote:
> > Hi
> >
> > Any hints how to enable Composite extension? I know you can enable it
> > already with "+extension Composite" command line option but I think
> > there exists also "Extensions" section to enable/disable extensions
> > like this.
>
> add smth like this :
> # Option "XEVIE" "Enable"
> # Option "Composite" "Enable"
> # Option "Composite" "Disable"
> EndSection
Hmm ... this only works for XEVIE.
Option "XEVIE" "Disable"
Option "Composite" "Enable"
EndSection
(==) Using config file: "/etc/X11/XF86Config"
(EE) Extension "Composite" is unrecognized
Problem when converting the config data structures
(EE) Error parsing the config file
> > And where can Composite be enabled by default in the code itself?
>
> no idea,
> but i wouldn't do it for now
> here X wont start with it enabled
Did work for me when using "+extension Composite" command line option.
Stefan
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
From keithp at keithp.com Tue Aug 3 13:44:14 2004
Date: Tue Aug 3 13:44:37 2004
In-Reply-To: Your message of "Tue, 03 Aug 2004 14:00:09 EDT."
<410FD2A9.5020105@niehs.nih.gov>
Message-ID: <E1Bs68s-0001un-P8@evo.keithp.com>
Around 14 o'clock on Aug 3, Joe Krahn wrote:
> Also, I think user drivers are still useful if you have a
> device not supported by non-Windows OSes. Of course, the newer USB
> HID based devices should mean mot things are automatically supported.
You have to write a driver in either case. Just write a kernel-mode
driver instead of a user-mode one. I don't know of any significant X.org
environments that can't add kernel modules any more.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040803/fc000502/attach
ment.pgp
From krh at bitplanet.net Tue Aug 3 14:48:28 2004
Date: Tue Aug 3 14:50:27 2004
Message-ID: <4110082C.8090908@bitplanet.net>
Jim Gettys wrote:
> Hi Kristian,
>
> First, I applaud your wading in and making progress.
>
> But I'm seriously wondering if XAddInputDevice is the
> right approach.
This was mostly to get the ball rolling and see that it could be done.
> Somehow or another, the X server needs to be informed
> of new devices, (and their removal to their control).
>
> It might seem natural to do this by extending the X protocol
> directly, as you've done. The particular suggestion you've made
> has a lot of configuration file specific sorts of information
> in it; others have expressed concerns here.
>
> But I'm suspecting this will beg a lot of other questions best
> left unasked, particularly around security.
>
> X is generally a priviledged process (currently root
> on most Linux systems), and does not run as the user's
> protection domain.
>
> So by exposing the device name and/or drivers to clients, there is
> an immediate need to deal with security consequences of doing
> so. Otherwise, unpriviledged X clients can start playing
> nasty games that they should't be able to, by accessing
> files/drivers they shouldn't.
>
> Now X in general needs better security than it currently does; but
> right now, we don't have the right expertise in the community
> to take these on directly. We can probably make some cookie
> mechanism work here, if we have to.
Right, I'm not particularly attached to the approach that I've taken and
I realize that it's problematic letting any user with display access ask
the server to open any file. Another thing, which Alan also mentioned,
is that it's difficult to do this in an implementation independent
manner. Even if you can standardize on what arguments to pass to the
XAddInputDevice() call, the meaning of those arguments will be server
specific (e.g. what drivers are available, what options do they support
etc.) A hotplug daemon that want's to support several server
implementation will have different code paths for each server it supports.
> But here is an alternative approach, that keeps all this
> from being exposed to clients directly and keeps OS independence.
>
> 0) The X server listens for new input devices somehow
> (say unix domain socket).
>
> 1) A new device appears. The systems' hotplug facility
> interacts with the user, and determines that the device is
> to be assigned to the particular X server for this session
> (or every time the system boots).
>
> This also allows the hotplug facility to do lots around
> device initialization and configuration, driver loading,
> etc; it can be priviledged, change protections, ownership,
> etc, on the user's behalf as hotplug generally does.
>
> This device might be local, or remote.
>
> 2) Via some protocol over this socket (might be dbus, might be
> some other protocol, as simple as the current name/value pairs
> used in the current configuration file nightmare), the X server
> is told to set up the new input device).
D-BUS doesn't let you pass file descriptors, so I guess that's out.
> 3) If so, after initialization,
> the socket associated with the device gets sent to
> the X server (via send()), along with some information to allow
> the X server to filter the byte stream (or do the right IOCTL's),
> via some interface, for delivery of events after the device
> has been initialised.
>
> There would likely be three such filters (on Linux):
> a) existing serial devices (if we care)
> b) evdev devices.
> c) remote devices via some (yet to be determined) wire
> protocol.
Wouldn't it be better to do 2 and 3 in one go, i.e. send a request
saying "setup a new input device, use this filter, use this fd". That
avoids state in the protocol and makes the whole setup simpler.
> 4) The socket closing signals the X server that the device has
> gone away.
I like this idea, I think you described something similar at GUADEC.
As I understand your suggestion, the access to the servers hotplug
socket is unpriviledged and security is enforced by letting the user
open the device file.
So we should try to figure out what kind of interface the server should
expose on this local socket and what kind of protocol to use. I can't
see that we would need anything more than add device and remove device
requests. The add device request passes the fd, the name of the filter
to use, and possibly a set of options for that filter.
> Events would be sent to (interested) clients notifying them
> of new devices coming and going.
Yes, I have this bit in the patch also. You select the
DevicePresenceNotify event using the XInput XSelectExtensionEvent().
> The big issue I see is figuring out how device calibration
> and configuration should occur; we'd like X UI's to be
> buildable to share as much as they can across different
> device classes. I need to study the X Input
> extension further.
For configuring devices, there are two mechanisms: feedbacks and device
controls, and I must admit I'm not sure what the difference is. They
both allow clients to change behaivour of a device that you've opened
with XOpenDevice().
> In any case, I'm suspecting that keeping the hotplug
> details invisible from clients can avoid many security issues,
> and in fact, isn't much harder to implement... The ddx
> interface for XInput didn't look all that daunting (as oppossed
> to the 10K lines of mess of the serial drivers themselves, for
> N different devices)...
I dont think it'll be harder to implement either, it's just that
initially I wanted to avoid making up another protocol but rather use
the existing X protocol.
Kristian
>
> - Jim
>
>
>
>
> On Mon, 2004-08-02 at 20:10, Kristian H?gsberg wrote:
>
>>Hi,
>>
>>I've been doing some work on the XInput hotplug functionality that was
>>discussed on this list some weeks ago. I have put a patch in bugzilla,
>>http://freedesktop.org/bugzilla/show_bug.cgi?id=971. At this point,
>>I've added two requests to XInput:
>>
>> extern int XAddInputDevice(
>> Display* /* display */,
>> _Xconst char* /* name */,
>> _Xconst char* /* driver */,
>> XDeviceOption* /* options */,
>> int /* nOptions */
>> );
>>
>>
>> extern int XRemoveInputDevice(
>> Display* /* display */,
>> _Xconst char* /* name */
>> );
>>
>>with
>>
>> typedef struct {
>> char *name;
>> char *value;
>> } XDeviceOption;
>>
>>
>>The idea is that the arguments given to XAddInputDevice() corresponds to
>>the options you can give in an xorg.conf InputDevice section, e.g.
>>
>> Section "InputDevice"
>> Identifier "Mouse0"
>> Driver "mouse"
>> Option "Protocol" "IMPS/2"
>> Option "Device" "/dev/input/mice"
>> Option "ZAxisMapping" "4 5"
>> EndSection
>>
>>could be configured at runtime from an X client as
>>
>> XDeviceOption options[] = {
>> { "Protocol", "IMPS/2" },
>> { "Device", "/dev/input/mice" },
>> { "ZAxisMapping", "4 5" },
>> };
>>
>> XAddInputDevice(dpy, "Mouse0", "mouse", options, 3);
>>
>>Which will load the "mouse" driver if it's not already present, and add
>>the device "Mouse0".
>>
>>When a new device is added, a DevicePresenceNotify event is sent to
>>interested clients. The event does not contain any information about
>>the change, clients should use XListInputDevices() to find out what
>>devices are available.
>>
>>I've also attached a tar-file with a few sample applications: xadddev
>>and xrmdev are commandline utils to add and remove input devices,
>>get-event demonstrates how to select the DevicePresenceNotify event and
>>finally, input-daemon, which is a simple example of how a daemon could
>>listen for system hotplug events using HAL and add and remove input
>>devices accordingly.
>>
>>I think it would be cool if we could have this or similar functionality
>>in the next release again (i.e. not the one scheduled for August). At
>>the moment I guess people are busy with the upcoming release, but I
>>would greatly appreciate comments and feedback on this stuff.
>>
>>Kristian
>>_______________________________________________
>>xorg mailing list
>>xorg@freedesktop.org
>>http://freedesktop.org/mailman/listinfo/xorg
>
>
>
Date: Tue Aug 3 17:25:46 2004
In-Reply-To: <4110082C.8090908@bitplanet.net>
<4110082C.8090908@bitplanet.net>
On Tue, 2004-08-03 at 17:48, Kristian H?gsberg wrote:
> Jim Gettys wrote:
> > Hi Kristian,
> >
> > First, I applaud your wading in and making progress.
> >
> > But I'm seriously wondering if XAddInputDevice is the
> > right approach.
>
> This was mostly to get the ball rolling and see that it could be done.
>
> > Somehow or another, the X server needs to be informed
> > of new devices, (and their removal to their control).
> >
> > It might seem natural to do this by extending the X protocol
> > directly, as you've done. The particular suggestion you've made
> > has a lot of configuration file specific sorts of information
> > in it; others have expressed concerns here.
> >
> > But I'm suspecting this will beg a lot of other questions best
> > left unasked, particularly around security.
> >
> > X is generally a priviledged process (currently root
> > on most Linux systems), and does not run as the user's
> > protection domain.
> >
> > So by exposing the device name and/or drivers to clients, there is
> > an immediate need to deal with security consequences of doing
> > so. Otherwise, unpriviledged X clients can start playing
> > nasty games that they should't be able to, by accessing
> > files/drivers they shouldn't.
> >
> > Now X in general needs better security than it currently does; but
> > right now, we don't have the right expertise in the community
> > to take these on directly. We can probably make some cookie
> > mechanism work here, if we have to.
>
> Right, I'm not particularly attached to the approach that I've taken and
> I realize that it's problematic letting any user with display access ask
> the server to open any file. Another thing, which Alan also mentioned,
> is that it's difficult to do this in an implementation independent
> manner. Even if you can standardize on what arguments to pass to the
> XAddInputDevice() call, the meaning of those arguments will be server
> specific (e.g. what drivers are available, what options do they support
> etc.) A hotplug daemon that want's to support several server
> implementation will have different code paths for each server it supports.
>
> > But here is an alternative approach, that keeps all this
> > from being exposed to clients directly and keeps OS independence.
> >
> > 0) The X server listens for new input devices somehow
> > (say unix domain socket).
> >
> > 1) A new device appears. The systems' hotplug facility
> > interacts with the user, and determines that the device is
> > to be assigned to the particular X server for this session
> > (or every time the system boots).
> >
> > This also allows the hotplug facility to do lots around
> > device initialization and configuration, driver loading,
> > etc; it can be priviledged, change protections, ownership,
> > etc, on the user's behalf as hotplug generally does.
> >
> > This device might be local, or remote.
> >
> > 2) Via some protocol over this socket (might be dbus, might be
> > some other protocol, as simple as the current name/value pairs
> > used in the current configuration file nightmare), the X server
> > is told to set up the new input device).
>
> D-BUS doesn't let you pass file descriptors, so I guess that's out.
No, I don't think it is an issue here.
I'm thinking of the case to allow the design to deal with new
device types.
If you look at the porting document for XInput, it looks as though
the X server can be educated about pretty arbitrary input devices, with
pretty arbitrary combinations of keys, buttons, locators, displays,
etc...
It is an incremental process.
You say: Here's a new device.
It has some buttons,
it has some keys,
it has N axes,
and so on....
to allow pretty arbitrary devices to be described. I'm actually
reasonably impressed at the ideas behind the design.
I don't understand how to do this in a one step process.
> > 3) If so, after initialization,
> > the socket associated with the device gets sent to
> > the X server (via send()), along with some information to allow
> > the X server to filter the byte stream (or do the right IOCTL's),
> > via some interface, for delivery of events after the device
> > has been initialised.
> >
> > There would likely be three such filters (on Linux):
> > a) existing serial devices (if we care)
> > b) evdev devices.
> > c) remote devices via some (yet to be determined) wire
> > protocol.
>
> Wouldn't it be better to do 2 and 3 in one go, i.e. send a request
> saying "setup a new input device, use this filter, use this fd". That
> avoids state in the protocol and makes the whole setup simpler.
To set up a device, we may have to do a whole sequence of
operations. E.g.
a) load the correct device driver
b) set it into a known sane state
It isn't clear to me that we want both/either of those in
the module loaded into the X server.
So we can let hotplug get things into a state that
X can use, and, rather than X having to reopen the device,
and thereby potentially have to reinitialize it, pass the
file descriptor to the X server when it is ready to go.
If you detect the idea to keep as little as possible in the
X server, you're right.
This is analogous to the work we want to do to get display
mode setting *out* of the X server.
>
> > 4) The socket closing signals the X server that the device has
> > gone away.
>
> I like this idea, I think you described something similar at GUADEC.
> As I understand your suggestion, the access to the servers hotplug
> socket is unpriviledged and security is enforced by letting the user
> open the device file.
>
> So we should try to figure out what kind of interface the server should
> expose on this local socket and what kind of protocol to use. I can't
> see that we would need anything more than add device and remove device
> requests. The add device request passes the fd, the name of the filter
> to use, and possibly a set of options for that filter.
It is the setup of new devices where the interface has to be reasonably
rich; or you can't support arbitrary devices.
>
> > Events would be sent to (interested) clients notifying them
> > of new devices coming and going.
>
> Yes, I have this bit in the patch also. You select the
> DevicePresenceNotify event using the XInput XSelectExtensionEvent().
>
> > The big issue I see is figuring out how device calibration
> > and configuration should occur; we'd like X UI's to be
> > buildable to share as much as they can across different
> > device classes. I need to study the X Input
> > extension further.
>
> For configuring devices, there are two mechanisms: feedbacks and device
> controls, and I must admit I'm not sure what the difference is. They
> both allow clients to change behaivour of a device that you've opened
> with XOpenDevice().
Yeah, I have to scratch my head some. It also looks like some stuff
is missing (e.g. control for force feedback joysticks.
>
> > In any case, I'm suspecting that keeping the hotplug
> > details invisible from clients can avoid many security issues,
> > and in fact, isn't much harder to implement... The ddx
> > interface for XInput didn't look all that daunting (as oppossed
> > to the 10K lines of mess of the serial drivers themselves, for
> > N different devices)...
>
> I dont think it'll be harder to implement either, it's just that
> initially I wanted to avoid making up another protocol but rather use
> the existing X protocol.
>
Yup.
From zakki at peppermint.jp Tue Aug 3 18:31:57 2004
From: zakki at peppermint.jp (Kensuke Matsuzaki)
Date: Tue Aug 3 18:31:48 2004
Subject: [Xorg] [PATCH] Japanese ctext conversion bug fix patch
In-Reply-To: <7jshll4x.wl%zakki@peppermint.jp>
References: <7jshll4x.wl%zakki@peppermint.jp>
Message-ID: <657zlmcy.wl%zakki@peppermint.jp>
This compound text bug appears if X_LOCALE is defined.
With Cygwin/X, XIM is broken because of this. And also that causes
Cygwin/X's clipbord integration problem in Japanese environment.
--
Kensuke Matsuzaki
mailto:zakki@peppermint.jp
http://peppermint.jp
From bbarnich at umich.edu Tue Aug 3 20:07:03 2004
From: bbarnich at umich.edu (Brad Barnich)
Date: Tue Aug 3 20:17:29 2004
In-Reply-To: <ye8smb4yxz3.fsf@ec07.daimi.au.dk>
<ye8smb4yxz3.fsf@ec07.daimi.au.dk>
Message-ID: <5C1E0DCC-E5C3-11D8-AE2D-000D93291E48@umich.edu>
Why does the average Joe User need to see the checkboard. Its more like
a test pattern for geeks or troubleshooters only. Notice you don't see
the checkboard in windows or mac systems. Those systems run perfectly
fine. Is that correct or am I missing something.
Brad Barnich
On Aug 3, 2004, at 12:42 PM, Soeren Sandmann wrote:
> Gene Heskett <gene.heskett@verizon.net> writes:
>
>> Ahh, I'm not seeing that pattern here at startx time either. Running a
>> mostly FC2 system now including your x.org version. Using
>> kde3.3-beta2 also. Where would I remove the -nobr or whatever that
>> would enable this. My monitor is, after 10 years, beginning to show
>> a wee bit of ageing. NEC 5FG, pretty good in its day...
>
> Well, that's the point. Fedora has a patch to remove the checkerboard,
> and I wanted to get it upstream. But it is probably better to just fix
> it to use the command line option instead.
>
>
> S?ren
> _______________________________________________
> xorg mailing list
From ajax at nwnk.net Tue Aug 3 20:29:42 2004
Date: Tue Aug 3 20:29:51 2004
In-Reply-To: <5C1E0DCC-E5C3-11D8-AE2D-000D93291E48@umich.edu>
<5C1E0DCC-E5C3-11D8-AE2D-000D93291E48@umich.edu>
Hash: SHA1
On Tuesday 03 August 2004 23:07, Brad Barnich wrote:
> Why does the average Joe User need to see the checkboard. Its more like
> a test pattern for geeks or troubleshooters only. Notice you don't see
> the checkboard in windows or mac systems. Those systems run perfectly
> fine. Is that correct or am I missing something.
Windows and Mac systems initialize the screen to solid colors. The X stipple
isn't too far removed from the bootup gray screen of MacOS <=9.
- - ajax
iD8DBQFBEFgnW4otUKDs0NMRAlSjAJ0Z2cQ2t7e5nf8e51p17T9GH1X00gCgp3QW
Y7FUVsO7NWl/F7uSksOLBoY=
=Bhy+
From jserv at linux2.cc.ntu.edu.tw Wed Aug 4 02:22:43 2004
From: jserv at linux2.cc.ntu.edu.tw (jserv@linux2.cc.ntu.edu.tw)
Date: Wed Aug 4 02:22:49 2004
Subject: [Xorg] xkb support in kdrive.
Message-ID: <20040804092243.GA21007@linux2.cc.ntu.edu.tw>
Hi all,
I cvs checkout, and I found that I failed to build kdrive again.
The ChangeLog shows:
2004-07-28 Daniel Stone <daniel@freedesktop.org>
* configure.ac:
* hw/Makefile.am:
It's official - Xizzle is dead code. hw/xorg has been moved to
/cvs/xserver/DEAD/xorg; all traces of it have been removed from
xserver.
But I noticed that the content in xkb/Makefile.am contains:
M_CFLAGS = -DXKB_DFLT_DISABLED=0 -DXKB_IN_SERVER \
-DXKB_BASE_DIRECTORY=\"$(LIBDIR)/xkb\" -DXKB
INCLUDES = $(XORG_INCS) $(KDRIVE_INCS) -I$(srcdir)/../mi
-I$(srcdir)/../hw/xorg/common \
-I$(srcdir)/../hw/xorg/include
-I$(srcdir)/../hw/xorg/os-support/bus
So that, how can I build KDrive? Should I check out xorg from the old
/cvs/xserver/DEAD/xorg?
Thanks,
Jim Huang
From daniel at freedesktop.org Wed Aug 4 02:28:00 2004
Date: Wed Aug 4 02:28:03 2004
In-Reply-To: <20040804092243.GA21007@linux2.cc.ntu.edu.tw>
References: <20040804092243.GA21007@linux2.cc.ntu.edu.tw>
Message-ID: <20040804092800.GC8627@fooishbar.org>
On Wed, Aug 04, 2004 at 05:22:43PM +0800, jserv@linux2.cc.ntu.edu.tw wrote:
> I cvs checkout, and I found that I failed to build kdrive again.
> The ChangeLog shows:
>
> 2004-07-28 Daniel Stone <daniel@freedesktop.org>
>
> * configure.ac:
> * hw/Makefile.am:
> It's official - Xizzle is dead code. hw/xorg has been moved to
> /cvs/xserver/DEAD/xorg; all traces of it have been removed from
> xserver.
>
> But I noticed that the content in xkb/Makefile.am contains:
>
> M_CFLAGS = -DXKB_DFLT_DISABLED=0 -DXKB_IN_SERVER \
> -DXKB_BASE_DIRECTORY=\"$(LIBDIR)/xkb\" -DXKB
> INCLUDES = $(XORG_INCS) $(KDRIVE_INCS) -I$(srcdir)/../mi
> -I$(srcdir)/../hw/xorg/common \
> -I$(srcdir)/../hw/xorg/include
> -I$(srcdir)/../hw/xorg/os-support/bus
>
> So that, how can I build KDrive? Should I check out xorg from the old
> /cvs/xserver/DEAD/xorg?
... don't use XKB.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040804/d215572f/attach
ment.pgp
From eich at pdx.freedesktop.org Wed Aug 4 02:50:01 2004
Date: Wed Aug 4 02:53:23 2004
In-Reply-To: bbarnich@umich.edu wrote on Tuesday,
3 August 2004 at 23:07:03 -0400
Brad Barnich writes:
>
Why does Joe User have to see the checkerboard?
If the display manager are configured right and startx
is patched so that the Xserver receives the -bg option
he will never get to see it.
Besides, the checkerboard has prooven to be useful to
adjust flat panels and projectors.
Egbert.
From carl at personnelware.com Wed Aug 4 03:24:01 2004
Date: Wed Aug 4 03:24:07 2004
References: <E1BrlFp-0001EN-ON@evo.keithp.com><ye8smb4yxz3.fsf@ec07.daimi.au.dk>
<200408032329.45521.ajax@nwnk.net>
Message-ID: <114b01c47a0d$347bf940$1e01a8c0@cnt496>
No system runs perfectly. Not even my atari 2600. Espically windows. Mac,
maybe, but I doubt that there isn't a mac somewhere that is having a problem.
That is when diagnostics are realy nice, and not having them is really bad. Not
that a pattern fixes everything, but it is one little piece.
And I am now guilty of commenting about something that has been talked about way
too much.
There is a switch, it can be used.
When everythign else is done, and there is nothing left to talk about, then
perhaps this subject can be discussed more. Maybe mankind has something to
learn from such a great debate. Future generations can read about it in history
class, including the dark ages when there where those that didn't think it was
important.
Carl K
From rasa at gmx.ch Wed Aug 4 03:34:46 2004
From: rasa at gmx.ch (Raffaele Sandrini)
Date: Wed Aug 4 03:34:42 2004
Subject: [Xorg] Contrast problems using the radeon driver
In-Reply-To: <1091478828.7335.8.camel@uranos.rnt.ch>
References: <1091478828.7335.8.camel@uranos.rnt.ch>
Message-ID: <1091615685.3285.3.camel@uranos.rnt.ch>
On Mon, 2004-08-02 at 22:33, Raffaele Sandrini wrote:
> Hi
>
> I used the xorg radeon driver for my Radeon 9600XT without problems till
> i switched to a 2 screen env (using Xinerama). Now, the primary screen
> shows up with a very weak contrast (i.e. the GNOME 2.6 splash screen is
> completly while in the background). The second screen works perfectly.
>
> I first though its a hw prob so i switched monitors. Since the contrast
> problem didn't switch to (stayed on the new primary screen) i thought
> its a problem of my graphic hardware. To test that i startet up WinXP
> and it worked perfect there (with a Catalyst installed). The picture was
> perfect (except of the content :)). So its finally seems to be a sw
> problem... I actually never tried it with the binary radeon driver yet.
>
> Is this known to any one here?
>
Seems noone has seen that problem...
I tried the binary (fglrx) driver by ATI. The picture is perfect there.
It seems that ATI keeps some details about multi-head in secret :).
cheers,
Raffaele
From eich at pdx.freedesktop.org Wed Aug 4 03:42:40 2004
Date: Wed Aug 4 03:43:56 2004
In-Reply-To: otaylor@redhat.com wrote on Tuesday,
3 August 2004 at 11:05:36 -0400
<1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
<16655.39353.293945.865812@xf11.fra.suse.de>
Owen Taylor writes:
> >
> > We removed the dependency on internal headers.
>
> Really? I still see the inclusion in:
>
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/lib/font/FreeType/ftfuncs.
c?rev=1.5&view=auto
>
OK, you seem to be referring to:
#include FT_INTERNAL_TRUETYPE_TYPES_H
#include FT_INTERNAL_SFNT_H
#include FT_INTERNAL_STREAM_H
The last one at least doesn't seem to be required.
The question arises how private those headers are.
> > However the question
> > arises what is an internal header. If you install a header in
> > /usr/include/... it is no longer internal.
>
> And if you install a header into
> /usr/include/freetype2/freetype/internal/?
>
> While I wouldn't recommend installing internal headers, I think if
> an application does:
>
> #include FT_INTERNAL_TRUETYPE_TYPES_H
>
> They are definitely asking for trouble.
So why are these headers installed, then?
I think saying "well, these are not really ment to be public
so we reserve the right to change them but application may still find
them useful" calls for trouble.
>
> > > (Pango also uses internal headers but with implicit acceptance of
> > > the risk that if you upgrade FreeType you may also need to upgrade
> > > Pango.)
> >
> > This issue should be fixed with the freetype folks. If interfaces are
> > exposed thru the headers in /usr/include/.. they should not be considered
> > internally. If one needs the freetype sources (we did prior to X.Org 6.7)
> > to build because he needs a header file that doesn't get installed,
> > one should talk to FreeType to make this information public.
> > That's what Chisato did.
>
> The Pango question is a little different - Pango includes a big hunk of
> table reading code from FreeType 1 ported to Pango 2. The plan is to get
> it back into the FreeType project, but that's a long term thing.
> Anyways, not really the subject here...
Right. We should do the same thing and supply a patch freetype that
makes it public.
It won't help us to fix the past, though, but we can fix the past
by adding backward compatibility #ifdefs. Knowing that we will
not have to clutter the code with these for an unforseeable future
helps to justify them.
[...]
>
> I don't think that the rebuilding half the packages installed is
> will be necessary. FreeType-2.0 => FreeType-2.1 might have required
> rebuilding Pango (I don't recall at this point.) I'm pretty sure
> we didn't need to rebuild anything else in the distribution.
> And no other upgrades of FreeType required rebuilding packages.
Appearantly there was a problem between 2.1.6 and 2.1.7 and there
are indications that there also is a problem between 2.1.7 and 2.1.8.
>
> [...]
>
[...]
> >
> > Then this begs the question why people have to access internal structures
> > and why they are exposed thru external headers in the first place.
>
> Well if you look at why ftfuncs.c is using internal headers, I think
> it's because new functionality was written as if it was part of
> FreeType - probably so it could be submitted as an addition to FreeType.
>
> We could certainly campaign to have FreeType move more stuff to the
> public supported API... to make FreeType a more extensible library.
> But I think new functionality is seldom going to be *required* for X,
> so a better approach is probably:
>
> - When new functionality is useful, submit a patch to freetype to
> add that functionality.
> - Add conditionalization to X to use that functionality when
> there and fallback when not.
Right.
[...]
> >
> > I can see a problem when the later one is used during build while the
> > earlier version is used during run time.
> > The other way around shouldn't be a problem provided the backward
> > compatibility issue is resolved.
>
> If the mismatch happens the right way, there's no problem. But it
> happens the wrong way roughly 50% of the time...
>
> > > [ I'll certainly loudly oppose the motion if you encourage the FreeType
> > > maintainers to bump the major version number :-). That would be
> > > a horrible pain for distributors ]
> > >
> >
> > This has happend with other libs before and has forced distributors to
> > ship old versions of these libs along with the newest ones anyhow.
>
> Yes, but usually major version number changes go along with significant
> API changes. A new major version of a library more than doubles the
> maintenance for distributions (I have to *backport* fixes to the
> old version...). Having that cost for no real gain isn't pretty.
>
OK, that's definitely annoying. But how often does it happen that
a patch is importand enough to be backported to an older version?
Cheers,
Egbert.
Date: Wed Aug 4 04:05:03 2004
References: <20040730210005.GB25118@fooishbar.org> <410AB7F2.2090802@sun.com>
<1091221747.43156.15.camel@leguin>
<16654.11636.55368.324651@xf11.fra.suse.de>
<16655.19547.343108.906285@xf11.fra.suse.de>
<16655.39353.293945.865812@xf11.fra.suse.de>
<16656.48544.499975.419805@xf14.fra.suse.de>
Message-ID: <20040804110500.GE8627@fooishbar.org>
On Wed, Aug 04, 2004 at 12:42:40PM +0200, Egbert Eich wrote:
> So why are these headers installed, then?
>
> I think saying "well, these are not really ment to be public
> so we reserve the right to change them but application may still find
> them useful" calls for trouble.
That's why they have the 'INTERNAL' bit. If it breaks, you get to keep
both pieces.
Sort of like how X has _Xgetpwnam(). Debian and Red Hat both have
patches (the same patch) to change its arguments, and people bitched
about this. Our (Debian's) response to this was the same as mine to this
situation now: it's an internal API. You can use it if you really want
to, but the both pieces disclaimer applies.
> Appearantly there was a problem between 2.1.6 and 2.1.7 and there
> are indications that there also is a problem between 2.1.7 and 2.1.8.
Anything built with 2.1.6 would segfault when started with 2.1.7,
because the ABI was silently changed.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040804/6c142a32/attach
ment.pgp
From alexander.gottwald at s1999.tu-chemnitz.de Wed Aug 4 04:22:03 2004
Date: Wed Aug 4 04:22:08 2004
In-Reply-To: <5C1E0DCC-E5C3-11D8-AE2D-000D93291E48@umich.edu>
On Tue, 3 Aug 2004, Brad Barnich wrote:
Cygwin/X definitly has the pattern. If you start Cygwin/X without any
parameter the pattern appears. If it does not appear in then the xserver
has any problems with initialization.
bye
ago
--
From Michael.Lampe at iwr.uni-heidelberg.de Wed Aug 4 05:55:46 2004
From: Michael.Lampe at iwr.uni-heidelberg.de (Michael Lampe)
Date: Wed Aug 4 06:20:27 2004
Message-ID: <4110DCD2.6070404@iwr.uni-heidelberg.de>
>> I have asked around and noone I've asked could come up with rendering
>> problems with 2.1.8. The build breaks for those packages that have used
>> freetype internal defines (appearantly from a non public header). This
>> defines have been renamed to bear the prefix FT.
>
> http://freedesktop.org/~ajax/ft2.1.8-badness.png
Some more:
http://sit.iwr.uni-heidelberg.de/~lampe/freetype-2.1.7.png
2.1.7 is good, 2.1.8 is horrible, 2.1.9 is tolerable.
-Michael
From krahn at niehs.nih.gov Wed Aug 4 08:49:24 2004
Date: Wed Aug 4 08:49:34 2004
In-Reply-To: <4110082C.8090908@bitplanet.net>
References: <410ED7FC.5030401@bitplanet.net> <1091561564.3642.53.camel@localh
ost.localdomain>
Message-ID: <41110584.9000203@niehs.nih.gov>
> For configuring devices, there are two mechanisms: feedbacks and device
> controls, and I must admit I'm not sure what the difference is. They
> both allow clients to change behaivour of a device that you've opened
> with XOpenDevice().
The intended distinction is that feedback events are device outputs,
like LEDs or beeps. DeviceControls are for configuring a device.
In the XInput world, the video display is a really big Feedback
device.
This sort of ties in with the idea that XInput could be generalized
to XDevice. There are a lot of similar issues with server-to-device
mapping, multiple devices/screens for one piece of hardware, etc.
Also keep in mind that managing available devices is more than
just getting the list of attached hardware. For example, a user
may want the server to always advertise a given device which may
not always be plugged in.
Maybe there should be system level code outside of the X protocol
that tells X which devices are available and how to access them,
and the XInput extension can be in charge of adding the OS-available
devices to/from the X servers list of devices, and configuring the
default X options.
Joe Krahn
Date: Wed Aug 4 09:01:30 2004
In-Reply-To: <E1Bs68s-0001un-P8@evo.keithp.com>
References: <E1Bs68s-0001un-P8@evo.keithp.com>
> Around 14 o'clock on Aug 3, Joe Krahn wrote:
>
>
>>Also, I think user drivers are still useful if you have a
>>device not supported by non-Windows OSes. Of course, the newer USB
>>HID based devices should mean mot things are automatically supported.
>
>
> You have to write a driver in either case. Just write a kernel-mode
> driver instead of a user-mode one. I don't know of any significant X.org
> environments that can't add kernel modules any more.
Yes, but I am thinking that one user-mode X.org driver could work for
all systems that X.org runs on, but that kernel-mode drivers will vary
a lot, so several drivers must be written instead of just one.
Of course, the ideal solution would be a cross-platform device driver
ABI. But, what are the odds of that working?
Most of these issues aren't even a problem for most users, who
will only want to use simple pointer/keyboard/joystick devices.
That's why resolving the issues have been ignored for a long time,
and most people don't even try to use X for other devices.
Joe Krahn
From krh at bitplanet.net Wed Aug 4 09:45:10 2004
Date: Wed Aug 4 09:47:10 2004
In-Reply-To: <41110584.9000203@niehs.nih.gov>
ost.localdomain>
<4110082C.8090908@bitplanet.net> <41110584.9000203@niehs.nih.gov>
Message-ID: <41111296.1040904@bitplanet.net>
Joe Krahn wrote:
> Kristian H?gsberg wrote:
>
>> For configuring devices, there are two mechanisms: feedbacks and
>> device controls, and I must admit I'm not sure what the difference
>> is. They both allow clients to change behaivour of a device that
>> you've opened with XOpenDevice().
>
>
> The intended distinction is that feedback events are device outputs,
> like LEDs or beeps. DeviceControls are for configuring a device.
> In the XInput world, the video display is a really big Feedback
> device.
But feedbacks are also used for adjusting mouse acceleration and
keyboard repeat... not just output.
Kristian
Date: Wed Aug 4 09:56:53 2004
ost.localdomain> <4110082C.8090908@bitplanet.net>
Jim Gettys wrote:.
> If you look at the porting document for XInput, it looks as though
> the X server can be educated about pretty arbitrary input devices, with
> pretty arbitrary combinations of keys, buttons, locators, displays,
> etc...
>
> It is an incremental process.
>
> You say: Here's a new device.
> It has some buttons,
> it has some keys,
> it has N axes,
> and so on....
>
> to allow pretty arbitrary devices to be described. I'm actually
> reasonably impressed at the ideas behind the design.
>
> I don't understand how to do this in a one step process.
One idea I had is that that X client code that manages the Input devices
gets access to new devices in a Grabbed state, and has a chance to
configure the desired options before it gets listed for general access.
Krisitan preferred a single event "load device X with option-list".
But, a grabbed-open for new devices gives client code a way to find
out info about a device before applying initial options.
...
> To set up a device, we may have to do a whole sequence of
> operations. E.g.
>
> a) load the correct device driver
> b) set it into a known sane state
>
> It isn't clear to me that we want both/either of those in
> the module loaded into the X server.
> So we can let hotplug get things into a state that
> X can use, and, rather than X having to reopen the device,
> and thereby potentially have to reinitialize it, pass the
> file descriptor to the X server when it is ready to go.
>
One thing that should be possible is for two servers on one VT
to be able to use the same device, but with different settings.
That means X needs to keep device state info and re-instate it
when X gets it's VT switched active and it regains devices.
> If you detect the idea to keep as little as possible in the
> X server, you're right.
>
> This is analogous to the work we want to do to get display
> mode setting *out* of the X server.
>
It seems strange to me for X not to be in charge of display-mode
settings. Does this mean that an OS with VT switching will have
to track display mode states for each server on one multi-VT
console?
> Yeah, I have to scratch my head some. It also looks like some stuff
> is missing (e.g. control for force feedback joysticks.
The BIG design problem here is the lack of extensibility of Controls
and Feebacks in a way that doesn't require an X protocol changes.
Another really useful thing is an Atom to describe individual
control items, rather than just axis 1 through n.
Joe Krahn
Date: Wed Aug 4 10:03:18 2004
Subject: [Xorg] Re: Minutes from August 4 Release Wranglers call
In-Reply-To: <200408041549.JAA12070@anderson.fc.hp.com>
References: <200408041549.JAA12070@anderson.fc.hp.com>
On Wed, 4 Aug 2004, Paul Anderson wrote:
> Bugzilla/Testing status
> -----------------------
> How do we get more testing on wider variety of platforms? Kevin
> said the release will get put upstream into Rawhide as soon
> as possible to increase testing exposure.
I'll prepare test packages for cygwin and upload them.
which numbering scheme is preferrable for those pre release packages?
something like 6.7.99?
bye
ago
--
From svetljo at gmx.de Wed Aug 4 10:03:18 2004
From: svetljo at gmx.de (Svetoslav Slavtchev)
Date: Wed Aug 4 10:03:22 2004
References: <20040803203347.GA26937@suse.de>
Message-ID: <9778.1091638998@www27.gmx.net>
> On Tue, Aug 03, 2004 at 10:12:16PM +0200, Svetoslav Slavtchev wrote:
> > > Hi
> > >
> > > Any hints how to enable Composite extension? I know you can enable it
> > > already with "+extension Composite" command line option but I think
> > > there exists also "Extensions" section to enable/disable extensions
> > > like this.
> >
> > add smth like this :
> > Section "Extensions"
> > # Option "XEVIE" "Enable"
> > # Option "Composite" "Enable"
> > # Option "Composite" "Disable"
> > EndSection
>
> Hmm ... this only works for XEVIE.
>
> Option "XEVIE" "Disable"
> Option "Composite" "Enable"
> EndSection
>
> (==) Using config file: "/etc/X11/XF86Config"
> (EE) Extension "Composite" is unrecognized
> Problem when converting the config data structures
> (EE) Error parsing the config file
have you enabled building Composite in your host.def ?
it's disabled per default and i was getting the same
errors when i tried to use it, but x.org was missing
#define BuildComposite YES
> > > And where can Composite be enabled by default in the code itself?
> >
> > no idea,
> > but i wouldn't do it for now
> > here X wont start with it enabled
>
> Did work for me when using "+extension Composite" command line option.
you did have it listed in xdpyinfo output ?
and no problems with any window manager ?
i tried ~8-10 WM's and i think it mostly works on
gnome2.6, but even there X crashed while i was playing/resizing a mozilla
window
as said enlightenment doesn't even start
here are some nice pic's :(
strange issues with XVideo (i think) mostly, but not
only
http://mandrake.contactel.cz/people/svetljo/mandrake/probably_broken/composite/
gdm's session menu has a green shadow , and sometimes
crashes X
eterm has strange collors in the text area and the titlebar
depending on wether
composite is disabled in build, turned on or off via xorg.conf
clicking on mozilla window with composite enabled
is like sliding a green film over the entire screen.
the green film vanisches when i click outside of mozilla
/* i couldn't capture this sorry :( */
best,
svetljo
--
NEU: WLAN-Router fr 0,- EUR* - auch fr DSL-Wechsler!
GMX DSL = supergnstig & kabellos http://www.gmx.net/de/go/dsl
Date: Wed Aug 4 10:05:36 2004
In-Reply-To: <41111296.1040904@bitplanet.net>
ost.localdomain>
<4110082C.8090908@bitplanet.net> <41110584.9000203@niehs.nih.gov>
<41111296.1040904@bitplanet.net>
> Joe Krahn wrote:
>
>> Kristian H?gsberg wrote:
>>
>>> For configuring devices, there are two mechanisms: feedbacks and
>>> device controls, and I must admit I'm not sure what the difference
>>> is. They both allow clients to change behaivour of a device that
>>> you've opened with XOpenDevice().
>>
>>
>>
>> The intended distinction is that feedback events are device outputs,
>> like LEDs or beeps. DeviceControls are for configuring a device.
>> In the XInput world, the video display is a really big Feedback
>> device.
>
>
> But feedbacks are also used for adjusting mouse acceleration and
> keyboard repeat... not just output.
>
Yeah, these break the concept of feedback versus control a bit.
Pointer acceleration has both categories. Maybe because these are
dynamically interacting with the user they are seen as special cases
that are a bit intermediate. I think it would have been better for
these both to have been kept as just controls and not feedbacks.
Oh well...
Joe
Date: Wed Aug 4 15:58:38 2004
Message-ID: <4111699A.7000000@bitplanet.net>
Jim Gettys wrote:
...
>>>This device might be local, or remote.
>>>
>>>2) Via some protocol over this socket (might be dbus, might be
>>>some other protocol, as simple as the current name/value pairs
>>>used in the current configuration file nightmare), the X server
>>>is told to set up the new input device).
>>
>>D-BUS doesn't let you pass file descriptors, so I guess that's out.
>
>
> No, I don't think it is an issue here.
>
> I'm thinking of the case to allow the design to deal with new
> device types.
>
> If you look at the porting document for XInput, it looks as though
> the X server can be educated about pretty arbitrary input devices, with
> pretty arbitrary combinations of keys, buttons, locators, displays,
> etc...
>
> It is an incremental process.
>
> You say: Here's a new device.
> It has some buttons,
> it has some keys,
> it has N axes,
> and so on....
>
> to allow pretty arbitrary devices to be described. I'm actually
> reasonably impressed at the ideas behind the design.
>
> I don't understand how to do this in a one step process.
You would just specify all that in one request, e.g.:
Device: <file descriptor here>
Driver: xmlevent
Buttons: 7
Keys: A B C D E F
I don't see why the server and the hotplug daemon need to discuss back
and forth about this, if it can be done with just one request. I guess
I'm just trying to keeps things as simple as possible.
If the server can not add the device with the given options it reports
this back, of course, but this should be exceptional, e.g. out of memory.
>>>3) If so, after initialization,
>>>the socket associated with the device gets sent to
>>>the X server (via send()), along with some information to allow
>>>the X server to filter the byte stream (or do the right IOCTL's),
>>>via some interface, for delivery of events after the device
>>>has been initialised.
>>>
>>>There would likely be three such filters (on Linux):
>>> a) existing serial devices (if we care)
>>> b) evdev devices.
>>> c) remote devices via some (yet to be determined) wire
>>> protocol.
>>
>>Wouldn't it be better to do 2 and 3 in one go, i.e. send a request
>>saying "setup a new input device, use this filter, use this fd". That
>>avoids state in the protocol and makes the whole setup simpler.
>
>
> To set up a device, we may have to do a whole sequence of
> operations. E.g.
>
> a) load the correct device driver
> b) set it into a known sane state
>
> It isn't clear to me that we want both/either of those in
> the module loaded into the X server.
>
> So we can let hotplug get things into a state that
> X can use, and, rather than X having to reopen the device,
> and thereby potentially have to reinitialize it, pass the
> file descriptor to the X server when it is ready to go.
Again, I'd like to keep this as simple as possible, and as I said above,
I don't see anything that prevents us from sending this information as
one request. When the server receives the requests it works its way
through the options in the request and sets up the driver accordingly,
finally adding the file descriptor and enabling the device. If
something goes wrong, it unrolls the steps taken so far and reports an
error back to the hotplug daemon. Otherwise it sends a confirmation that
the device was successfully added.
...
>>So we should try to figure out what kind of interface the server should
>>expose on this local socket and what kind of protocol to use. I can't
>>see that we would need anything more than add device and remove device
>>requests. The add device request passes the fd, the name of the filter
>>to use, and possibly a set of options for that filter.
>
> It is the setup of new devices where the interface has to be reasonably
> rich; or you can't support arbitrary devices.
As I mentioned on IRC, I'm not crazy about exposing such a rich API over
a custom IPC mechanism. For one, it's a lot of work, and I'm not sure
how it's better than letting the driver do this work.
Kristian
Btw., you've mentioned an XML-based event protocol a couple of times; do
you have a link for this work?
-------------- next part --------------
Name: evdev.c
Type: text/x-csrc
Size: 21521 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040805/4a25c523/evdev.
c
Date: Wed Aug 4 16:32:41 2004
In-Reply-To: <4111699A.7000000@bitplanet.net>
References: <410ED7FC.5030401@bitplanet.net> <1091561564.3642.53.came
l@localhost.localdomain> <4110082C.8090908@bitplanet.net>
<4111699A.7000000@bitplanet.net>
Message-ID: <4111719F.1040704@bitplanet.net>
> Jim Gettys wrote:
>
> ...
>> It is the setup of new devices where the interface has to be reasonably
>> rich; or you can't support arbitrary devices.
>
>
> As I mentioned on IRC, I'm not crazy about exposing such a rich API over
> a custom IPC mechanism. For one, it's a lot of work, and I'm not sure
> how it's better than letting the driver do this work.
Hmm... it's common to mention an attachment and forget to actually
attach it; this was the other way around...
I attached the evdev driver I've been working on to illustrate how a
driver could probe the fd it receives to find out what kind of events it
supports. Using ioctl()'s you can get a bitmask of the event classes
the device supports, and for each event class, you can query further to
discover the actual events the device sends. This maps quite nicely to
the XInput API, which has almost the same event classes.
Kristian
From thomas at winischhofer.net Wed Aug 4 17:27:54 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Wed Aug 4 17:29:36 2004
In-Reply-To: <Pine.LNX.4.58.0408041859420.9508@odoaker.hrz.tu-chemnitz.de>
<Pine.LNX.4.58.0408041859420.9508@odoaker.hrz.tu-chemnitz.de>
Message-ID: <41117F0A.8040607@winischhofer.net>
Alexander Gottwald wrote:
> On Wed, 4 Aug 2004, Paul Anderson wrote:
>
>
>>Bugzilla/Testing status
>>-----------------------
>>How do we get more testing on wider variety of platforms? Kevin
>>said the release will get put upstream into Rawhide as soon
>>as possible to increase testing exposure.
>
>
> I'll prepare test packages for cygwin and upload them.
>
> which numbering scheme is preferrable for those pre release packages?
> something like 6.7.99?
Traditionally 6.7.99.1 and so on, I'd say. If tradition counts, that is.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
From sergiomb at netcabo.pt Wed Aug 4 19:13:35 2004
From: sergiomb at netcabo.pt (=?ISO-8859-1?Q?S=E9rgio?= Monteiro Basto)
Date: Wed Aug 4 19:13:43 2004
Subject: [Xorg] Re: Savage DRI DDX to xorg merge
In-Reply-To: <a728f9f90408012145739c3fb1@mail.gmail.com>
References: <a728f9f90408012145739c3fb1@mail.gmail.com>
Message-ID: <1091672015.2600.4.camel@darkstar>
On Mon, 2004-08-02 at 05:45, Alex Deucher wrote:
> I just finished the preliminary merge. It seems to work ok in limited
> testing. for those interested the patch is here:
> http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
>
> the code still needs the "develdri" #ifdefs added. I'm not sure
> exactly where those need to go off hand. also the savage dri is still
> only in mesa.
> At this point this can probably wait until after the next release for merging.
>
> Alex
Finally I can post to xorg
so a little resume for xorg list:
with your patch and
uncomment on xc/config/cf/xorgsite.def
#define BuildDevelDRIDrivers YES
Finally I can report that DRI work on savage twister k very (well)
smoothly :)
but on some videos with video driver xv (others works well) have
problems, I see a duplicated image, I test it with mplayer and xine and
maybe a small problem in xine with xv drive is already a problem o
s3savage drive.
best regards,
--
S?rgio M. B.
From kem at freedesktop.org Wed Aug 4 21:12:19 2004
From: kem at freedesktop.org (Kevin E Martin)
Date: Wed Aug 4 21:12:26 2004
Subject: [Xorg] Release status update
Message-ID: <20040805041219.GA27306@kem.org>
As most of you already know, the feature freeze was last Friday. We
would like to thank everyone for getting all of their features checked
in on schedule.
We are now moving into the testing phase of the release, so no further
features will be allowed in the tree at this time. Bug fixes and
updates to the documentation are welcome.
At this time, we really need to get more complete testing, bug reporting
and bug fixing of the current code. For those that can build and test
the release, please do so and report any problems in the freedesktop.org
bugzilla, ideally with a patch that fixes the problem.
We would also like to get those testers that cannot build the release
themselves involved. To do so, I would like to see some volunteers
build and package the pre-release code for others to download and test.
If there is a way to automatically do nightly builds and packaging, that
would be very much appreciated.
We are tentatively calling this next release "X11R6.8" but the final
decision will need to be made by the X.Org Foundation BOD. When the
name is approved, we will announce it here. As for what to call the
pre-release packages, others have suggested that we use X11R6.7.99.x,
which is similar to what has been done in the past.
Fixing bugs should be the priority until the code freeze on 13 Aug 2004.
After that date, only critical bug fixes and documentation updates will
be allowed to be checked into the tree. Here is the URL for the release
bug:
https://freedesktop.org/bugzilla/show_bug.cgi?id=351
On this page, you will find the list of bugs that the release depends
on. These blocker bugs should be fixed first, and then the list of
other bugs filed against the "xorg" product should be investigated.
There are currently 21 blocker bugs (8 of which have already been fixed)
and a total of 183 bugs currently open against xorg in the freedesktop
bugzilla.
We would like this release to be as stable as possible, so all help
looking into and fixing these bugs is most appreciated!
Date: Wed Aug 4 21:14:53 2004
In-Reply-To: <Pine.LNX.4.58.0408041859420.9508@odoaker.hrz.tu-chemnitz.de>
Message-ID: <20040805041448.GB27306@kem.org>
On Wed, Aug 04, 2004 at 07:03:15PM +0200, Alexander Gottwald wrote:
> On Wed, 4 Aug 2004, Paul Anderson wrote:
>
> > Bugzilla/Testing status
> > -----------------------
> > How do we get more testing on wider variety of platforms? Kevin
> > said the release will get put upstream into Rawhide as soon
> > as possible to increase testing exposure.
>
> I'll prepare test packages for cygwin and upload them.
Thank you!
> which numbering scheme is preferrable for those pre release packages?
> something like 6.7.99?
Yes, that should be fine. I would suggest adding another .# at the end
(e.g., 6.7.99.1 for the first build) so that we can track what people
test.
Date: Wed Aug 4 21:27:53 2004
In-Reply-To: <41117F0A.8040607@winischhofer.net>
<41117F0A.8040607@winischhofer.net>
Message-ID: <20040805042748.GC27306@kem.org>
On Thu, Aug 05, 2004 at 02:27:54AM +0200, Thomas Winischhofer wrote:
> Alexander Gottwald wrote:
> >On Wed, 4 Aug 2004, Paul Anderson wrote:
> >
> >
> >>Bugzilla/Testing status
> >>-----------------------
> >>How do we get more testing on wider variety of platforms? Kevin
> >>said the release will get put upstream into Rawhide as soon
> >>as possible to increase testing exposure.
> >
> >
> >I'll prepare test packages for cygwin and upload them.
> >
> >which numbering scheme is preferrable for those pre release packages?
> >something like 6.7.99?
>
> Traditionally 6.7.99.1 and so on, I'd say. If tradition counts, that is.
That is an excellent suggestion. The extra .# will help us track which
pre-release is used. Following this thought through, we should also tag
the tree for each pre-release package. The problem is that we don't
have the official release name yet, but currently the thought is that it
will be X11R6.8. Once the name is finalized, I will follow up with the
other release wranglers to determine what the pre-release tags will be
(probably something like XORG-PRE-R6_8-# where # is the pre-release
package number). I will report back with the results.
From bryce at osdl.org Wed Aug 4 21:45:07 2004
From: bryce at osdl.org (Bryce Harrington)
Date: Wed Aug 4 21:45:10 2004
Subject: [Xorg] Release status update
In-Reply-To: <20040805041219.GA27306@kem.org>
Message-ID: <Pine.LNX.4.33.0408042126540.16936-100000@osdlab.pdx.osdl.net>
On Thu, 5 Aug 2004, Kevin E Martin wrote:
> We would also like to get those testers that cannot build the release
> themselves involved. To do so, I would like to see some volunteers
> build and package the pre-release code for others to download and test.
> If there is a way to automatically do nightly builds and packaging, that
> would be very much appreciated.
A tinderbox is available for nightly build tests:
http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
A number of OS's are represented there. There are instructions for
setting up new systems, available here:
http://www.freedesktop.org/Software/TinderboxWiki
I'll be adding SuSE 9.1 soonish.
Bryce
From andreas at syndrom23.de Wed Aug 4 23:58:05 2004
From: andreas at syndrom23.de (Andreas Kohn)
Date: Thu Aug 5 00:05:28 2004
Subject: [Xorg] xserver: Interrupt pointer (seg f000 off 5490) doesn't point
at ROM
Message-ID: <1091689084.31362.17.camel@klamath.ankon.de.eu.org>
Hi,
I can't get xserver to run on my machine. Both Xvesa and Xpm2[*] report:
---8<----
andreas@pentium freedesktop.org $
LD_LIBRARY_PATH=/usr/local/freedesktop.org/lib/ sudo bin/Xvesa :0
Interrupt pointer (seg f000 off 5490) doesn't point at ROM
Fatal server error:
no screens found
Segmentation fault
---->8-----
The card is an Elsa Winner 2000/Office.
lspci -vn
----
0000:00:0b.0 Class 0300: 104c:3d07 (rev 01)
Subsystem: 1048:0a31
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at e1000000 (32-bit, non-prefetchable)
Memory at e0000000 (32-bit, non-prefetchable) [size=8M]
Memory at e0800000 (32-bit, non-prefetchable) [size=8M]
----
XFree86.0.log (from XFree86 4.3) reports this card as
----
(--) PCI:*(0:11:0) Texas Instruments TVP4020 [Permedia 2] rev 1, Mem @
0xe1000000/17, 0xe0000000/23, 0xe0800000/23
...
(II) GLINT: driver for 3Dlabs chipsets: gamma, gamma2, ti_pm2, ti_pm,
r4,
pm4, pm3, pm2v, pm2, pm, 300sx, 500tx, mx, delta
(II) Primary Device is: PCI 00:0b:0
(--) Chipset ti_pm2 found
...
(**) GLINT(0): Depth 16, (--) framebuffer bpp 16
(==) GLINT(0): RGB weight 565
(==) GLINT(0): Default visual is TrueColor
(==) GLINT(0): Using gamma correction (1.0, 1.0, 1.0)
(==) GLINT(0): Using HW cursor
(--) GLINT(0): Not using Linux framebuffer device
(--) GLINT(0): Chipset: "ti_pm2"
(--) GLINT(0): Linear framebuffer at 0xE0800000
(--) GLINT(0): MMIO registers at 0xE1000000
(WW) System lacks support for changing MTRRs
(--) GLINT(0): VideoRAM: 8192 kByte
----8<----
The machine in question is a Pentium 200MMX with Linux 2.6.7 (Gentoo).
xserver is built from CVS sources, latest test was yesterday ~2300CEST.
[*] Xpm2 will report this if I force detection:
----
Index: pm2stub.c
===================================================================
RCS file: /cvs/xserver/xserver/hw/kdrive/pm2/pm2stub.c,v
diff -u -r1.1 pm2stub.c
--- pm2stub.c 24 May 2004 19:31:41 -0000 1.1
+++ pm2stub.c 5 Aug 2004 06:53:09 -0000
@@ -21,6 +21,10 @@
for (i = 0; i < numPM2Cards; i++)
if (LinuxFindPci (0x3d3d, PM2Cards[i], 0, &attr))
KdCardInfoAdd (&PM2Funcs, &attr, (void *) PM2Cards[i]);
+
+ i = 0x3d07; /* XXX: ankon: HACK HACK HACK */
+ if (LinuxFindPci (PCI_VENDOR_TI, i, 0, &attr))
+ KdCardInfoAdd( &PM2Funcs, &attr, (void *) &i);
}
----
Should Xpm2/Xvesa work on this card? How could I debug/help debugging
this problem?
Regards,
Andreas Kohn
-------------- next part --------------
Name: not available
Size: 187 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040805/588c545d/attach
ment.pgp
From stefano at cdh.it Thu Aug 5 04:17:48 2004
From: stefano at cdh.it (stefano@cdh.it)
Date: Thu Aug 5 04:25:24 2004
Subject: [Xorg] V_BIOS Radeon problem
Message-ID: <4112175C.6090000@cdh.it>
Hope not an already answered question:
I've added a Radeon 7000 PCI into my desktop system and I have this
strange behavior: first time I boot the computer Xorg starts correctly
in both video cards, using them both. If i logout and relog it only
finds the other video card. I've to reset the computer in order to let
Xorg to reuse that Radeon.
this is the difference between the two Xorg startup log:
13c13
< (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 4 15:37:48 2004
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 4 15:35:58 2004
580c580
< (II) RADEON(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
is 0x0000
---
> (II) RADEON(1): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset
is 0x0000
596,597c596
< (EE) RADEON(1): Cannot read V_BIOS
< (WW) RADEON(1): Restoring MEM_CNTL (00000000), setting to 00002e00
---
> (II) Truncating PCI BIOS Length to 49152
614,615d612
< (WW) RADEON(1): Video BIOS not detected in PCI space!
< (WW) RADEON(1): Attempting to read Video BIOS from legacy ISA space!
674c671
< (II) RADEON(1): DFP table revision: 68
---
> (II) RADEON(1): DFP table revision: 3
813c810
< (II) NVIDIA(0): Wrote: rd=837, fd=249, pd=0
---
> (II) NVIDIA(0): Wrote: rd=60, fd=480, pd=1
867a865,869
> (II) Screen 0 shares mem & io resources
> (II) NVIDIA(0): Wrote: rd=2, fd=20, pd=1
it seems that the second time it starts, it can't find V_BIOS so it
simply can't use radeon card.
I've found only a very similar situation searching with google, but it
seems has been resolved upgrading Xorg: I think I've the last stable
version:
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
Build Operating System: Linux 2.6.7 i686 [ELF]
Current Operating System: Linux athlon 2.6.7 #3 Fri Jul 23 17:45:06 CEST
2004 i686
Build Date: 19 June 2004
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
any suggestion?
thanks a lot
From thomas at winischhofer.net Thu Aug 5 04:18:17 2004
Date: Thu Aug 5 04:26:35 2004
Subject: [Xorg] CVS: connection refused?
Message-ID: <41121779.4080909@winischhofer.net>
ssh: connect to host cvs.freedesktop.org port 22: Connection refused
Is this indended or just a temporary problem?
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
From krh at bitplanet.net Thu Aug 5 05:20:57 2004
Date: Thu Aug 5 05:23:06 2004
Subject: [Xorg] CVS: connection refused?
In-Reply-To: <41121779.4080909@winischhofer.net>
References: <41121779.4080909@winischhofer.net>
Thomas Winischhofer wrote:
>
> ssh: connect to host cvs.freedesktop.org port 22: Connection refused
>
> Is this indended or just a temporary problem?
>
My IRC client tells me that:
Topic for #freedesktop is SSH DOWN UNTIL FURTHER NOTICE || ...
but other than that I dont know...
Kristian
From alexdeucher at gmail.com Thu Aug 5 09:08:09 2004
Date: Thu Aug 5 09:08:16 2004
In-Reply-To: <1091672015.2600.4.camel@darkstar>
<1091672015.2600.4.camel@darkstar>
Message-ID: <a728f9f9040805090817b37070@mail.gmail.com>
On Thu, 05 Aug 2004 03:13:35 +0100, S?rgio Monteiro Basto
<sergiomb@netcabo.pt> wrote:
> On Mon, 2004-08-02 at 05:45, Alex Deucher wrote:
> > I just finished the preliminary merge. It seems to work ok in limited
> > testing. for those interested the patch is here:
> > http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
> >
> > the code still needs the "develdri" #ifdefs added. I'm not sure
> > exactly where those need to go off hand. also the savage dri is still
> > only in mesa.
> > At this point this can probably wait until after the next release for mergin
g.
> >
> > Alex
> Finally I can post to xorg
> so a little resume for xorg list:
> with your patch and
> uncomment on xc/config/cf/xorgsite.def
> #define BuildDevelDRIDrivers YES
>
> Finally I can report that DRI work on savage twister k very (well)
> smoothly :)
> but on some videos with video driver xv (others works well) have
> problems, I see a duplicated image, I test it with mplayer and xine and
> maybe a small problem in xine with xv drive is already a problem o
> s3savage drive.
did you have those problems with DRI cvs or are they new with xorg?
The streams code has be reshuffled a bit. also try with
option "BCIForXv" "false" (or something like that; I forget the exact name).
thanks for testing.
Alex
>
> best regards,
>
> --
> S?rgio M. B.
>
>
From jserv at linux2.cc.ntu.edu.tw Thu Aug 5 10:44:05 2004
Date: Thu Aug 5 10:44:08 2004
In-Reply-To: <20040804092800.GC8627@fooishbar.org>
References: <20040804092243.GA21007@linux2.cc.ntu.edu.tw>
<20040804092800.GC8627@fooishbar.org>
On Wed, Aug 04, 2004 at 07:28:00PM +1000, Daniel Stone wrote:
>
> ... don't use XKB.
>
Thanks.
How can I turn off xkb in fd.o xserver?
Without passing --enable-xkb, it seems to be the same resulting
in compilation errors.
Any ideas?
Thanks,
Jim Huang
From Jim.Gettys at hp.com Thu Aug 5 11:21:02 2004
Date: Thu Aug 5 11:21:10 2004
In-Reply-To: <41111551.1040707@niehs.nih.gov>
<41111551.1040707@niehs.nih.gov>
> One thing that should be possible is for two servers on one VT
> to be able to use the same device, but with different settings.
> That means X needs to keep device state info and re-instate it
> when X gets it's VT switched active and it regains devices.
I presume you mean two servers on 2 different Linux virtual
terminals.
Ugh. Do we *really* need this complexity?
Do USB devices provide ways to save/restore such settings?
Or will the system have to shadow the state and try to
keep it consistent?
Or is an input device assigned to a particular X server
statically? This maps well to the situation of
multi-head systems (e.g. 441, like we've (HP) started selling
in South Africa).
You are helping stoke my head-ache ;-).
>
> > If you detect the idea to keep as little as possible in the
> > X server, you're right.
> >
> > This is analogous to the work we want to do to get display
> > mode setting *out* of the X server.
> >
> It seems strange to me for X not to be in charge of display-mode
> settings. Does this mean that an OS with VT switching will have
> to track display mode states for each server on one multi-VT
> console?
Well, where should the complexity lie?
Should the operating system that inflicts the complexity
have to bear the cost, or is this something X should have to
support?
>
> > Yeah, I have to scratch my head some. It also looks like some stuff
> > is missing (e.g. control for force feedback joysticks.
>
> The BIG design problem here is the lack of extensibility of Controls
> and Feebacks in a way that doesn't require an X protocol changes.
>
> Another really useful thing is an Atom to describe individual
> control items, rather than just axis 1 through n.
>
Could be. We have to look into this all more. We know we
have to add to XInput for hotplug, and if there are other issues
clearly that need fixing, now is probably the time.
- Jim
From roland.mainz at nrubsig.org Wed Aug 4 10:19:43 2004
Date: Thu Aug 5 11:49:58 2004
References: <200408021914.NAA11658@anderson.fc.hp.com>
Message-ID: <41111AAF.2A622B64@nrubsig.org>
Paul Anderson wrote:
>
> I noticed that I haven't received any e-mail from bugzilla to the
> xorg-bugzilla-noise list since July 14. Does anyone know why?
No, I have no clue. But I suggest to drop the *-noise mailinglists
completely since bugzilla has been upgraded to a version where it is
possible to "watch" other users (see
https://freedesktop.org/bugzilla/userprefs.cgi?tab=email , field "users
to watch"), e.g. you get all the bugzilla emails which are send to the
person you are "watching", too...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Thu Aug 5 12:00:53 2004
In-Reply-To: <41111AAF.2A622B64@nrubsig.org>
References: <200408021914.NAA11658@anderson.fc.hp.com>
<41111AAF.2A622B64@nrubsig.org>
Roland Mainz wrote:
> Paul Anderson wrote:
>
>>I noticed that I haven't received any e-mail from bugzilla to the
>>xorg-bugzilla-noise list since July 14. Does anyone know why?
>
>
> No, I have no clue. But I suggest to drop the *-noise mailinglists
> completely since bugzilla has been upgraded to a version where it is
> possible to "watch" other users (see
> https://freedesktop.org/bugzilla/userprefs.cgi?tab=email , field "users
> to watch"), e.g. you get all the bugzilla emails which are send to the
> person you are "watching", too...
What if you want to follow all the traffic in bugzilla? What user
should you watch?
Kristian
From steven_ed4153 at yahoo.com Thu Aug 5 13:55:53 2004
From: steven_ed4153 at yahoo.com (Steven Edwards)
Date: Thu Aug 5 14:02:36 2004
Subject: [Xorg] Mingw build
Is anyone working on this? The only site I could find with information
was the old Redhat site.
Thanks
Steven
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
From jonsmirl at yahoo.com Thu Aug 5 14:16:55 2004
Date: Thu Aug 5 14:17:05 2004
In-Reply-To: <4112175C.6090000@cdh.it>
Does X have this ATI radeon fix in it? This should be done before
trying to access a ROM on a radeon card. Several of the radeons I own
need this fix.
/* Fix from ATI for problem with Radeon hardware not leaving ROM
enabled */
#define DRIVER_ROMBUG(mmio) \
{ \
unsigned int temp; \
temp = DRM_READ32(mmio, RADEON_MPP_TB_CONFIG); \
temp &= 0x00ffffffu; \
temp |= 0x04 << 24; \
DRM_WRITE32(mmio, RADEON_MPP_TB_CONFIG, temp); \
temp = DRM_READ32(mmio, RADEON_MPP_TB_CONFIG); \
}

=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From sergiomb at netcabo.pt Thu Aug 5 16:51:08 2004
Date: Thu Aug 5 16:51:12 2004
In-Reply-To: <a728f9f9040805090817b37070@mail.gmail.com>
<1091672015.2600.4.camel@darkstar>
<a728f9f9040805090817b37070@mail.gmail.com>
On Thu, 2004-08-05 at 17:08, Alex Deucher wrote:
> On Thu, 05 Aug 2004 03:13:35 +0100, S?rgio Monteiro Basto
> <sergiomb@netcabo.pt> wrote:
> > On Mon, 2004-08-02 at 05:45, Alex Deucher wrote:
> > > I just finished the preliminary merge. It seems to work ok in limited
> > > testing. for those interested the patch is here:
> > > http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
> > >
> > > the code still needs the "develdri" #ifdefs added. I'm not sure
> > > exactly where those need to go off hand. also the savage dri is still
> > > only in mesa.
> > > At this point this can probably wait until after the next release for merg
ing.
> > >
> > > Alex
> > Finally I can post to xorg
> > so a little resume for xorg list:
> > with your patch and
> > uncomment on xc/config/cf/xorgsite.def
> > #define BuildDevelDRIDrivers YES
> >
> > Finally I can report that DRI work on savage twister k very (well)
> > smoothly :)
> > but on some videos with video driver xv (others works well) have
> > problems, I see a duplicated image, I test it with mplayer and xine and
> > maybe a small problem in xine with xv drive is already a problem o
> > s3savage drive.
>
> did you have those problems with DRI cvs or are they new with xorg?
> The streams code has be reshuffled a bit. also try with
> option "BCIForXv" "false" (or something like that; I forget the exact name).
Don't see any changes with option "BCIForXv" "false".
The duplicated/translated image is new, a small problem in xine with xv
is old, happens with DRI cvs and still with xorg.
> thanks for testing.
testings are welcomed, I'll try help you, where I could help you.
sorry for my bad English.
thanks,
> Alex
>
> >
> > best regards,
--
S?rgio M. B.
From carl at personnelware.com Thu Aug 5 18:24:44 2004
Date: Thu Aug 5 18:24:48 2004
Subject: [Xorg] tinderbox forest fire
Message-ID: <1f0e01c47b54$28025f90$1e01a8c0@cnt496>
http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
I would look at the logs, but I am being summoned for dinner.
Carl K
Date: Thu Aug 5 18:31:37 2004
In-Reply-To: <1f0e01c47b54$28025f90$1e01a8c0@cnt496>
References: <1f0e01c47b54$28025f90$1e01a8c0@cnt496>
Yeah, looks like Eric broke the build in his last check in on
composite.
If we could get a (compatible) version of bonsai going, it
would make the blame game even easier.
- Jim
On Thu, 2004-08-05 at 21:24, Carl Karsten wrote:
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
>
> I would look at the logs, but I am being summoned for dinner.
>
> Carl K
> _______________________________________________
> xorg mailing list
From ajax at nwnk.net Thu Aug 5 20:56:49 2004
Date: Thu Aug 5 20:57:03 2004
References: <1f0e01c47b54$28025f90$1e01a8c0@cnt496>
Hash: SHA1
On Thursday 05 August 2004 21:31, Jim Gettys wrote:
> Yeah, looks like Eric broke the build in his last check in on
> composite.
>
> If we could get a (compatible) version of bonsai going, it
> would make the blame game even easier.
> - Jim
I just pulled from CVS about 90 minutes ago and ran make World afresh, no
problems here...
- - ajax
iD8DBQFBEwGEW4otUKDs0NMRAt9XAKCBKwlun+223nwIhqMaaUNny17rHgCg33i3
f0MI+pLiSV2fDJBPv3eM+u0=
=yDhY
From eta at lclark.edu Thu Aug 5 20:58:28 2004
Date: Thu Aug 5 20:58:34 2004
Subject: [Xorg] Re: CVS Update: xc (branch: trunk)
In-Reply-To: <20040806003129.4DF129EEFD@freedesktop.org>
References: <20040806003129.4DF129EEFD@freedesktop.org>
On Thu, 2004-08-05 at 17:31, Eric Anholt wrote:
> CVSROOT: /cvs/xorg
> Module name: xc
> Changes by: anholt@pdx. 04/08/05 17:31:29
>
> Log message:
> Fix missing ';' in cw.c and unwrap the render wrapper properly.
>
> Modified files:
> ./:
> ChangeLog
> xc/programs/Xserver/composite/:
> cw.c cw.h cw_render.c
Sorry about that one. I have no idea how it slipped through :(
--
From keithp at keithp.com Thu Aug 5 21:59:04 2004
Date: Fri Aug 6 00:57:44 2004
Subject: [Xorg] xserver: Interrupt pointer (seg f000 off 5490) doesn't
point at ROM
In-Reply-To: Your message of "Thu, 05 Aug 2004 08:58:05 +0200."
<1091689084.31362.17.camel@klamath.ankon.de.eu.org>
Message-ID: <E1Bswor-0000eA-W9@evo.keithp.com>
Around 8 o'clock on Aug 5, Andreas Kohn wrote:
> I can't get xserver to run on my machine. Both Xvesa and Xpm2[*] report:
You'll want to try loading the vesa fb driver into your kernel and using
Xfbdev instead. Sometimes the vm86 support code in the vesa module gets
confused by weird bioses. Help in debugging these cases would be welcome
if you feel up to it, but I don't have any instances which fail available
to me.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040805/b998cae6/attach
ment.pgp
From stefano at cdh.it Fri Aug 6 02:48:30 2004
From: stefano at cdh.it (stefano@cdh.it)
Date: Fri Aug 6 02:48:38 2004
Message-ID: <411353EE.9030000@cdh.it>
Jon Smirl wrote:
>Does X have this ATI radeon fix in it? This should be done before
>trying to access a ROM on a radeon card. Several of the radeons I own
>need this fix.
>
>
>
I use Xorg from slackware, I'll check in the source. In which file do I
should find this code?
>/* Fix from ATI for problem with Radeon hardware not leaving ROM
>enabled */
>#define DRIVER_ROMBUG(mmio) \
>{ \
> unsigned int temp; \
> temp = DRM_READ32(mmio, RADEON_MPP_TB_CONFIG); \
> temp &= 0x00ffffffu; \
> temp |= 0x04 << 24; \
> DRM_WRITE32(mmio, RADEON_MPP_TB_CONFIG, temp); \
> temp = DRM_READ32(mmio, RADEON_MPP_TB_CONFIG); \
>}
>
>
>
>
>=====
>Jon Smirl
>jonsmirl@yahoo.com
>
>
>
>__________________________________
>Do you Yahoo!?
>New and Improved Yahoo! Mail - Send 10MB messages!
>http://promotions.yahoo.com/new_mail
>
>
From thomas at winischhofer.net Fri Aug 6 05:48:23 2004
Date: Fri Aug 6 05:50:00 2004
Subject: [Xorg] xorgGetVersion() declaration
Message-ID: <41137E17.9030005@winischhofer.net>
Shouldn't there be a declaration for xorgGetVersion() anywhere in a
common header file? That function is otherwise not (legitimately) usable
from within a module.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From krh at bitplanet.net Fri Aug 6 08:03:06 2004
Date: Fri Aug 6 08:05:11 2004
Subject: [Xorg] CVS snapshot RPMs for Fedore Core 2
Message-ID: <41139DAA.1090603@bitplanet.net>
Hi,
I have put together a set of RPMs for Xorg CVS as of August 5 in
http://freedesktop.org/~krh
In other words, these RPMs have the new set of extensions, but also a
set of known bugs (see #351). These aren't official Red Hat RPMs and
they are only available for i386. Fedora Development will soon have
official RPMs for other architectures, but for now these packages should
make more widespread testing easier.
Use the standard bugzilla.freedesktop.org for reporting bugs against
these packages, and please Cc me (bugzilla account: krh@bitplanet.net)
on bugs filed against them. Also, remember to check that the bug you
are reporting is not already in bugzilla.
Have fun,
Kristian
From alexdeucher at gmail.com Fri Aug 6 08:09:14 2004
Date: Fri Aug 6 08:09:19 2004
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
Message-ID: <a728f9f9040806080953f5a40e@mail.gmail.com>
On Fri, 06 Aug 2004 00:51:08 +0100, S?rgio Monteiro Basto
>
>
> On Thu, 2004-08-05 at 17:08, Alex Deucher wrote:
> > On Thu, 05 Aug 2004 03:13:35 +0100, S?rgio Monteiro Basto
> > <sergiomb@netcabo.pt> wrote:
> > > On Mon, 2004-08-02 at 05:45, Alex Deucher wrote:
> > > > I just finished the preliminary merge. It seems to work ok in limited
> > > > testing. for those interested the patch is here:
> > > > http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
> > > >
> > > > the code still needs the "develdri" #ifdefs added. I'm not sure
> > > > exactly where those need to go off hand. also the savage dri is still
> > > > only in mesa.
> > > > At this point this can probably wait until after the next release for me
rging.
> > > >
> > > > Alex
> > > Finally I can post to xorg
> > > so a little resume for xorg list:
> > > with your patch and
> > > uncomment on xc/config/cf/xorgsite.def
> > > #define BuildDevelDRIDrivers YES
> > >
> > > Finally I can report that DRI work on savage twister k very (well)
> > > smoothly :)
> > > but on some videos with video driver xv (others works well) have
> > > problems, I see a duplicated image, I test it with mplayer and xine and
> > > maybe a small problem in xine with xv drive is already a problem o
> > > s3savage drive.
> >
> > did you have those problems with DRI cvs or are they new with xorg?
> > The streams code has be reshuffled a bit. also try with
> > option "BCIForXv" "false" (or something like that; I forget the exact name).
>
> Don't see any changes with option "BCIForXv" "false".
>
> The duplicated/translated image is new, a small problem in xine with xv
> is old, happens with DRI cvs and still with xorg.
thanks I'll look into it as soon as I get a chance.
Alex
>
> > thanks for testing.
>
> testings are welcomed, I'll try help you, where I could help you.
> sorry for my bad English.
> thanks,
>
>
> > Alex
> >
> > >
> > > best regards,
>
> --
> S?rgio M. B.
>
>
From Alan.Coopersmith at Sun.COM Fri Aug 6 08:18:33 2004
Date: Fri Aug 6 08:18:30 2004
Subject: [Xorg] Re: [Fontconfig] adding/distributing new fonts
In-Reply-To: <6555429d040806011636e2cc46@mail.gmail.com>
References: <6555429d040806011636e2cc46@mail.gmail.com>
Message-ID: <4113A149.7020006@sun.com>
xorg@freedesktop.org is the mailing list for xorg, and would be a much
better place to discuss adding fonts to the X.Org distribution, so I've
cc'ed it.
I believe the license requirements are that it be some sort of open source
license, but that the requirements for fonts are a bit looser than source
code.
TrueType fonts are the currently preferred format.
Soon-Son Kwon wrote:
> Hi all:
> I am Korean user.
> At http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/fonts/encodings/,
> there are many fonts which seems to be distributed as default.
>
> But as for Korean fonts, few fonts are distributed together hence
> users should add & configure Korean fonts manually which takes much time
> and discourages new users who do not have much experience with X before.
>
> We already have some free/open Korean fonts and some people are working
> on new fonts. If these Korean fonts can be added to the default distrubition,
> then it will greatly benefit many people.
>
> - Can anyone please let me know how to add Korean fonts to the default
> xorg source distribution? Is there any approval process?
> - What is the license requirement for that fonts?
> - What should be the technical font format for this?
>
> Any comments are welcomed.
>
> Thanks very much.
From Nicolas.Mailhot at laPoste.net Fri Aug 6 08:44:09 2004
Date: Fri Aug 6 08:44:22 2004
In-Reply-To: <4113A149.7020006@sun.com>
<4113A149.7020006@sun.com>
Message-ID: <1091807049.30930.7.camel@m54.net81-64-155.noos.fr>
On ven, 2004-08-06 at 08:18 -0700, Alan Coopersmith wrote:
> xorg@freedesktop.org is the mailing list for xorg, and would be a much
> better place to discuss adding fonts to the X.Org distribution, so I've
> cc'ed it.
>
> I believe the license requirements are that it be some sort of open source
> license, but that the requirements for fonts are a bit looser than source
> code.
>
> TrueType fonts are the currently preferred format.
And of course the preferred way would be to have a single set of
consistent truetype fonts with full unicode coverage.
If everyone could just contribute glyphs to a single font family (the
Vera fonts Bitstream liberated for gnome seems a good base) instead of
multiplying fonts with partial coverage this would be better for all of
us.
Cheers,
--
Nicolas Mailhot
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/d768808c/attach
ment.pgp
From sandmann at daimi.au.dk Fri Aug 6 08:34:32 2004
Date: Fri Aug 6 09:30:25 2004
Subject: [Xorg] Prefetching extensions
Message-ID: <ye88ycsnuuv.fsf@ec02.daimi.au.dk>
People who read the minutes of the recent architecture board meeting
will know that the conclusion wrt. an extension extension was to delay
it until hardware will make it a necessity and instead apply a hack to
Xlib to reduce the number of round-trips on startup.
So here is an Xlib hack that does two things
(a) It adds a new
XPrefetchExtensions (char **names, int count)
call that in a single roundtrip will query the extensions and
store the result in a cache. Subsequent calls to
XQueryExtensions(), both direct and indirect though things like
XRenderQueryExtension() will then return without any
roundtrips.
(b) Makes XOpenDisplay() use XPrefetchExtensions() to
batch together the initial queries for BIGREQUESTS, XKEYBOARD
with and the initial GetPropeerty it does.
This is not material for the upcoming release of course.
For people worried about the performance of the linked list caching
scheme, remember that only a small number of extensions are ever
queried for.
S?ren
-------------- next part --------------
Name: prefetch
Size: 11458 bytes
Desc: The patch
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/b3204e74/prefet
ch.obj
-------------- next part --------------
Name: PrefetchExtensions.c
Size: 3828 bytes
Desc: PrefetchExtensions.c
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/b3204e74/Prefet
chExtensions.obj
From keithp at keithp.com Fri Aug 6 09:28:06 2004
Date: Fri Aug 6 09:34:47 2004
In-Reply-To: Your message of "Wed, 04 Aug 2004 19:19:43 +0200."
<41111AAF.2A622B64@nrubsig.org>
Message-ID: <E1Bt7Ze-0005JP-J4@evo.keithp.com>
> I noticed that I haven't received any e-mail from bugzilla to the
> xorg-bugzilla-noise list since July 14. Does anyone know why?
I fixed this a couple of days ago; all of the mail was pending moderation
because mailman somehow lost that bugzilla was allowed to post to the list.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/8f8e6d5e/attach
ment.pgp
Date: Fri Aug 6 10:20:30 2004
In-Reply-To: Your message of "Fri, 06 Aug 2004 17:44:09 +0200."
<1091807049.30930.7.camel@m54.net81-64-155.noos.fr>
Message-ID: <E1Bt8Nz-0005Nt-Pw@evo.keithp.com>
Around 17 o'clock on Aug 6, Nicolas Mailhot wrote:
> And of course the preferred way would be to have a single set of
> consistent truetype fonts with full unicode coverage.
That's (unfortunately) not really possible. Korean, Japanese and Chinese
use overlapping sections of Unicode, so you need three separate fonts to
display these languages correctly. I believe most readers of these
languages can make sense out of the alternate representations, but it's
somewhat akin to a English reader trying to make sense of Arabic numerals
(that's probably overstating the case a bit, but I wanted to use an
example most of us can directly experience).
Besides, typefaces have a specific "style" which is often only suitable
for a limited number of character sets; the various curves and stems are
tightly tied to the expected letterform variations. One can often extend
a Latin typeface to Cyrillic, but not to Devanagari.
Take a look at Arial Unicode to see what happens when you try to mash all
of Unicode into a single "font". Yuck. (well, ok, Arial itself is an
ugly clone of Helvetica, but still).
Once you accept that a single typeface cannot cover all of Unicode, you
simply create applications and mechanisms that can blend multiple fonts
together to present the user's data. Fontconfig tries to help with this
process, and both Qt and Pango manage quite nicely at this point. Xterm
could use some help in this area.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/ac437d69/attach
ment-0001.pgp
From ufz6 at rz.uni-karlsruhe.de Fri Aug 6 10:30:25 2004
From: ufz6 at rz.uni-karlsruhe.de (Amir Bukhari)
Date: Fri Aug 6 10:29:52 2004
Subject: [Xorg] XComposite, XDamage Extension with Xvideo or GL
Message-ID: <E1Bt8XN-0004Oy-00@mailgate.rz.uni-karlsruhe.de>
Redirect OpenGL application to backing store pixmap does not work with
Composite Extension (in Manual Mode) (Xserver always draw).
Is GLX use a wrapper functions for GC Operations, which let the Deron
Johnson hacks of GC wrapper functions in Composite extension not work OR
there is others reason? We use it by project Looking Glass.
Note that most GLX modules come with graphic card, which we could not hack
it directly.
Xvideo uses the overlay feature of the video cards to draw the video on the
screen, which bring trouble with composite extension. I heared there is a
discussion about how to get Xvideo to work with Composite extension, is that
right?
Amir Bukhari
E-Mail: ufz6@rz.uni-karlsruhe.de
Date: Fri Aug 6 10:45:44 2004
In-Reply-To: Your message of "Fri, 06 Aug 2004 19:30:25 +0200."
<E1Bt8XN-0004Oy-00@mailgate.rz.uni-karlsruhe.de>
Message-ID: <E1Bt8mS-0005RQ-Mz@evo.keithp.com>
Around 19 o'clock on Aug 6, "Amir Bukhari" wrote:
> Redirect OpenGL application to backing store pixmap does not work with
> Composite Extension (in Manual Mode) (Xserver always draw).
Correct. Fixing GLX to draw to off-screen memory will require additional
work.
> Xvideo uses the overlay feature of the video cards to draw the video on the
> screen, which bring trouble with composite extension. I heared there is a
> discussion about how to get Xvideo to work with Composite extension, is that
> right?
For simple decoration and animation hacks, the overlays will "work", but
for more sophisticated manipulation, the drivers need to be modified to
use the 3D texturing engine to convert the YUV image to RGB data in the
off-screen pixmap. The kdrive-based Xati server demonstrates how to do
that for R128 and R100 hardware.
The XFree86-based Matrox driver has code to use the texture engine, but
will need a modest amount of work to make it support Composite correctly.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/46b0df1a/attach
ment.pgp
From aritger at nvidia.com Fri Aug 6 10:41:52 2004
From: aritger at nvidia.com (Andy Ritger)
Date: Fri Aug 6 10:46:58 2004
In-Reply-To: <E1Bt8XN-0004Oy-00@mailgate.rz.uni-karlsruhe.de>
References: <E1Bt8XN-0004Oy-00@mailgate.rz.uni-karlsruhe.de>
Message-ID: <Pine.LNX.4.58.0408061337100.29176@paert.nvidia.com>
The technical challenges of Damage/Composite with direct rendering
clients have been discussed in threads such as this one:
http://freedesktop.org/pipermail/xorg/2004-May/000607.html
I believe Damage/Composite + GLX direct rendering clients is a
solvable problem, but there will be a significant performance
impact, and it will be a long term project (eg: I do not have an
ETA of when NVIDIA will be able to provide an OpenGL driver that
interacts correctly with Damage/Composite; I'm not familiar with
DRI's schedule for Damage/Composite support).
I do not believe video overlays will be usable with Damage/Composite.
Thanks,
- Andy
On Fri, 6 Aug 2004, Amir Bukhari wrote:
> Redirect OpenGL application to backing store pixmap does not work with
> Composite Extension (in Manual Mode) (Xserver always draw).
> Is GLX use a wrapper functions for GC Operations, which let the Deron
> Johnson hacks of GC wrapper functions in Composite extension not work OR
> there is others reason? We use it by project Looking Glass.
> Note that most GLX modules come with graphic card, which we could not hack
> it directly.
>
> Xvideo uses the overlay feature of the video cards to draw the video on the
> screen, which bring trouble with composite extension. I heared there is a
> discussion about how to get Xvideo to work with Composite extension, is that
> right?
>
> Amir Bukhari
> E-Mail: ufz6@rz.uni-karlsruhe.de
>
> _______________________________________________
> xorg mailing list
>
From ufz6 at rz.uni-karlsruhe.de Fri Aug 6 11:14:24 2004
Date: Fri Aug 6 11:13:51 2004
In-Reply-To: <E1Bt8mS-0005RQ-Mz@evo.keithp.com>
Message-ID: <E1Bt9Dw-0002Kh-00@mailgate.rz.uni-karlsruhe.de>

> Correct. Fixing GLX to draw to off-screen memory will require additional
> work.
It seems as I read the old discussions about this issue, it is complex
issue.
Is there any Work in progress?
From carl at personnelware.com Fri Aug 6 11:57:13 2004
Date: Fri Aug 6 11:56:23 2004
Subject: [Xorg] tinderbox bured out my laptop
Message-ID: <259701c47be7$2f81e400$1e01a8c0@cnt496>
806071207.log
/usr/include/math.h:-21758: internal compiler error: Bus errorGuessing it over
heated. I am pulling my boxes until the tinderbox is a bit more tender with my
boxes.Carl Khttp://www.personnelware.com/carl/resume.html
From sandmann at daimi.au.dk Fri Aug 6 11:33:19 2004
Date: Fri Aug 6 12:29:03 2004
Subject: [Xorg] Composite and ABI stability
Message-ID: <ye8oelo5d74.fsf@horse08.daimi.au.dk>
In bug 990, Eric Anholt reports that X server compiled with COMPOSITE
produce wrong colors and suspects that this is cause alphaMask and
alphaOffset in Visuals are not initialized.
This is correct; modfiying the i830 driver to initialize those fields
does make the problem go away. However, there is a bigger problem than
that:
typedef struct _Visual {
VisualID vid;
short class;
short bitsPerRGBValue;
short ColormapEntries;
short nplanes;/* = log2 (ColormapEntries). This does not
* imply that the screen has this many planes.
* it may have more or fewer */
unsigned long redMask, greenMask, blueMask;
int offsetRed, offsetGreen, offsetBlue;
#ifdef COMPOSITE
unsigned long alphaMask;
int offsetAlpha;
#endif
} VisualRec;
The two added fields break binary compatibility because drivers are
passed arrays of Visuals though screens and are expected to initialize
them. There is a similar problem with Pixmaps which also get two
additional fields.
If we are guaranteeing binary compatibility with existing drivers,
this has to be done in a different way.
Some possible solutions:
1. In compinit.c simply initialzie all the existing alpha
masks to 0. This will break compatibility and prevent
hardware from advertising its own alpha visuals
2. Fix all drivers to initialize the fields properly. This
will break compatibility in the Composite case.
3. Rework the way composite has been integrated to now change
the size of Visuals and Pixmaps and make composite
responsible for initializing the new fields.
To me, 3 seems the right solution, but I could be wrong.
S?ren
From kem at freedesktop.org Fri Aug 6 12:48:30 2004
Date: Fri Aug 6 12:48:41 2004
In-Reply-To: <ye8oelo5d74.fsf@horse08.daimi.au.dk>
References: <ye8oelo5d74.fsf@horse08.daimi.au.dk>
On Fri, Aug 06, 2004 at 08:33:19PM +0200, Soeren Sandmann wrote:
> In bug 990, Eric Anholt reports that X server compiled with COMPOSITE
^^^^^^^^^^^
Kevin Martin
> produce wrong colors and suspects that this is cause alphaMask and
> alphaOffset in Visuals are not initialized.
>
> This is correct;
Thank you for confirming this issue.
> modfiying the i830 driver to initialize those fields
> does make the problem go away. However, there is a bigger problem than
> that:
>
> typedef struct _Visual {
> VisualID vid;
> short class;
> short bitsPerRGBValue;
> short ColormapEntries;
> short nplanes;/* = log2 (ColormapEntries). This does not
> * imply that the screen has this many planes.
> * it may have more or fewer */
> unsigned long redMask, greenMask, blueMask;
> int offsetRed, offsetGreen, offsetBlue;
> #ifdef COMPOSITE
> unsigned long alphaMask;
> int offsetAlpha;
> #endif
> } VisualRec;
>
>
> The two added fields break binary compatibility because drivers are
> passed arrays of Visuals though screens and are expected to initialize
> them. There is a similar problem with Pixmaps which also get two
> additional fields.
>
> If we are guaranteeing binary compatibility with existing drivers,
> this has to be done in a different way.
>
> Some possible solutions:
>
> 1. In compinit.c simply initialzie all the existing alpha
> masks to 0. This will break compatibility and prevent
> hardware from advertising its own alpha visuals
>
> 2. Fix all drivers to initialize the fields properly. This
> will break compatibility in the Composite case.
>
> 3. Rework the way composite has been integrated to now change
> the size of Visuals and Pixmaps and make composite
> responsible for initializing the new fields.
>
> To me, 3 seems the right solution, but I could be wrong.
I agree with your assessment and recently added a comment to bug #991
along similar lines -- i.e., create an "extended" visual structure that
only Composite would export. A similar approach could be taken with
pixmaps. This should solve both the ABI issue as well as the exposing
visuals problem (bug #991).
Another solution, if it is not possible to fix the ABI issues, is to
simply disable compiling Composite by default for the release.
Date: Fri Aug 6 13:13:17 2004
<ye8oelo5d74.fsf@horse08.daimi.au.dk>
Message-ID: <E1BtB59-0005Xz-4G@evo.keithp.com>
> #ifdef COMPOSITE
> unsigned long alphaMask;
> int offsetAlpha;
> #endif
I didn't remember this part of the work. It's really not necessary part
of the Composite implementation, it's only used to 'kludge' the color
lookup code in colormap.c to return colors with alpha bits already set to
one.
We can easily fix this by having the colormap code call directly into the
composite extension and get the appropriate values for "non-core" visuals.
I'll see about fixing this after I get trapezoids integrated into CVS.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/9a944d8a/attach
ment.pgp
Date: Fri Aug 6 13:16:01 2004
In-Reply-To: Your message of "Fri, 06 Aug 2004 15:48:30 EDT."
<20040806194830.GA30491@kem.org>
Message-ID: <E1BtB7r-0005YE-ML@evo.keithp.com>
Around 15 o'clock on Aug 6, Kevin E Martin wrote:
> Another solution, if it is not possible to fix the ABI issues, is to
> simply disable compiling Composite by default for the release.
We can also simply remove the visual ABI changes -- they're only used to
kludge AllocColor (et al) to add alpha bits to server-side color
allocations. Presumably a "knowledgable" client will know what to do with
color allocations already. As a point of interest -- neither Gtk+ nor Qt
will benefit from the server-side kludge as they always perform color
allocation on the client side for TrueColor visuals, so the code as built
today doesn't actually help all that much.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/cf750297/attach
ment.pgp
From Deron.Johnson at Sun.COM Fri Aug 6 13:16:38 2004
From: Deron.Johnson at Sun.COM (Deron Johnson)
Date: Fri Aug 6 13:16:43 2004
In-Reply-To: <E1BtB59-0005Xz-4G@evo.keithp.com>
References: <E1BtB59-0005Xz-4G@evo.keithp.com>
Message-ID: <4113E726.1020901@Sun.COM>
I mentioned this in an e-mail last week to Keith and Eric Anholt as one
of the issues with Composite that needs to be resolved.
Keith, Eric: did you get that e-mail? It contained other issues that
need attention.
In my work with Composite, I had to leave out the ARGB visual stuff
entirely. Would it be possible to include the ARGB visual changes
in a separate ifdef, say, #ifdef ARGB_VISUAL?
> Around 20 o'clock on Aug 6, Soeren Sandmann wrote:
>
>
>>#ifdef COMPOSITE
>> unsigned long alphaMask;
>> int offsetAlpha;
>>#endif
>
>
> I didn't remember this part of the work. It's really not necessary part
> of the Composite implementation, it's only used to 'kludge' the color
> lookup code in colormap.c to return colors with alpha bits already set to
> one.
>
> We can easily fix this by having the colormap code call directly into the
> composite extension and get the appropriate values for "non-core" visuals.
>
> I'll see about fixing this after I get trapezoids integrated into CVS.
>
> -keith
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xorg mailing list
Date: Fri Aug 6 13:28:22 2004
In-Reply-To: Your message of "Fri, 06 Aug 2004 13:16:38 PDT."
<4113E726.1020901@Sun.COM>
Message-ID: <E1BtBJn-0006KA-JO@evo.keithp.com>
Around 13 o'clock on Aug 6, Deron Johnson wrote:
> In my work with Composite, I had to leave out the ARGB visual stuff
> entirely. Would it be possible to include the ARGB visual changes
> in a separate ifdef, say, #ifdef ARGB_VISUAL?
There's no need to leave out the new visual creation code in Composite,
all we need to do is not tell the rest of the X server where the alpha
bits lie. Simply removing alphaMask/offsetAlpha from the visual structure
and deleting the related code in colormap.c should restore sanity (and
compatibility) to this structure.
Bothersome that this structure turns out to be placed in arrays and hence
unextendable.
I will try to figure out how to advertise visuals through the Composite
extension for applications interested in using ARGB visuals; I think
that's a more sensible approach in any case.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/288ff20c/attach
ment.pgp
From idr at us.ibm.com Fri Aug 6 13:27:53 2004
From: idr at us.ibm.com (Ian Romanick)
Date: Fri Aug 6 13:59:16 2004
In-Reply-To: <ye8oelo5d74.fsf@horse08.daimi.au.dk>
References: <ye8oelo5d74.fsf@horse08.daimi.au.dk>
Message-ID: <4113E9C9.9060903@us.ibm.com>
> In bug 990, Eric Anholt reports that X server compiled with COMPOSITE
> produce wrong colors and suspects that this is cause alphaMask and
> alphaOffset in Visuals are not initialized.
>
> This is correct; modfiying the i830 driver to initialize those fields
> does make the problem go away. However, there is a bigger problem than
> that:
I ran into a similar problem a few months ago (probably closer to a year
ago now) with respect to GLX visuals on the client-side and on the
server-side. My solution was to use a new structure, _GLcontextModes,
to represent the data. The data provided by the driver in the old
structure was converted to the new structure by a device-independent layer.
Date: Fri Aug 6 14:14:24 2004
<4113E9C9.9060903@us.ibm.com>
Message-ID: <E1BtC2E-0007xg-Ku@evo.keithp.com>
Around 13 o'clock on Aug 6, Ian Romanick wrote:
> I ran into a similar problem a few months ago (probably closer to a year
> ago now) with respect to GLX visuals on the client-side and on the
> server-side.
Fortunately, I already have a structure on both server and client sides
representing the visual structure -- the PictureFormat contains everything
needed. Removing the alpha fields from the visual affects *only* the
ability of the core colormap code to pre-fill pixels with solid alpha
values. This helped me get Xterm running on the ARGB visual, but had no
effect on Gtk+ or Qt applications (which have their own client-side
TrueColor pixel allocation code).
I could also hard-code the pixel computations so that all bits from RGB to
depth are set to one. Or, we could kludge the colormap code to call back
into the composite code to figure out what to do. Anything but add
elements to the Visual structure in the server.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/af96b6d3/attach
ment.pgp
From bryce at osdl.org Fri Aug 6 14:35:23 2004
Date: Fri Aug 6 14:35:30 2004
Subject: [Xorg] Xorg tinderbox chat
In-Reply-To: <259701c47be7$2f81e400$1e01a8c0@cnt496>
Kiko, Jim, and I had a chat on Tinderbox this morning. Some notes:
Current Tinderbox status:
* anholt-LC FreeBSD - has been in state 'compiling' for a couple days
now, is it dead?
* cfk.cp1 Linux - Appears to be having trouble doing CVS checkouts
maybe? Isn't getting very far into the process.
* mh-OpenBSD-amd64 OpenBSD 3.5 - Seems to be having trouble linking a
library. Kiko wonders if this is a build system config issue? Maybe
a library version mismatch?
For scoping out the set of machines we may eventually want in the
system, Jim mentions that the number of permutations gets quite large,
especially when you look at the breadth of configs, distros, etc. We'll
probably need to figure out a good 'sparse matrix' that provides
sufficient coverage. Kiko mentions that Tinderbox also provides
mechanisms for splitting the results out into separate pages.
Bonzai was identified as an important next step to getting additional
value from this setup. After that, Jim indicated three automated tests
that would be worth hooking in: xfw4, x11perf, and rendertest.
It was commented that Xorg is going to need to start assembling the
equivalent of a QA-oriented team to investigate, try out, and hook up
these and other tests as we go forward.
There were a lot of other topics touched on, but I hope this captures
the gist of it.
Bryce
On Fri, 6 Aug 2004, Carl Karsten wrote:
40806071207.log
> /usr/include/math.h:-21758: internal compiler error: Bus errorGuessing it over
> heated. I am pulling my boxes until the tinderbox is a bit more tender with m
y
> boxes.Carl Khttp://www.personnelware.com/carl/resume.html
>
> _______________________________________________
> xorg mailing list
>
From carl at personnelware.com Fri Aug 6 16:39:35 2004
Date: Fri Aug 6 16:38:51 2004
Subject: [Xorg] Re: Xorg tinderbox chat
References: <Pine.LNX.4.33.0408061305300.28769-100000@osdlab.pdx.osdl.net>
Message-ID: <26e001c47c0e$a404f070$1e01a8c0@cnt496>
> * cfk.cp1 Linux - Appears to be having trouble doing CVS checkouts
> maybe? Isn't getting very far into the process.
It had trouble doing anything:
> > /usr/include/math.h:-21758: internal compiler error: Bus error
> > Guessing it over
> > heated.
Keep me posted. I have boxes.
Carl K
Date: Fri Aug 6 18:12:46 2004
In-Reply-To: <20040806210629.J2563@ada.dhs.org>
<4113A149.7020006@sun.com>
<6555429d0408061645329bf72d@mail.gmail.com>
<20040806210629.J2563@ada.dhs.org>
Message-ID: <41142C50.5080803@Sun.COM>
Ambrose Li wrote:
> Hi,
>
> On Sat, Aug 07, 2004 at 08:45:57AM +0900, Soon-Son Kwon wrote:
>
>
>>I think font is something like picture or novel which does
>>not need to be freely modified. The font designers won't like
>>that though some will. I remember that in the current xorg
>>distribution, modifiable/non-modifiable fonts are mixed.
>
>
> I agree that the designers won't like it, but I disagree that
> fonts need not be freely modified.
The middle ground is the license used by the Bitstream Vera fonts
(which are the only fonts I know of added to Xorg recently) - they
allow changes, but only if you rename your changed version so it's
clear it's not the work of their designers.
http://www.gnome.org/fonts/
--
Date: Fri Aug 6 18:30:58 2004
Subject: [Xorg] Lots of changes today
Message-ID: <E1BtG2g-0003U9-K6@evo.keithp.com>
I imported the new trapezoid code today and then found several other
broken bits in the xorg tree which I fixed:
1) misprite hadn't been replaced yet. the xserver tree uses a new
implementation of misprite based on the damage code. This may seem
like an unnecessary change, but not so -- the new sprite code
cooperates with damage to avoid reporting changes when painting the
sprite on the screen. Without this change, the server will spin
whenever it uses a software cursor.
2) Xvfb didn't match "normal" PC hardware. This made my 'lightpipe'
damage test application unhappy so I just changed it. Much nicer
now. I also got rid of the mfb support.
3) I removed the new alpha fields in visuals. These made the driver
ABI change without offering any substantive benefits. The idea was
to report pixel values to clients that included the alpha bits so
"simple" applications would "just work" on ARGB visuals. Turns out
no modern toolkit bothers to ask the X server to translate RGB
values into pixels for TrueColor visuals, so this was mostly a
wasted effort in any case. If we want to revisit this, we will
need to stick the alpha data somewhere else.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/560192be/attach
ment.pgp
Date: Fri Aug 6 18:42:36 2004
<Pine.LNX.4.56.0408062135250.2410@localhost>
Message-ID: <E1BtGDx-0003VB-IF@evo.keithp.com>
Around 21 o'clock on Aug 6, Stuart Anderson wrote:
> > 2) Xvfb didn't match "normal" PC hardware.
>
> Can you elaborate on this a bit more? How did it not match "normal"?
Xvfb was letting the 'fb' code pick the RGB masks for pixels, so we got
BGR color order. It was also not picky about depths, so when you asked
for a x16 screen, you ended up with a depth 15 one. I'm afraid I
hard-coded this to depth 16 so that it worked correctly for me; a better
fix would be to respect the command line argument, but that seems "hard".
With the current setup, you can use 'lightpipe' to a "normal" PC graphics
card and things look right.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/30ff3469/attach
ment.pgp
From anderson at netsweng.com Fri Aug 6 18:36:02 2004
From: anderson at netsweng.com (Stuart Anderson)
Date: Fri Aug 6 18:53:03 2004
In-Reply-To: <E1BtG2g-0003U9-K6@evo.keithp.com>
References: <E1BtG2g-0003U9-K6@evo.keithp.com>
Message-ID: <Pine.LNX.4.56.0408062135250.2410@localhost>
On Fri, 6 Aug 2004, Keith Packard wrote:
> 2) Xvfb didn't match "normal" PC hardware. This made my 'lightpipe'
> damage test application unhappy so I just changed it. Much nicer
> now. I also got rid of the mfb support.
Can you elaborate on this a bit more? How did it not match "normal"?
Stuart
Stuart R. Anderson anderson@netsweng.com
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
Date: Fri Aug 6 19:04:56 2004
In-Reply-To: Your message of "Sat, 07 Aug 2004 03:54:57 +0200."
<41143671.34C7B15D@nrubsig.org>
Message-ID: <E1BtGZW-0004w8-TX@evo.keithp.com>
Around 3 o'clock on Aug 7, Roland Mainz wrote:
> What do you mean with "normal" PC hardware ? Do you mean something like
> making 24bit TrueColor the default visual for Xvfb or what ?
No, all I changed was the order of RGB within a TrueColor visual as well
as switching from depth 15 to depth 16 (a better depth fix would be nice).
> Maybe not "modern" toolkits (BTW: Did you check whether Motif and Athena
> applications still work ?)
Remember that this change was only designed to make legacy toolkits
operate with ARGB visuals. I have hacked xterm to kinda work in this mode
with these DIX changes, but it still took a lot of fixes within the xterm
code to make it all work more-or-less correctly.
Applications using the "normal" visuals see no change in any case.
If we think a change like this would be useful, we can go back and figure
out a way to do this without modifying the visual structure. It's not
that hard -- it's almost always just the bits in depth with those consumed
by RGB taken out.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/25d20182/attach
ment.pgp
From ksoonson at gmail.com Fri Aug 6 16:45:57 2004
From: ksoonson at gmail.com (Soon-Son Kwon)
Date: Fri Aug 6 19:38:14 2004
In-Reply-To: <1091807049.30930.7.camel@m54.net81-64-155.noos.fr>
<4113A149.7020006@sun.com>
Message-ID: <6555429d0408061645329bf72d@mail.gmail.com>
Thank you very much for the comments.
But still I do not fully understand how to add a new font
to the default xorg distribution. What is the detailed license
requirement? Alan's opinion is what I thought initially.
I think font is something like picture or novel which does not
need to be freely modified. The font designers won't like that though
some will. I remember that in the current xorg distribution,
modifiable/non-modifiable fonts are mixed.
Here are some free font project in Korea.
1. http://kldp.net/projects/unfonts/
- almost ready to release within a week.
- current snapshot can be downloaded from
http://chem.skku.ac.kr/~wkpark/project/font/UnFonts/20040805/ )
2. http://kldp.net/projects/baekmuk/
- actual fonts are in cvs tree
- already included in many linux distributions including debian/gentoo/fedora
Can anyone please check if these fonts are ready to be included?
We are also planning to apply for government fund for commercial high quality
fonts so that we can purchase the whole rights including free redistribution.
If xorg distribution can hold more fonts for double-byte character users,
then it would benefit many many people.
Thanks very much.
/Shawn
On Fri, 06 Aug 2004 17:44:09 +0200, Nicolas Mailhot
<nicolas.mailhot@laposte.net> wrote:
> On ven, 2004-08-06 at 08:18 -0700, Alan Coopersmith wrote:
> > xorg@freedesktop.org is the mailing list for xorg, and would be a much
> > better place to discuss adding fonts to the X.Org distribution, so I've
> > cc'ed it.
> >
> > I believe the license requirements are that it be some sort of open source
> > license, but that the requirements for fonts are a bit looser than source
> > code.
> >
> > TrueType fonts are the currently preferred format.
>
> And of course the preferred way would be to have a single set of
> consistent truetype fonts with full unicode coverage.
>
> If everyone could just contribute glyphs to a single font family (the
> Vera fonts Bitstream liberated for gnome seems a good base) instead of
> multiplying fonts with partial coverage this would be better for all of
> us.
>
> Cheers,
>
> --
> Nicolas Mailhot
>
>
>
--
http://kldp.org/~kss
Date: Fri Aug 6 19:47:48 2004
In-Reply-To: <E1BtG2g-0003U9-K6@evo.keithp.com>
Heya Keith,
anholt's box is showing an issue with the do_traps.c code on his
machine, presumably related to this set of changes. The logs don't
pinpoint the exact cause but it seems to be around line 113 of
do_traps.c:
0040806175804.log
Bryce
> I imported the new trapezoid code today and then found several other
> broken bits in the xorg tree which I fixed:
>
> 1) misprite hadn't been replaced yet. the xserver tree uses a new
> implementation of misprite based on the damage code. This may seem
> like an unnecessary change, but not so -- the new sprite code
> cooperates with damage to avoid reporting changes when painting the
> sprite on the screen. Without this change, the server will spin
> whenever it uses a software cursor.
>
>
> 3) I removed the new alpha fields in visuals. These made the driver
> ABI change without offering any substantive benefits. The idea was
> to report pixel values to clients that included the alpha bits so
> "simple" applications would "just work" on ARGB visuals. Turns out
> no modern toolkit bothers to ask the X server to translate RGB
> values into pixels for TrueColor visuals, so this was mostly a
> wasted effort in any case. If we want to revisit this, we will
> need to stick the alpha data somewhere else.
>
> -keith
>
>
>
From Jim.Gettys at hp.com Fri Aug 6 19:51:44 2004
Date: Fri Aug 6 19:51:55 2004
In-Reply-To: <6555429d0408061645329bf72d@mail.gmail.com>
<4113A149.7020006@sun.com>
Please take a look at the license I worked out with Bitstream
for the Vera fonts.
It manages to meet free software standards, while protecting
the interests of the font designers to not have their name
on modifications they do not approve of, and ensuring that
they not just be dropped into a font resale system, but allowing
them to be used in any other circumstance freely.
See http://www.gnome.org/fonts
Fonts need on-going maintenance (new characters need
to be added from time to time), so unmodifiable fonts end up,
with time, not being all that useful.
Regards,
- Jim Gettys
On Fri, 2004-08-06 at 19:45, Soon-Son Kwon wrote:
> Thank you very much for the comments.
>
> But still I do not fully understand how to add a new font
> to the default xorg distribution. What is the detailed license
> requirement? Alan's opinion is what I thought initially.
>
> I think font is something like picture or novel which does not
> need to be freely modified. The font designers won't like that though
> some will. I remember that in the current xorg distribution,
> modifiable/non-modifiable fonts are mixed.
>
> Here are some free font project in Korea.
> 1. http://kldp.net/projects/unfonts/
> - almost ready to release within a week.
> - current snapshot can be downloaded from
> http://chem.skku.ac.kr/~wkpark/project/font/UnFonts/20040805/ )
>
> 2. http://kldp.net/projects/baekmuk/
> - actual fonts are in cvs tree
> - already included in many linux distributions including debian/gentoo/fedora
>
> Can anyone please check if these fonts are ready to be included?
> We are also planning to apply for government fund for commercial high quality
> fonts so that we can purchase the whole rights including free redistribution.
>
> If xorg distribution can hold more fonts for double-byte character users,
> then it would benefit many many people.
>
> Thanks very much.
>
> /Shawn
>
>
> On Fri, 06 Aug 2004 17:44:09 +0200, Nicolas Mailhot
> <nicolas.mailhot@laposte.net> wrote:
> > On ven, 2004-08-06 at 08:18 -0700, Alan Coopersmith wrote:
> > > xorg@freedesktop.org is the mailing list for xorg, and would be a much
> > > better place to discuss adding fonts to the X.Org distribution, so I've
> > > cc'ed it.
> > >
> > > I believe the license requirements are that it be some sort of open source
> > > license, but that the requirements for fonts are a bit looser than source
> > > code.
> > >
> > > TrueType fonts are the currently preferred format.
> >
> > And of course the preferred way would be to have a single set of
> > consistent truetype fonts with full unicode coverage.
> >
> > If everyone could just contribute glyphs to a single font family (the
> > Vera fonts Bitstream liberated for gnome seems a good base) instead of
> > multiplying fonts with partial coverage this would be better for all of
> > us.
> >
> > Cheers,
> >
> > --
> > Nicolas Mailhot
> >
> >
> >
>
From aplattner at nvidia.com Fri Aug 6 20:00:59 2004
From: aplattner at nvidia.com (Aaron Plattner)
Date: Fri Aug 6 20:12:34 2004
Subject: [Xorg] RandR physical screen size question
Message-ID: <20040807030059.GA23012@homeworld.dnsalias.net>
While working on rotation issues, I've noticed that xf86RandRGetInfo calculates
the physical screen size as

pScreen->mmWidth * randrp->virtualX / scrp->currentMode->HDisplay,
pScreen->mmHeight * randrp->virtualY / scrp->currentMode->VDisplay
in the case where the current mode is different from the screen's virtual size.
Originally, this function simply looked for any mode matching the virtual size,
but it was modified in response to XFree86's bug #853
(http://bugzilla.xfree86.org/show_bug.cgi?id=853).
This leads to the following behavior:
[aaron@dhcp-178-206 common]$ xrandr
SZ: Pixels Physical Refresh
*0 1280 x 1024 ( 361mm x 292mm ) *75 60
1 1024 x 768 ( 361mm x 292mm ) 85 75 70 60
[...]
16 320 x 200 ( 361mm x 292mm ) 85
17 320 x 175 ( 361mm x 292mm ) 85
Current rotation - left
Current reflection - none
Rotations possible - normal left inverted right
Reflections possible - none
[Hit ctrl-alt-+]
[aaron@dhcp-178-206 common]$ xrandr
SZ: Pixels Physical Refresh
0 1280 x 1024 ( 361mm x 292mm ) 75 60
1 1024 x 768 ( 361mm x 292mm ) 85 75 70 60
[...]
16 320 x 200 ( 361mm x 292mm ) 85
17 320 x 175 ( 361mm x 292mm ) 85
*18 1280 x 1024 ( 451mm x 389mm ) *75
Current rotation - left
Current reflection - none
Rotations possible - normal left inverted right
Reflections possible - none
Notice the new mode with the bogus physical size.
My question is, is this intentional, or a bug? Why isn't the physical
size simply set to pScreen->mmWidth x pScreen->mmHeight?
Thanks!
-- Aaron Plattner
From fxjrlists at yahoo.com.br Fri Aug 6 20:21:22 2004
From: fxjrlists at yahoo.com.br (Francisco Figueiredo Jr.)
Date: Fri Aug 6 20:23:52 2004
Subject: [Xorg] Disabling XVideo because mode pixel rate.
Message-ID: <41144AB2.2040400@yahoo.com.br>
Hi all, Dawes,
I'm getting this message in xorg logs,
could you help me explain what it is??
Is there something I can do to lower the mode bandwidth?
Can this damage my lcd monitor?
Thanks in advance.
Xorg message:
(II) I810(0): Mode bandwidth is 88 Mpixel/s
(II) I810(0): maxBandwidth is 1152 Mbyte/s, pipe bandwidths are 164
Mbyte/s, 0 Mbyte/s
(II) I810(0): LFP compensation mode: 0x6
(II) I810(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Horizontal and Vertical Lines
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
18 256x256 slots
(==) I810(0): Backing store disabled
(==) I810(0): Silken mouse enabled
(II) I810(0): Initializing HW Cursor
(**) Option "dpms"
(**) I810(0): DPMS enabled
(WW) I810(0): Disabling XVideo output because the mode pixel rate (88 MHz)
exceeds the hardware limit (79 MHz)
From roland.mainz at nrubsig.org Fri Aug 6 18:54:57 2004
Date: Fri Aug 6 20:26:57 2004
References: <E1BtG2g-0003U9-K6@evo.keithp.com>
Message-ID: <41143671.34C7B15D@nrubsig.org>
[snip]
What do you mean with "normal" PC hardware ? Do you mean something like
making 24bit TrueColor the default visual for Xvfb or what ?
> 3) I removed the new alpha fields in visuals. These made the driver
> ABI change without offering any substantive benefits. The idea was
> to report pixel values to clients that included the alpha bits so
> "simple" applications would "just work" on ARGB visuals. Turns out
> no modern toolkit bothers to ask the X server to translate RGB
> values into pixels for TrueColor visuals, so this was mostly a
> wasted effort in any case.
Maybe not "modern" toolkits (BTW: Did you check whether Motif and Athena
applications still work ?) but there are some (toolkit-less)
applications which may depend on that (mpgdbx comes in mind). So the
question is whether those applications will still work or not...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Fri Aug 6 20:39:24 2004
<Pine.LNX.4.33.0408061945410.4961-100000@osdlab.pdx.osdl.net>
Message-ID: <E1BtI2v-00079W-Mu@evo.keithp.com>
Around 19 o'clock on Aug 6, Bryce Harrington wrote:
> anholt's box is showing an issue with the do_traps.c code on his
> machine, presumably related to this set of changes. The logs don't
> pinpoint the exact cause but it seems to be around line 113 of
> do_traps.c:
Looks like I committed code in the wrong order. I think it should be
fixed now; we'll see when the tinderbox comes around again. This release
is too darn big...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/4e305afc/attach
ment.pgp
Date: Fri Aug 6 20:42:41 2004
<20040807030059.GA23012@homeworld.dnsalias.net>
Message-ID: <E1BtI6A-0007A0-MZ@evo.keithp.com>
Around 20 o'clock on Aug 6, Aaron Plattner wrote:
> My question is, is this intentional, or a bug? Why isn't the physical
> size simply set to pScreen->mmWidth x pScreen->mmHeight?
That's a good question; I do what you suggest in the kdrive servers which
have supported rotation for "a while" now.
Could it have something to do with the virtual desktop mode?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/0be724e2/attach
ment.pgp
From gene.heskett at verizon.net Fri Aug 6 20:43:01 2004
Date: Fri Aug 6 20:49:28 2004
Subject: [Xorg] Odd messages in log, can someone explain?
Greetings;
Running what is supposed to be an upgrade to FC2, but its not all
working yet.
I just noted these in my Xorg.0.log:
-----------------
SetGrabKeysState - disabled
SetGrabKeysState - enabled
SetClientVersion: 0 8
Does anyone know what these mean?
It would be nice if these were time stamped, but there are none in
this log. Might that be an option one could set in Xorg.conf?
Thanks.
--
Cheers, Gene
Date: Fri Aug 6 20:55:22 2004
Subject: [Xorg] Any chance i810 driver not rely in vbios to get video modes ?
Message-ID: <41145217.3030608@yahoo.com.br>
Hi all,
I have a laptop which is capable of geting 1400x1050, but my bios
doesn't present this mode to i810 driver.
Is there any chance i810 driver not rely in bios to program video modes?
For while, I'm testing this program which changes the vbios and add the
1400 mode, but I'm getting an strange message about xvideo disabled[1].
Thanks in advance
Regards,
Francisco Figueiredo Jr.
[1]
Mbyte/s, 0 Mbyte/s
Offscreen Pixmaps
32 128x128 slots
18 256x256 slots
(**) Option "dpms"
(II) I810(0): X context handle = 0x00000001
Date: Fri Aug 6 21:24:20 2004
Subject: [Xorg] Any chance i810 driver not rely in vbios to get video
modes ?
In-Reply-To: Your message of "Sat, 07 Aug 2004 00:52:55 -0300."
<41145217.3030608@yahoo.com.br>
Message-ID: <E1BtIkS-0000Rd-UZ@evo.keithp.com>
Around 0 o'clock on Aug 7, "Francisco Figueiredo Jr." wrote:
> I have a laptop which is capable of geting 1400x1050, but my bios
> doesn't present this mode to i810 driver.
I've seen kludges around that make this work; you might poke about a bit
and report back if you find something that does the trick for you.
> Is there any chance i810 driver not rely in bios to program video modes?
Nope. Turns out it's "hard" because the i810 doesn't actually contain all
of the hardware needed to drive the display -- half of it is in an
external chip, and there are *many* possible chips for that job, none of
which are made by Intel and none of which have opened up their
documentation.
So, we have to rely on the BIOS to set up those external chips.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040806/20c47942/attach
ment.pgp
Date: Fri Aug 6 22:01:42 2004
In-Reply-To: <E1BtI2v-00079W-Mu@evo.keithp.com>
> Around 19 o'clock on Aug 6, Bryce Harrington wrote:
> > anholt's box is showing an issue with the do_traps.c code on his
> > machine, presumably related to this set of changes. The logs don't
> > pinpoint the exact cause but it seems to be around line 113 of
> > do_traps.c:
>
> Looks like I committed code in the wrong order. I think it should be
> fixed now; we'll see when the tinderbox comes around again. This release
> is too darn big...
Yeah, you're right, Xorg is Huge. But this is exactly the sort of thing
that Tinderbox Luvs. :-)
As of 12m ago, problem still appears unresolved, according to anholt's
FreeBSD's box. We need faster build machines. Anholt gets a geek-point
here though.
Bryce
Date: Fri Aug 6 23:06:38 2004
Subject: [Xorg] Any chance i810 driver not rely in vbios to get video
modes ?
In-Reply-To: <E1BtIkS-0000Rd-UZ@evo.keithp.com>
References: <E1BtIkS-0000Rd-UZ@evo.keithp.com>
Message-ID: <41145FF6.6020308@yahoo.com.br>
> Around 0 o'clock on Aug 7, "Francisco Figueiredo Jr." wrote:
>
>
>>I have a laptop which is capable of geting 1400x1050, but my bios
>>doesn't present this mode to i810 driver.
>
>
> I've seen kludges around that make this work; you might poke about a bit
> and report back if you find something that does the trick for you.
>
Hi Keith Packard!
I found one. It is 855resolution. http://perso.wanadoo.fr/apoirier/ It
worked and I could get the resolution, but I also got the following
message in xorg.log:
Mbyte/s, 0 Mbyte/s
Offscreen Pixmaps
32 128x128 slots
18 256x256 slots
(**) Option "dpms"
What does this mode pixel rate means?
Can this damage my lcd?
Is there someway I can lower this bandwidth without lowering resolution?
In 1280x1024 the mode pixel rate is 78 Mhz.
If no problem exist, the only affected things would be the blue screen
when viewing movies?
>
>>Is there any chance i810 driver not rely in bios to program video modes?
>
>
> Nope. Turns out it's "hard" because the i810 doesn't actually contain all
> of the hardware needed to drive the display -- half of it is in an
> external chip, and there are *many* possible chips for that job, none of
> which are made by Intel and none of which have opened up their
> documentation.
>
> So, we have to rely on the BIOS to set up those external chips.
>
hmmmm, ok. I noticed some companies do commercial xwindows drivers and I
found one which does the i810 programming without relying in vbios.
I wish docs about that could be made public so xorg guys could develop
the driver :)
Thanks in advance.
Regards,
From reed at reedmedia.net Fri Aug 6 23:12:30 2004
Date: Fri Aug 6 23:12:37 2004
Subject: using tinderbox (was Re: [Xorg] Debian/unstable tinderbox)
In-Reply-To: <Pine.LNX.4.33.0407282054010.9531-100000@osdlab.pdx.osdl.net>
On Wed, 28 Jul 2004, Bryce Harrington wrote:
> > I may have overlooked it, but where is the quick
> > how-to-get-started-with-tinderbox guide for Xorg?
>
> http://www.freedesktop.org/Software/TinderboxWiki
Thank you. (And thank you to Carl K.)
I have had it running the "Test" for a few hours.
The webpage says "Once you have found that your tinderbox is working, you
can change the tree from 'Test' to 'XMonolithic' in run-client.sh"
How do you know the tinderbox is working? How do I know when to change
from "Test" to "XMonolithic"?
I did look at the
http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test webpage
but I don't have any idea what this means.
Will it ("Test") stop? Or does it run forever?
Also, the TinderboxWiki webpage says "Once a day ... the entire directory
is deleted and the files checked out fresh".
Is there a way to skip that? I'd rather not download files again and again
... Isn't "cvs up -dP" good enough?
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
From reed at reedmedia.net Fri Aug 6 23:30:26 2004
Date: Fri Aug 6 23:30:35 2004
In-Reply-To: <Pine.LNX.4.43.0408062307260.11735-100000@pilchuck.reedmedia.net>
Answering some of my own questions below:
> The webpage says "Once you have found that your tinderbox is working, you
> can change the tree from 'Test' to 'XMonolithic' in run-client.sh"
>
> How do you know the tinderbox is working? How do I know when to change
> from "Test" to "XMonolithic"?
>
> I did look at the
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test webpage
> but I don't have any idea what this means.
I guess I found that in the "Show Log" where it said:
TINDERBOX FINISHED (SUCCESS) RUNNING 'make World' Sat, 07 Aug 2004
04:38:42 GMT
> Will it ("Test") stop? Or does it run forever?
I guess it does continue to run. I see it started again.
I have now changed to do the "XMonolithic" instead of the "Test". I am
still curious about the following:
> Also, the TinderboxWiki webpage says "Once a day ... the entire directory
> is deleted and the files checked out fresh".
>
> Is there a way to skip that? I'd rather not download files again and again
> ... Isn't "cvs up -dP" good enough?
Jeremy C. Reed
From ksoonson at gmail.com Fri Aug 6 21:56:43 2004
Date: Sat Aug 7 00:12:31 2004
<4113A149.7020006@sun.com>
Message-ID: <6555429d040806215671e0b0dc@mail.gmail.com>
Thank you very much for your comment.
It will be a nice reference for our future work.
As for now, the font I mentioned are licensed under GPL
and especially the UnFont( http://kldp.net/projects/unfonts/ )
is about to be released within a few days.
(wkpark(he is in the To: list of this email also from the beginning)
is the maintainer)
He hopes that the UnFont can be included to the current xorg distribution
so that users do not have to manually setup Korean font.
The current xorg distribution does not have nice Korean
font so users should always download / setup fonts in Korea.
I will let you xorg developers know once the UnFont is released.
I hope xorg add this font so that Korean users need not spend
too much time in the future.
Regards...
/Shawn
On Fri, 06 Aug 2004 22:51:44 -0400, Jim Gettys <jim.gettys@hp.com> wrote:
> Please take a look at the license I worked out with Bitstream
> for the Vera fonts.
>
> It manages to meet free software standards, while protecting
> the interests of the font designers to not have their name
> on modifications they do not approve of, and ensuring that
> they not just be dropped into a font resale system, but allowing
> them to be used in any other circumstance freely.
>
> See http://www.gnome.org/fonts
>
> Fonts need on-going maintenance (new characters need
> to be added from time to time), so unmodifiable fonts end up,
> with time, not being all that useful.
> Regards,
> - Jim Gettys
>
>
>
> On Fri, 2004-08-06 at 19:45, Soon-Son Kwon wrote:
> > Thank you very much for the comments.
> >
> > But still I do not fully understand how to add a new font
> > to the default xorg distribution. What is the detailed license
> > requirement? Alan's opinion is what I thought initially.
> >
> > I think font is something like picture or novel which does not
> > need to be freely modified. The font designers won't like that though
> > some will. I remember that in the current xorg distribution,
> > modifiable/non-modifiable fonts are mixed.
> >
> > Here are some free font project in Korea.
> > 1. http://kldp.net/projects/unfonts/
> > - almost ready to release within a week.
> > - current snapshot can be downloaded from
> > http://chem.skku.ac.kr/~wkpark/project/font/UnFonts/20040805/ )
> >
> > 2. http://kldp.net/projects/baekmuk/
> > - actual fonts are in cvs tree
> > - already included in many linux distributions including debian/gentoo/fedor
a
> >
> > Can anyone please check if these fonts are ready to be included?
> > We are also planning to apply for government fund for commercial high qualit
y
> > fonts so that we can purchase the whole rights including free redistribution
.
> >
> > If xorg distribution can hold more fonts for double-byte character users,
> > then it would benefit many many people.
> >
> > Thanks very much.
> >
> > /Shawn
> >
> >
> > On Fri, 06 Aug 2004 17:44:09 +0200, Nicolas Mailhot
> > <nicolas.mailhot@laposte.net> wrote:
> > > On ven, 2004-08-06 at 08:18 -0700, Alan Coopersmith wrote:
> > > > xorg@freedesktop.org is the mailing list for xorg, and would be a much
> > > > better place to discuss adding fonts to the X.Org distribution, so I've
> > > > cc'ed it.
> > > >
> > > > I believe the license requirements are that it be some sort of open sour
ce
> > > > license, but that the requirements for fonts are a bit looser than sourc
e
> > > > code.
> > > >
> > > > TrueType fonts are the currently preferred format.
> > >
> > > And of course the preferred way would be to have a single set of
> > > consistent truetype fonts with full unicode coverage.
> > >
> > > If everyone could just contribute glyphs to a single font family (the
> > > Vera fonts Bitstream liberated for gnome seems a good base) instead of
> > > multiplying fonts with partial coverage this would be better for all of
> > > us.
> > >
> > > Cheers,
> > >
> > > --
> > > Nicolas Mailhot
> > >
> > >
> > >
> >
>
> _______________________________________________
> xorg mailing list
>
--
From sndirsch at suse.de Sat Aug 7 01:44:18 2004
Date: Sat Aug 7 01:44:22 2004
In-Reply-To: <20040803203347.GA26937@suse.de>
<20040803203347.GA26937@suse.de>
On Tue, Aug 03, 2004 at 10:33:47PM +0200, Stefan Dirsch wrote:
> On Tue, Aug 03, 2004 at 10:12:16PM +0200, Svetoslav Slavtchev wrote:
> > > Hi
> > >
> > > Any hints how to enable Composite extension? I know you can enable it
> > > already with "+extension Composite" command line option but I think
> > > there exists also "Extensions" section to enable/disable extensions
> > > like this.
> >
> > add smth like this :
> > Section "Extensions"
> > # Option "XEVIE" "Enable"
> > # Option "Composite" "Enable"
> > # Option "Composite" "Disable"
> > EndSection
>
> Hmm ... this only works for XEVIE.
>
> Option "XEVIE" "Disable"
> Option "Composite" "Enable"
> EndSection
>
> (==) Using config file: "/etc/X11/XF86Config"
> (EE) Extension "Composite" is unrecognized
> Problem when converting the config data structures
> (EE) Error parsing the config file
This works now with current CVS.
[...]
(**) Extension "Composite" is enabled
[...]
BTW, XEVIE is now disabled by default as well. IMHO this makes sense.
Stefan
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
From matthieu.herrb at laas.fr Sat Aug 7 02:03:52 2004
Date: Sat Aug 7 02:04:01 2004
Message-ID: <B4729DD1-E850-11D8-AC9E-000A956DE68C@laas.fr>
On 6 Aug 2004, at 23:35, Bryce Harrington wrote:
> Kiko, Jim, and I had a chat on Tinderbox this morning. Some notes:
>
> Current Tinderbox status:
> * anholt-LC FreeBSD - has been in state 'compiling' for a couple days
> now, is it dead?
> * cfk.cp1 Linux - Appears to be having trouble doing CVS checkouts
> maybe? Isn't getting very far into the process.
> * mh-OpenBSD-amd64 OpenBSD 3.5 - Seems to be having trouble linking a
> library. Kiko wonders if this is a build system config issue? Maybe
> a library version mismatch?
It's a library versioning issue. OpenBSD/amd64
doesn't understand the 3 number versioning scheme used by fontconfig.
I've a patch for that in OpenBSDLib.tmpl, but I'm currently not able to
commit to
freedesktop.org (ssh connection refused). This patch is attached below
if someone
wants to commit it before my net connectivity gets fixed.
-------------- next part --------------
Name: obsd.diff
Size: 6001 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040807/e8010a53/obsd.o
bj
-------------- next part --------------
From thomas at winischhofer.net Sat Aug 7 05:41:30 2004
Date: Sat Aug 7 05:41:22 2004
In-Reply-To: <B4729DD1-E850-11D8-AC9E-000A956DE68C@laas.fr>
<B4729DD1-E850-11D8-AC9E-000A956DE68C@laas.fr>
Message-ID: <4114CDFA.7070607@winischhofer.net>
>
> On 6 Aug 2004, at 23:35, Bryce Harrington wrote:
>
>> Kiko, Jim, and I had a chat on Tinderbox this morning. Some notes:
>>
>> Current Tinderbox status:
>> * anholt-LC FreeBSD - has been in state 'compiling' for a couple days
>> now, is it dead?
>> * cfk.cp1 Linux - Appears to be having trouble doing CVS checkouts
>> maybe? Isn't getting very far into the process.
>> * mh-OpenBSD-amd64 OpenBSD 3.5 - Seems to be having trouble linking a
>> library. Kiko wonders if this is a build system config issue? Maybe
>> a library version mismatch?
>
>
> It's a library versioning issue. OpenBSD/amd64
> doesn't understand the 3 number versioning scheme used by fontconfig.
> I've a patch for that in OpenBSDLib.tmpl, but I'm currently not able to
> commit to
> freedesktop.org (ssh connection refused). This patch is attached below
> if someone
> wants to commit it before my net connectivity gets fixed.
Done.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From sergiomb at netcabo.pt Sat Aug 7 08:18:47 2004
Date: Sat Aug 7 08:18:55 2004
In-Reply-To: <a728f9f9040806080953f5a40e@mail.gmail.com>
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<a728f9f9040806080953f5a40e@mail.gmail.com>
On Fri, 2004-08-06 at 16:09, Alex Deucher wrote:
> > > did you have those problems with DRI cvs or are they new with xorg?
> > > The streams code has be reshuffled a bit. also try with
> > > option "BCIForXv" "false" (or something like that; I forget the exact name
).
> >
> > Don't see any changes with option "BCIForXv" "false".
> >
> > The duplicated/translated image is new, a small problem in xine with xv
> > is old, happens with DRI cvs and still with xorg.
Only the old "little problem" happens with DRI cvs and still in xorg,
but could a xine problem.
>
> thanks I'll look into it as soon as I get a chance.
>
> Alex
Testing some 3D games emilia pinball, foobillard and Chromium works
perfectly.
you can found the "new problem" on tuxracer and quake3 demo.
hope that can help something
thanks,
> >
> > > thanks for testing.
> >
> > testings are welcomed, I'll try help you, where I could help you.
> > sorry for my bad English.
> > thanks,
> >
> >
> > > Alex
> > >
> > > >
> > > > best regards,
> >
> > --
> > S?rgio M. B.
> >
> >
--
S?rgio M. B.
Date: Sat Aug 7 09:05:00 2004
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<1091891927.4246.14.camel@darkstar>
On Sat, 2004-08-07 at 16:43, albert vilella wrote:
> I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
>
> is just pulling the cvs and compiling?
>
> Albert.
>
just pulling the cvs
apply this patch
( I just finished the preliminary merge. It seems to work ok in limited
testing. for those interested the patch is here:
http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff )
and uncomment on xc/config/cf/xorgsite.def
#define BuildDevelDRIDrivers YES
before compiling
best regards,
--
S?rgio M. B.
From ufz6 at rz.uni-karlsruhe.de Sat Aug 7 09:07:57 2004
Date: Sat Aug 7 09:07:22 2004
Message-ID: <E1BtTj5-0007S7-00@mailgate.rz.uni-karlsruhe.de>
> Around 19 o'clock on Aug 6, "Amir Bukhari" wrote:
>
> > Redirect OpenGL application to backing store pixmap does not work with
> > Composite Extension (in Manual Mode) (Xserver always draw).
>
> work.
>
If someone could give me some information about the implementation of GLX on
X Server, I could start playing with it to get GLX draw to off-screen (I
have got now a good picture of X implementation, so that I can begin hack on
it).
Is there a common Interface in X Server act as communication between X and
GLX and Graphic Card, which all GLX implementations use it.
From alexdeucher at gmail.com Sat Aug 7 09:08:01 2004
Date: Sat Aug 7 09:08:03 2004
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<1091891927.4246.14.camel@darkstar>
Message-ID: <a728f9f90408070908646dbefc@mail.gmail.com>
On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
<albertvilella@terra.es> wrote:
> I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
>
> is just pulling the cvs and compiling?
download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then
follow the mesa/xorg build instructions.
build instructions:
http://dri.sourceforge.net/cgi-bin/moin.cgi/Building
xorg patch:
Alex
>
> Albert.
>
> On Sat, 2004-08-07 at 17:18, S?rgio Monteiro Basto wrote:
> > On Fri, 2004-08-06 at 16:09, Alex Deucher wrote:
> > > > > did you have those problems with DRI cvs or are they new with xorg?
> > > > > The streams code has be reshuffled a bit. also try with
> > > > > option "BCIForXv" "false" (or something like that; I forget the exact
name).
> > > >
> > > > Don't see any changes with option "BCIForXv" "false".
> > > >
> > > > The duplicated/translated image is new, a small problem in xine with xv
> > > > is old, happens with DRI cvs and still with xorg.
> >
> >
> > Only the old "little problem" happens with DRI cvs and still in xorg,
> > but could a xine problem.
> >
> > >
> > > thanks I'll look into it as soon as I get a chance.
> > >
> > > Alex
> >
> > Testing some 3D games emilia pinball, foobillard and Chromium works
> > perfectly.
> > you can found the "new problem" on tuxracer and quake3 demo.
> >
> > hope that can help something
> >
> > thanks,
> >
> > > >
> > > > > thanks for testing.
> > > >
> > > > testings are welcomed, I'll try help you, where I could help you.
> > > > sorry for my bad English.
> > > > thanks,
> > > >
> > > >
> > > > > Alex
> > > > >
> > > > > >
> > > > > > best regards,
> > > >
> > > > --
> > > > S?rgio M. B.
> > > >
> > > >
> --
> ----------------------------
> jabberid avilella@jabber.org
> ----------------------------
>
>
Date: Sat Aug 7 09:26:58 2004
In-Reply-To: <a728f9f90408070908646dbefc@mail.gmail.com>
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<1091891927.4246.14.camel@darkstar>
<a728f9f90408070908646dbefc@mail.gmail.com>
On Sat, 2004-08-07 at 17:08, Alex Deucher wrote:
> On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
> <albertvilella@terra.es> wrote:
> > I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
> >
> > is just pulling the cvs and compiling?
>
> download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then
> follow the mesa/xorg build instructions.
>
> build instructions:
> http://dri.sourceforge.net/cgi-bin/moin.cgi/Building
> xorg patch:
I don't know what you mean about download Mesa cvs, xorg cvs comes with
one Mesa and I am using it. am I doing any thing wrong ?
I use this scripts:
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg login
(check out )
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg co -P xc
mkdir build
cd build
lndir ../xc
(create_drmkl.sh)
cd build/extras/drm/linux/
sh ../scripts/create_linux_pci_lists.sh < ../shared/drm_pciids.txt
(if you want linux kernel drm )
cd ..
scripts/create_lk_drm.sh /opt/xorgcvs/ 2.4
(or )
cd build/extras/drm/linux/
make
cp savage.o /lib/modules/ùname -r`/kernel/drivers/char/drm
(update cvs)
cvs -q -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg update -P xc
and finally in /etc/X11/xorg.conf
Section "Module"
# ...
Load "glx"
Load "dri"
# ...
EndSection
Section "DRI"
Mode 0666
EndSection
regards,
--
S?rgio M. B.
From alan at lxorguk.ukuu.org.uk Sat Aug 7 08:26:29 2004
Date: Sat Aug 7 09:28:56 2004
In-Reply-To: <1091807049.30930.7.camel@m54.net81-64-155.noos.fr>
<4113A149.7020006@sun.com>
On Gwe, 2004-08-06 at 16:44, Nicolas Mailhot wrote:
> If everyone could just contribute glyphs to a single font family (the
> Vera fonts Bitstream liberated for gnome seems a good base) instead of
> multiplying fonts with partial coverage this would be better for all of
> us.
Dafydd Harries has been attempting to get exactly this happening with
the Olwen font (Vera + extras). The name change to keep correctly wrt
the licensing rules on the name. Currently there are contributions for
Welsh and I think something like Serbian (I forget which)
Alan
Date: Sat Aug 7 09:35:20 2004
References: <E1Bt8mS-0005RQ-Mz@evo.keithp.com>
On Gwe, 2004-08-06 at 18:45, Keith Packard wrote:
> Around 19 o'clock on Aug 6, "Amir Bukhari" wrote:
>
> > Redirect OpenGL application to backing store pixmap does not work with
> > Composite Extension (in Manual Mode) (Xserver always draw).
>
> work.
Not a huge amount on the GL side. Generally the GL applications in
direct mode are already drawing off screen anyway and then blitting to
the front display. A redirected OpenGL window would mean allocating
another back buffer somewhere (probably on the X side since only X can
deal with the "out of memory" failure sequence) and changing GL_FRONT to
use it if neccessary.
I suspect (GL hackers correct me) that it could even be deferred to the
point the app uses GL_FRONT.
Fixing X to know when and how to composite and do damage with it is the
fun side.
> For simple decoration and animation hacks, the overlays will "work", but
> for more sophisticated manipulation, the drivers need to be modified to
> use the 3D texturing engine to convert the YUV image to RGB data in the
Most TV capture cards already can do RGB capture modes in 15, 16, 24 and
32bit, as well as a 240 colour 8bit palette (which might be interesting
for textures).
Other question I have on Damage/Composite - how does it interact with
DGA ?
Alan
Date: Sat Aug 7 09:46:14 2004
In-Reply-To: <E1BtTj5-0007S7-00@mailgate.rz.uni-karlsruhe.de>
References: <E1BtTj5-0007S7-00@mailgate.rz.uni-karlsruhe.de>
On Sad, 2004-08-07 at 17:07, Amir Bukhari wrote:
> Is there a common Interface in X Server act as communication between X and
> GLX and Graphic Card, which all GLX implementations use it.
Nope.
When you are doing client side rendering ("direct render") the X server
and 3D clients share a lock and some administrative and security code in
kernel space.
The X server describes the window positions, clipping, layout and other
information the card needs in a shared memory area that the clients can
read.
The normal behaviour (backbuffer using) is that the client renders into
an offscreen pixmap owned by the client and then uses the 2D engine
directly (or via kernel space if insecure in hardware) to blit the
pixels to the front buffer rectangles that are exposed.
In certain cases programs choose to render to the front buffer and in
that situation the 3D rendering uses the lis of rectangles and draws
directly into it.
From bryce at osdl.org Sat Aug 7 09:58:38 2004
Date: Sat Aug 7 09:58:41 2004
Subject: [Xorg] Tinderbox compile status
Tinderbox looks a little messy this morning... Here's a run-down on the
problems:
do_traps.c: machine 'anholt-LC-NODRI FreeBSD' indicates there are some
errors in this file, although it's the only machine showing this error
so maybe it's a FreeBSD-only problem? Or maybe the machine is not
getting its updates correctly? not sure
do_traps.c: 'mh.OpenBSD-i386 OpenBSD 3.5' is also having a problem
compiling this but different from the above: It is reporting undefined
references to several Xft routines in DoFixedTraps and
DoFixedTrapezoids.
libfontconfig.a: "could not read symbols: Bad value". Appears to be a
library linkage issue particular to the 'mh-OpenBSD-amd64 OpenBSD 3.5'
machine.
These machines appear lost or out of commission:
alanc-SolarisX86-9-SunCC
anholt-LC FreeBSD
cfk.gt.bki810 Linux 2.6.7-bk20
cfk.mdk Linux 2.6.3-4mdk
cfk.sahara.kpx3.4 Linux 2.6.6 Clbr
cfk.w2k.v2-cygwin1.5.1 WINNT 5.0
heijs-Gentoo-2.6.8_rc1 Linux 2.6.8-rc1
Hit tinderbox.freedesktop.org for more details.
Bryce
From michel at daenzer.net Sat Aug 7 10:05:43 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Sat Aug 7 10:06:01 2004
References: <E1Bt8mS-0005RQ-Mz@evo.keithp.com>
Message-ID: <1091898343.4442.23.camel@localhost>
On Sat, 2004-08-07 at 16:32 +0100, Alan Cox wrote:
> On Gwe, 2004-08-06 at 18:45, Keith Packard wrote:
> > Around 19 o'clock on Aug 6, "Amir Bukhari" wrote:
> >
> > > Redirect OpenGL application to backing store pixmap does not work with
> > > Composite Extension (in Manual Mode) (Xserver always draw).
> >
> > Correct. Fixing GLX to draw to off-screen memory will require additional
> > work.
>
> Not a huge amount on the GL side. Generally the GL applications in
> direct mode are already drawing off screen anyway and then blitting to
> the front display. A redirected OpenGL window would mean allocating
> another back buffer somewhere (probably on the X side since only X can
> deal with the "out of memory" failure sequence) and changing GL_FRONT to
> use it if neccessary.
>
> I suspect (GL hackers correct me) that it could even be deferred to the
> point the app uses GL_FRONT.
Most DRI drivers still only support a single shared front/back/depth
buffer, which doesn't work with composite. Changing that won't be
trivial but probably not too hard either.
> Fixing X to know when and how to composite and do damage with it is the
> fun side.
The X server will have to be notified of glXSwapBuffers/glFlush/glFinish
calls and then switch between the two off-screen colour buffers for the
window and generate damage events appropriately.
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From Alan.Coopersmith at Sun.COM Sat Aug 7 10:28:18 2004
Date: Sat Aug 7 10:28:21 2004
Message-ID: <41151132.1060403@sun.com>
Bryce Harrington wrote:
> These machines appear lost or out of commission:
> alanc-SolarisX86-9-SunCC
The tinderbox processes had died for some reason, so I restarted
them.
--
Date: Sat Aug 7 10:58:43 2004
Message-ID: <E1BtVSr-00045H-00@mailgate.rz.uni-karlsruhe.de>
> On Gwe, 2004-08-06 at 18:45, Keith Packard wrote:
> > Around 19 o'clock on Aug 6, "Amir Bukhari" wrote:
> >
> > > Redirect OpenGL application to backing store pixmap does not work with
> > > Composite Extension (in Manual Mode) (Xserver always draw).
> >
> > Correct. Fixing GLX to draw to off-screen memory will require
> additional
> > work.
>
> Not a huge amount on the GL side. Generally the GL applications in
> direct mode are already drawing off screen anyway and then blitting to
> the front display. A redirected OpenGL window would mean allocating
> another back buffer somewhere (probably on the X side since only X can
> deal with the "out of memory" failure sequence) and changing GL_FRONT to
> use it if neccessary.
What confuse me is the end (2D) image (after doing all 3D rendering) must be
draw to the OpenGL Window. This surely the job of X Server DDX Layer -
correct me if I am wrong -. As you said before most GL Application use off
screen to do their Direct Rendering, that mean at the end they should use a
way to copy the image to the OpenGL Window (like CopyArea). The hacks must
be in the phase of putting the end image on the OpenGL Window.
In my case, as I redirect a Window (which supposed to be OpenGL Window), the
X Server draw always the Image on its origin position.
Date: Sat Aug 7 11:12:25 2004
In-Reply-To: <E1BtVSr-00045H-00@mailgate.rz.uni-karlsruhe.de>
References: <E1BtVSr-00045H-00@mailgate.rz.uni-karlsruhe.de>
On Sad, 2004-08-07 at 18:59, Amir Bukhari wrote:
> What confuse me is the end (2D) image (after doing all 3D rendering) must be
> draw to the OpenGL Window. This surely the job of X Server DDX Layer -
For performance reasons the OpenGL direct render layer does the 2D blit
itself while holding the X lock so that its window rectangle lists don't
change under it. What you say is correct for a server side GL
implementation.
The DRI client really doesn't care whether its drawing to the window or
offscreen. The problems is the memory allocation, the mechanism for
indicating that such behaviour should begin/end and the way in which the
server finds out if the area has been damaged. (Especially as for
most games the answer will always be "yes")
Date: Sat Aug 7 11:33:32 2004
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<1091891927.4246.14.camel@darkstar>
<1091896014.4246.39.camel@darkstar>
Message-ID: <a728f9f904080711334858456f@mail.gmail.com>
On Sat, 07 Aug 2004 17:26:54 +0100, S?rgio Monteiro Basto
> On Sat, 2004-08-07 at 17:08, Alex Deucher wrote:
> > On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
> > <albertvilella@terra.es> wrote:
> > > I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
> > >
> > > is just pulling the cvs and compiling?
> >
> > download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then
> > follow the mesa/xorg build instructions.
> >
> > build instructions:
> > http://dri.sourceforge.net/cgi-bin/moin.cgi/Building
> > xorg patch:
>
> I don't know what you mean about download Mesa cvs, xorg cvs comes with
> one Mesa and I am using it. am I doing any thing wrong ?
Sorry I didn't realize that the savage DRI had been merged into xorg
already. I see it has.
Alex
>
> I use this scripts:
>
> cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg login
> (check out )
> cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg co -P xc
> mkdir build
> cd build
> lndir ../xc
> (create_drmkl.sh)
> cd build/extras/drm/linux/
> sh ../scripts/create_linux_pci_lists.sh < ../shared/drm_pciids.txt
> (if you want linux kernel drm )
> cd ..
> scripts/create_lk_drm.sh /opt/xorgcvs/ 2.4
> (or )
> cd build/extras/drm/linux/
> make
> cp savage.o /lib/modules/ùname -r`/kernel/drivers/char/drm
>
> (update cvs)
> cvs -q -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg update -P xc
>
> and finally in /etc/X11/xorg.conf
> Section "Module"
> # ...
> Load "glx"
> Load "dri"
> # ...
> EndSection
> Section "DRI"
> Mode 0666
> EndSection
>
> regards,
> --
> S?rgio M. B.
>
>
From Nicolas.Mailhot at laPoste.net Sat Aug 7 12:24:40 2004
Date: Sat Aug 7 12:24:51 2004
<4113A149.7020006@sun.com>
Message-ID: <1091906680.2767.26.camel@m54.net81-64-155.noos.fr>
On sam, 2004-08-07 at 16:26 +0100, Alan Cox wrote:
> On Gwe, 2004-08-06 at 16:44, Nicolas Mailhot wrote:
> > us.
>
> Dafydd Harries has been attempting to get exactly this happening with
> the Olwen font (Vera + extras). The name change to keep correctly wrt
> the licensing rules on the name. Currently there are contributions for
> Welsh and I think something like Serbian (I forget which)
An "official" Vera fork endorsed by all free software Vera users would
probably help a lot (much like the ximian oo.o fork). I already knew of
3-4 Vera flavours but not this one, and I do follow some of the related
lists. It's funny how the licencing affects the life of a software
project.
Like it has already been said, freedesktop.org is the ideal place to
host such a project.
Cheers,
--
Nicolas Mailhot
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040807/8809a2be/attach
ment.pgp
Date: Sat Aug 7 12:28:46 2004
Message-ID: <E1BtWrw-0000fN-00@mailgate.rz.uni-karlsruhe.de>
> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Saturday, August 07, 2004 7:10 PM
> To: Amir Bukhari
> Cc: xorg@freedesktop.org
> Subject: RE: [Xorg] XComposite, XDamage Extension with Xvideo or GL
>
> On Sad, 2004-08-07 at 18:59, Amir Bukhari wrote:
> > What confuse me is the end (2D) image (after doing all 3D rendering)
> must be
> > draw to the OpenGL Window. This surely the job of X Server DDX Layer -
>
> For performance reasons the OpenGL direct render layer does the 2D blit
> itself while holding the X lock so that its window rectangle lists don't
> change under it. What you say is correct for a server side GL
> implementation.
>
> The DRI client really doesn't care whether its drawing to the window or
> offscreen. The problems is the memory allocation, the mechanism for
> indicating that such behaviour should begin/end and the way in which the
> server finds out if the area has been damaged. (Especially as for
> most games the answer will always be "yes").
It is simple to get Composite to Work with GLX& DRI Server implementation,
because DRI wrap some screen operation. I think it use it to Copy the front
buffer to original Window in X.
I don't know if Graphics Vendor use Server DRI Extension implementation or
their own implementation.
From bryce at osdl.org Sat Aug 7 16:22:43 2004
Date: Sat Aug 7 16:23:12 2004
On Fri, 6 Aug 2004, Jeremy C. Reed wrote:
> On Wed, 28 Jul 2004, Bryce Harrington wrote:
> > > I may have overlooked it, but where is the quick
> > > how-to-get-started-with-tinderbox guide for Xorg?
> >
> > http://www.freedesktop.org/Software/TinderboxWiki
>
> Thank you. (And thank you to Carl K.)
> Answering some of my own questions below:
>
> > The webpage says "Once you have found that your tinderbox is working, you
> > can change the tree from 'Test' to 'XMonolithic' in run-client.sh"
> >
> > How do you know the tinderbox is working? How do I know when to change
> > from "Test" to "XMonolithic"?
> >
> > I did look at the
> > http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test webpage
> > but I don't have any idea what this means.
>
> I guess I found that in the "Show Log" where it said:
>
> TINDERBOX FINISHED (SUCCESS) RUNNING 'make World' Sat, 07 Aug 2004
> 04:38:42 GMT
Yup, looks good.
> > Will it ("Test") stop? Or does it run forever?
>
> I guess it does continue to run. I see it started again.
Correct, it finishes building, then goes ahead and starts again.
There's an option you can set to make it pause between builds, but it
looks like most everyone just lets it run continuously. There's
probably enough change in the CVS tree for this to be very worthwhile.
> I have now changed to do the "XMonolithic" instead of the "Test". I am
> still curious about the following:
>
> > Also, the TinderboxWiki webpage says "Once a day ... the entire directory
> > is deleted and the files checked out fresh".
> >
> > Is there a way to skip that? I'd rather not download files again and again
> > ... Isn't "cvs up -dP" good enough?
>
> Jeremy C. Reed
It looks like you can... run tinderclient.pl to see a list of options.
I think you want --noclobber and --nousecommands.
Also take a peek in TinderClientModules/XMonolithic.pm
Bryce
Date: Sat Aug 7 16:32:34 2004
Subject: [Xorg] more and more problems
Hi every time I update xorg from cvs got more problems
since today I got:
Symbol RenderLineFixedEdgeInit from module /usr/X11R6/lib/modules/libfb.a is unr
esolved!
Symbol RenderLineFixedEdgeInit from module /usr/X11R6/lib/modules/libfb.a is unr
esolved!
Symbol RenderSampleFloorY from module /usr/X11R6/lib/modules/libfb.a is unresolv
ed!
Symbol RenderSampleCeilY from module /usr/X11R6/lib/modules/libfb.a is unresolve
d!
Symbol RenderEdgeInit from module /usr/X11R6/lib/modules/libfb.a is unresolved!
Symbol RenderEdgeInit from module /usr/X11R6/lib/modules/libfb.a is unresolved!
Symbol RenderSampleFloorY from module /usr/X11R6/lib/modules/libfb.a is unresolv
ed!
Symbol RenderSampleCeilY from module /usr/X11R6/lib/modules/libfb.a is unresolve
d!
and mouse pointer doesnt work normally, now don't clean well the area where move
s.
since last week:
After reboot computer or restart X with other configuration, startkde or
startgnome crash in login process, unless first I login with root.
This happens on Fedora Core 1 with one SIS and one Savage, so the
problem is not in the drive.
other question
is any diference pserver:anoncvs@cvs.freedesktop.org
and pserver:anoncvs@pdx.freedesktop.org ?
Regards,
--
S?rgio M. B.
From Deron.Johnson at Sun.COM Sat Aug 7 11:31:02 2004
Date: Sat Aug 7 17:42:42 2004
Subject: [Xorg] Build failure for mkfontscale.c?
Message-ID: <41151FE6.60507@Sun.COM>
While trying to compile the latest xorg cvs head, I get the following
build error. I got this when I did a fresh checkout (around 6:00
last night) and also after I did a cvs update -d this morning.
gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic
-Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
-I/usr/include/freetype2/config -I../../exports/include/X11 -I../..
-I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DFREETYPE2
-DXFREE86_FT2 -c -o mkfontscale.o mkfontscale.c
mkfontscale.c: In function `doDirectory':
mkfontscale.c:858: `BDF_PropertyRec' undeclared (first use in this function)
mkfontscale.c:858: (Each undeclared identifier is reported only once
mkfontscale.c:858: for each function it appears in.)
mkfontscale.c:858: parse error before "prop"
mkfontscale.c:859: warning: implicit declaration of function
`FT_Get_BDF_Property'
mkfontscale.c:859: `prop' undeclared (first use in this function)
mkfontscale.c:860: `BDF_PROPERTY_TYPE_ATOM' undeclared (first use in
this function)
From roland.mainz at nrubsig.org Sat Aug 7 18:42:55 2004
Date: Sat Aug 7 18:44:29 2004
Subject: [Xorg] Build failure for mkfontscale.c?
References: <41151FE6.60507@Sun.COM>
Message-ID: <4115851F.EFB8FEE7@nrubsig.org>
Deron Johnson wrote:
>
> While trying to compile the latest xorg cvs head, I get the following
> build error. I got this when I did a fresh checkout (around 6:00
> last night) and also after I did a cvs update -d this morning.
>
> gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic
> -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> -I/usr/include/freetype2/config -I../../exports/include/X11 -I../..
> -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
> -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
> -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DFREETYPE2
> -DXFREE86_FT2 -c -o mkfontscale.o mkfontscale.c
> mkfontscale.c: In function `doDirectory':
> mkfontscale.c:858: `BDF_PropertyRec' undeclared (first use in this function)
> mkfontscale.c:858: (Each undeclared identifier is reported only once
> mkfontscale.c:858: for each function it appears in.)
> mkfontscale.c:858: parse error before "prop"
> mkfontscale.c:859: warning: implicit declaration of function
> `FT_Get_BDF_Property'
> mkfontscale.c:859: `prop' undeclared (first use in this function)
> mkfontscale.c:860: `BDF_PROPERTY_TYPE_ATOM' undeclared (first use in
> this function)
Add the following line to xc/config/cf/host.def
-- snip --
#define HasFreetype2 NO
-- snip --
(Both JDS and Solaris ship with very very old versions of FreeType2
which aren't sufficient for the Xorg tree (minimum is FreeType 2.1.7,
recommended is >= 2.1.8))
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From ksoonson at gmail.com Sun Aug 8 06:58:47 2004
Date: Sun Aug 8 07:25:31 2004
Subject: [Xorg] Please include these fonts to the default xorg distribution
In-Reply-To: <6555429d0408061645329bf72d@mail.gmail.com>
<4113A149.7020006@sun.com>
Message-ID: <6555429d04080806584f432296@mail.gmail.com>
Two Korean fonts are released today.
The UnFont is lincensed under GPL and
the Baekmuk is under BSD.
Can anyone in charge of handling fonts issue please check if these
fonts can be added to default xorg distribution?
You can download them at the following URL.
http://kldp.net/projects/unfonts/
http://kldp.net/projects/baekmuk/
Thank you very much.
On Sat, 7 Aug 2004 08:45:57 +0900, Soon-Son Kwon <ksoonson@gmail.com> wrote:
> Thank you very much for the comments.
>
> But still I do not fully understand how to add a new font
> to the default xorg distribution. What is the detailed license
> requirement? Alan's opinion is what I thought initially.
>
> I think font is something like picture or novel which does not
> need to be freely modified. The font designers won't like that though
> some will. I remember that in the current xorg distribution,
> modifiable/non-modifiable fonts are mixed.
>
> Here are some free font project in Korea.
> 1. http://kldp.net/projects/unfonts/
> - almost ready to release within a week.
> - current snapshot can be downloaded from
> http://chem.skku.ac.kr/~wkpark/project/font/UnFonts/20040805/ )
>
> 2. http://kldp.net/projects/baekmuk/
> - actual fonts are in cvs tree
> - already included in many linux distributions including debian/gentoo/fedora
>
> Can anyone please check if these fonts are ready to be included?
> We are also planning to apply for government fund for commercial high quality
> fonts so that we can purchase the whole rights including free redistribution.
>
> If xorg distribution can hold more fonts for double-byte character users,
> then it would benefit many many people.
>
> Thanks very much.
>
> /Shawn
>
>
>
>
> On Fri, 06 Aug 2004 17:44:09 +0200, Nicolas Mailhot
> <nicolas.mailhot@laposte.net> wrote:
> > On ven, 2004-08-06 at 08:18 -0700, Alan Coopersmith wrote:
> > > xorg@freedesktop.org is the mailing list for xorg, and would be a much
> > > better place to discuss adding fonts to the X.Org distribution, so I've
> > > cc'ed it.
> > >
> > > I believe the license requirements are that it be some sort of open source
> > > license, but that the requirements for fonts are a bit looser than source
> > > code.
> > >
> > > TrueType fonts are the currently preferred format.
> >
> > And of course the preferred way would be to have a single set of
> > consistent truetype fonts with full unicode coverage.
> >
> > us.
> >
> > Cheers,
> >
> > --
> > Nicolas Mailhot
> >
> >
> >
>
>
> --
> http://kldp.org/~kss
>
--
From adasi-lists at culm.net Sun Aug 8 09:22:11 2004
From: adasi-lists at culm.net (Witold Krecicki)
Date: Sun Aug 8 09:48:06 2004
Subject: [Xorg] Problems running today CVS snap
Message-ID: <200408081822.11808.adasi-lists@culm.net>
At first, I get following errors in log:
Symbol RenderLineFixedEdgeInit from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderLineFixedEdgeInit from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderSampleFloorY from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderSampleCeilY from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderEdgeInit from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderEdgeInit from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderSampleFloorY from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol RenderSampleCeilY from module /usr/X11R6/lib/modules/libfb.a is
unresolved!
Symbol fbdevHWValidModeWeak from
module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved!
Symbol ATIFillInScreenInfo from
module /usr/X11R6/lib/modules/drivers/ati_drv.o is unresolved!
Symbol R128FillInScreenInfo from
module /usr/X11R6/lib/modules/drivers/ati_drv.o is unresolved!
Symbol R128OptionsWeak from module /usr/X11R6/lib/modules/drivers/ati_drv.o is
unresolved!
Then everything seems OK, but when trying to start fdoclock (with composite) I
get:
This should not happen!
An unresolved function was called!
Fatal server error:
in log. And nothing more...
Any help?
--
Witold Kr?cicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net
From krh at bitplanet.net Sun Aug 8 14:08:09 2004
Date: Sun Aug 8 14:10:18 2004
Subject: [Xorg] Keyboard driver heads up
Hi,
I just committed the patch to disable the legacy keyboard driver
("keyboard") by default. The plan is to mark this driver as deprecated
for the 6.8.0 release, and to remove it entirely in the release after
that. The new modularized driver "kbd" has the same feature set and is
available for most platforms, and should be used instead.
To enable compilation of the old driver, add
#define UseDeprecatedKeyboardDriver YES
to host.def, or even better, fill out the keyboard stubs
(hw/xfree86/os-support/<os>/os_kbd.c) for the platform in question, so
the kbd driver will work there also.
See also: #890.
Kristian
From adasi-lists at culm.net Sun Aug 8 15:15:28 2004
From: adasi-lists at culm.net (Witold Krecicki)
Date: Sun Aug 8 15:16:05 2004
In-Reply-To: <200408081822.11808.adasi-lists@culm.net>
References: <200408081822.11808.adasi-lists@culm.net>
Message-ID: <200408090015.28793.adasi-lists@culm.net>
Dnia niedziela 08 sierpie? 2004 18:22, Witold Krecicki napisa?:
> Any help?
Well, except for the ATI unresolved syms, I've helped myself (adding necesarry
function exports to hw/xfree86/loader/dixmod.c).
But, still, when running xcompmgr or metacity with compostie enabled, i've got
beautiful translucent windows with shadows under them, but..... all windows
are just gray, nothing inside, just like those weren't properly written to
offscreen buffer.
--
Witold Kr?cicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net
Date: Sun Aug 8 15:36:18 2004
In-Reply-To: Your message of "Sun, 08 Aug 2004 18:22:11 +0200."
<200408081822.11808.adasi-lists@culm.net>
Message-ID: <E1BtwGW-0003ni-2Z@evo.keithp.com>
Around 18 o'clock on Aug 8, Witold Krecicki wrote:
> At first, I get following errors in log:
> Symbol RenderLineFixedEdgeInit from module /usr/X11R6/lib/modules/libfb.a is
Oops. I forgot to export these from the Render module so that fb could
pick them up.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040808/fa1cbd14/attach
ment.pgp
Date: Sun Aug 8 17:57:49 2004
<1091672015.2600.4.camel@darkstar>
<1091749867.3320.5.camel@darkstar>
<1091891927.4246.14.camel@darkstar>
<1091896014.4246.39.camel@darkstar>
<1091920790.22729.0.camel@darkstar>
Message-ID: <a728f9f904080817572d22fc49@mail.gmail.com>
On Sun, 08 Aug 2004 02:44:31 +0200, albert vilella
> > > > cd build/extras/drm/linux/
> > > > make
> > > > cp savage.o /lib/modules/ùname -r`/kernel/drivers/char/drm
> > > >
> > >
> > > because either way I can rename the resulting "savage.o" for "savage.ko"
> > > in this directory. Is that correct?
>
> I don't get direct rendering to work.
>
> This is what I did:
>
> mkdir /home/avb/prosavage
> cd /home/avb/prosavage
> cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg login
> cvs -z3 -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg co -P xc
> mkdir /home/avb/prosavage/build
> cd /home/avb/prosavage/build
> /usr/X11R6/bin/lndir ../xc
> cd /home/avb/prosavage/build/extras/drm/linux/
> sh ../scripts/create_linux_pci_lists.sh < ../shared/drm_pciids.txt
> cd /home/avb/prosavage/build/extras/drm/linux/
> export ARCH=i386
> make
> cp savage.o /home/avb/prosavage/
> cvs -q -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg update -P xc
> # I don't know what is this "cvs update" for
>
> Then as root:
>
> cp /lib/modules/2.6.7-1.494.2.2/kernel/drivers/char/drm/savage.ko \
> /lib/modules/2.6.7-1.494.2.2/kernel/drivers/char/drm/savage.ko.ori
>
> cp /home/avb/prosavage/savage.o \
> /lib/modules/2.6.7-1.494.2.2/kernel/drivers/char/drm/savage.ko
>
> And then rebooted, but I don't get dri enabled (see glxinfo.log)
>
> I suppose I'm missing an essential (and surely ovbious point) :-D,
>
What does lsmod show? what about your xorg log? did you load the
agpgart, the agp chipset driver and the savage drm before starting X?
Alex
> Thanks in advance,
>
> Albert.
>
> --
> ----------------------------
> ----------------------------
>
>
>
From fxjrlists at yahoo.com.br Sun Aug 8 19:00:17 2004
Date: Sun Aug 8 18:56:13 2004
Subject: [Xorg] Is this xvideo message warning me about somethig which could
damage my lcd? help!
Message-ID: <4116DAB1.8020404@yahoo.com.br>
Hi all,
after setting my laptop resolution to 1400x1050, I got the following in
the xorg logs:
Mbyte/s, 0 Mbyte/s
Offscreen Pixmaps
32 128x128 slots
18 256x256 slots
(**) Option "dpms"
Is there something wrong?
Can I damage my lcd if I simply ignore this warning?
Is this only related to xvideo?
xorg starts perfectly on my lcd with this new resolution.
I was only worried about this message.
I'm attaching my full log below.
Please, let me know if you need more information.
Can I post my full xorg log so you can have a better idea?
Thanks in advance.
Regards,
From edt1023 at ms17.hinet.net Mon Aug 9 02:22:18 2004
From: edt1023 at ms17.hinet.net (Edward G.J. Lee)
Date: Mon Aug 9 02:52:12 2004
In-Reply-To: <20040808112618.K2563@ada.dhs.org>
<4113A149.7020006@sun.com>
<20040806210629.J2563@ada.dhs.org>
<20040808152358.GA4328@localhost>
<20040808112618.K2563@ada.dhs.org>
Message-ID: <20040809092218.GA10593@localhost>
On Sun, Aug 08, 2004, Ambrose Li wrote:
> On Sun, Aug 08, 2004 at 11:23:58PM +0800, Edward G.J. Lee wrote:
> >
> > FireFly had released Arphic New Sung too(Arphic PL, GPL-like),
> >
> > http://www.study-area.org/apt/firefly-font/
> >
> > AR PL New Sung = AR PL Mingti2L Big5 + AR PL SungtiL GB
>
> Ah, good to know that, since this is almost exactly what I intended
> to do. I wonder if they're going to also add more characters.
The purpose of AR PL New Sung is to embed bitmaps into TTF,
next release will embed more bitmaps. Thanks to FireFly.
But I don't think it's easy to add more characters, because
we don't have another free fonts and APL is not GPL compatible.
Edward
From edt1023 at ms17.hinet.net Mon Aug 9 04:37:36 2004
From: edt1023 at ms17.hinet.net (Edward G.J. Lee)
Date: Mon Aug 9 05:16:47 2004
In-Reply-To: <86acx4y6sb.fsf@avet.kvota.net>
<4113A149.7020006@sun.com>
<20040806210629.J2563@ada.dhs.org>
<20040808152358.GA4328@localhost>
<20040808112618.K2563@ada.dhs.org>
<20040809092218.GA10593@localhost> <86acx4y6sb.fsf@avet.kvota.net>
Message-ID: <20040809113736.GA20927@localhost>
Hello Danilo,
On Mon, Aug 09, 2004, Danilo ??egan wrote:
> Hi Edward,
>
> Today at 11:22, Edward G. J. Lee wrote:
>
> > But I don't think it's easy to add more characters, because
> > we don't have another free fonts and APL is not GPL compatible.
>
> There're many excellent free fonts. You can start with URW-CYR (35
> faces), Computer Modern Unicode (CM Unicode, another couple of dozen
> faces, all based on Knuth's magnificient Computer Modern family of
> typefaces ;), Bitstream Vera, ... There're other free fonts for
> non-Latin/Cyrillic based scripts, but I don't know much about them
> (except that they exist :).
The problem is the license, URW fonts license under GNU GPL
AFAIK. But APL is not GPL compatible. :(

Anyway, we have another MBE Arphic font project by Arne Goetje,
maybe will have more characters.

Currently it fully supports the following charsets:

ISO8859-1,2,3,4,7,9,10,13,14,15
Big5
GB2312-80
Modern Bopomofo Extensions for Hakka, Minnan

Partly support is implemented for:

HKSCS
CNS 11643
GB18030
http://debian.linux.org.tw/pub/3Anoppix/people/arne/
Edward
From alexdeucher at gmail.com Mon Aug 9 05:57:08 2004
Date: Mon Aug 9 05:57:15 2004
Subject: [Xorg] Is this xvideo message warning me about somethig which
could damage my lcd? help!
In-Reply-To: <4116DAB1.8020404@yahoo.com.br>
References: <4116DAB1.8020404@yahoo.com.br>
Message-ID: <a728f9f9040809055759696d4b@mail.gmail.com>
On Sun, 08 Aug 2004 23:00:17 -0300, Francisco Figueiredo Jr.
<fxjrlists@yahoo.com.br> wrote:
>
>
> Hi all,
>
> after setting my laptop resolution to 1400x1050, I got the following in
> the xorg logs:
>
> (II) I810(0): Mode bandwidth is 88 Mpixel/s
> (II) I810(0): maxBandwidth is 1152 Mbyte/s, pipe bandwidths are 164
> Mbyte/s, 0 Mbyte/s
> (II) I810(0): LFP compensation mode: 0x6
> (II) I810(0): Using XFree86 Acceleration Architecture (XAA)
> Screen to screen bit blits
> Solid filled rectangles
> 8x8 mono pattern filled rectangles
> Indirect CPU to Screen color expansion
> Solid Horizontal and Vertical Lines
> Offscreen Pixmaps
> Setting up tile and stipple cache:
> 32 128x128 slots
> 18 256x256 slots
> (==) I810(0): Backing store disabled
> (==) I810(0): Silken mouse enabled
> (II) I810(0): Initializing HW Cursor
> (**) Option "dpms"
> (**) I810(0): DPMS enabled
> (WW) I810(0): Disabling XVideo output because the mode pixel rate (88 MHz)
> exceeds the hardware limit (79 MHz)
>
> Is there something wrong?
> Can I damage my lcd if I simply ignore this warning?
> Is this only related to xvideo?
yes. It just means Xv is disabled because there is not enough
bandwith for the the overlay at that resolution.
Alex
>
> xorg starts perfectly on my lcd with this new resolution.
> I was only worried about this message.
>
> I'm attaching my full log below.
>
> Please, let me know if you need more information.
> Can I post my full xorg log so you can have a better idea?
>
> Thanks in advance.
>
> Regards,
>
> Francisco Figueiredo Jr.
>
Date: Mon Aug 9 07:53:50 2004
References: <Pine.LNX.4.43.0408062307260.11735-100000@pilchuck.reedmedia.net>
On Sat, 2004-08-07 at 02:12, Jeremy C. Reed wrote:
> On Wed, 28 Jul 2004, Bryce Harrington wrote:
>
> > > I may have overlooked it, but where is the quick
> > > how-to-get-started-with-tinderbox guide for Xorg?
> >
> > http://www.freedesktop.org/Software/TinderboxWiki
>
> Thank you. (And thank you to Carl K.)
>
> I have had it running the "Test" for a few hours.
>
> The webpage says "Once you have found that your tinderbox is working, you
> can change the tree from 'Test' to 'XMonolithic' in run-client.sh"
>
> How do you know the tinderbox is working? How do I know when to change
> from "Test" to "XMonolithic"?
If your builds seem to be working OK; having builds fail
due to missing dependencies that should have been installed
isn't going to help developers know at a glance if their checkins
have broken something. So basically, if you've managed
to get a green build to complete, you are set to go.
>
> I did look at the
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test webpage
> but I don't have any idea what this means.
>
> Will it ("Test") stop? Or does it run forever?
>
> Also, the TinderboxWiki webpage says "Once a day ... the entire directory
> is deleted and the files checked out fresh".
Not currently, I don't believe. I think it is just doing
a "cvs up -dP:, and a "make world"
>
> Is there a way to skip that? I'd rather not download files again and again
> ... Isn't "cvs up -dP" good enough?
>
From fxjrlists at yahoo.com.br Mon Aug 9 07:57:40 2004
From: fxjrlists at yahoo.com.br (=?iso-8859-1?q?Francisco=20Figueiredo=20Jr.?=)
Date: Mon Aug 9 08:04:33 2004
In-Reply-To: <a728f9f9040809055759696d4b@mail.gmail.com>
--- Alex Deucher <alexdeucher@gmail.com> escreveu:
> On Sun, 08 Aug 2004 23:00:17 -0300, Francisco Figueiredo Jr.
> >
> > Is there something wrong?
> > Can I damage my lcd if I simply ignore this warning?
> > Is this only related to xvideo?
>
> yes. It just means Xv is disabled because there is not enough
> bandwith for the the overlay at that resolution.
>
> Alex
>
Hi Alex, thanks for your reply.
But your "yes" is only to the question about that it is only related to xvideo
or it is also to my question about if this can damage my lcd?
Because I did some tests with mplayer and I could get it working with open gl
rendering and it was a good performance compared to xvideo in same resolution.
As in 1400 I can't use xvideo I think I could live with gl rendering.
So, I ask that because I'd like to start using 1400 resolution even with this
xvideo problem. But I also would like to know if this could damage my lcd.
Thanks in advance.
Regards,
_______________________________________________________
Yahoo! Acesso Gr?tis - navegue de gra?a com conex?o de qualidade! Acesse: http:/
/br.acesso.yahoo.com/
Date: Mon Aug 9 08:32:35 2004
Message-ID: <a728f9f9040809083235108c3e@mail.gmail.com>
On Mon, 9 Aug 2004 11:57:40 -0300 (ART), Francisco Figueiredo Jr.
> --- Alex Deucher <alexdeucher@gmail.com> escreveu:
> > On Sun, 08 Aug 2004 23:00:17 -0300, Francisco Figueiredo Jr.
>
> > >
> > > Is there something wrong?
> > > Can I damage my lcd if I simply ignore this warning?
> > > Is this only related to xvideo?
> >
> > yes. It just means Xv is disabled because there is not enough
> > bandwith for the the overlay at that resolution.
> >
> > Alex
> >
>
>
> Hi Alex, thanks for your reply.
>
> But your "yes" is only to the question about that it is only related to xvideo
> or it is also to my question about if this can damage my lcd?
>
> Because I did some tests with mplayer and I could get it working with open gl
> rendering and it was a good performance compared to xvideo in same resolution.
> As in 1400 I can't use xvideo I think I could live with gl rendering.
>
> So, I ask that because I'd like to start using 1400 resolution even with this
> xvideo problem. But I also would like to know if this could damage my lcd.
Sorry, I should have been more clear. You LCD should be ok. It's
just warning you about a bandwidth limitation that causes Xv to be
disabled.
Alex
>
>
> Regards,
>
>
>
> _______________________________________________________
> Yahoo! Acesso Gr?tis - navegue de gra?a com conex?o de qualidade! Acesse: http
://br.acesso.yahoo.com/
>
From Markus.Kuhn at cl.cam.ac.uk Mon Aug 9 09:54:42 2004
From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn)
Date: Mon Aug 9 10:16:02 2004
Subject: [Xorg] Revision of keysymdef.h
Message-ID: <E1BuDQ2-0003th-00@mta1.cl.cam.ac.uk>
Over the years, a number of problems have piled up with <X11/keysymdef.h>,
which I have set out to sort out.
These are in particular:
- Xfree86 has added since X11R6.4 was released in 1999 and 2000 a large
number of new macro definitions that are neither in line with the X11
protocols specification (Appendix A), nor have all of them been
checked charefully against the Unicode standard.
- The X11 standard lacks so far an official clarification of the
relationship between keysyms and Unicode
I have therefore reviewed, which keysyms are actually used in kbd
mapping files and have substantially reworked and cleaned up the <X11/
keysymdef.h> file. The result is available on
http://www.cl.cam.ac.uk/~mgk25/ucs/keysymdef.h
The database file that I have prepared to control the changes
made is on
http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt
and it contains further background information in the form of
comments and a status column for each keysym.
Quick summary of the changes:
- I have preserved as newly added keysyms in the range reserved
for the X11 standard only the following ones, as they are widely used
now in XFree86 keyboard mapping files:
0x06ad Ukrainian_ghe_with_upturn
0x06bd Ukrainian_GHE_WITH_UPTURN
0xfe60 dead_belowdot
0xfe61 dead_hook
0xfe62 dead_horn
These will have to be added to Appendix A of the protocols spec.
- A large number of Armenian, Gregorian, Irish, Arabic, Cyrillic,
Caucasus, and Vietnamese keysym macros were added by Pablo Saratxaga
on 1999-06-06 and 2000-10-27. With a very small number of exotic
exceptions, none of these keysyms are at present used in any
XFree86 files.
As many of them look useful, I have decided to remap them directly
into the Unicode range by adding 0x01000000 to their Unicode value.
This way, these keysyms will not have to be added to the X11 standard,
as they are implicitely defined by ISO 10646.
- I have also moved the currency symbol in the 0x20xx range
to the Unicode mapping range, with the exception of the EuroSign,
which is the only one of these that is actually used in keyboard
mapping files.
- I have added as comments to each keysym for which there exists
a direct or approximate Unicode equivalent the Unicode position
and name of this character.
- Various minor editorial fixes for better consistency, comments
added that clarify the Unicode mapping rule.
Unless someone shouts with an objection, I will submit these for inclusion
into the X.Org and XFree86 trees soon.
Proposed update to the X11 standard will follow shortly.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
From bryce at osdl.org Mon Aug 9 10:20:39 2004
Date: Mon Aug 9 10:20:54 2004
Subject: [Xorg] Xorg tinderbox status
In-Reply-To: <a728f9f9040809083235108c3e@mail.gmail.com>
Some notes regarding tinderbox as a followup to the release status call
this morning.
Tinderbox is at tinderbox.freedesktop.org.
* The Xorg release is scheduled to occur this month; the goal is to
achieve as much testing (incl. Tinderbox) as can be done during that
period.
* 6 machines are present in Tinderbox currently; this is down from the
dozen or so we had last week. It looks like we lost several over the
weekend, although don't know why. We may need a signup sheet for
Tinderbox volunteers who will be committing to providing tinderbox
service so we can contact them if the machine goes away.
* There are two problems related to do_traps.c but they appear to be
OS-specific issues. Is anyone running FreeBSD or OpenBSD that could
try to recreate and analyze the problems?
* Priorities for further enhancements to tinderbox:
+ Add link from the tinderbox page to the directions in wiki
+ Set up additional admins for it
+ Add Bonzai
+ Investigate how to get historical data from it
+ Hook up additional tests
+ Determine how to get compiled binaries for platforms
* Tests worth people running right now
+ xfw4
+ x11perf
+ rendertest.
Bryce
From reed at reedmedia.net Mon Aug 9 10:31:01 2004
Date: Mon Aug 9 10:31:11 2004
On Mon, 9 Aug 2004, Bryce Harrington wrote:
> * 6 machines are present in Tinderbox currently; this is down from the
> dozen or so we had last week. It looks like we lost several over the
> weekend, although don't know why. We may need a signup sheet for
> Tinderbox volunteers who will be committing to providing tinderbox
> service so we can contact them if the machine goes away.
I took my NetBSD down. Before I got started I didn't realize that it would
run continuously. I'd prefer to have it not refetch all code from scratch
but to do a "cvs up -dP" instead. And I don't want it rebuilding over and
over again. Oce I look at the configs/code, I will re-add my tinderbox
client build under NetBSD so it only builds once per day.
> * Tests worth people running right now
> + xfw4
What is xfw4? (A quick google search didn't find it.)
> + x11perf
> + rendertest.
Can these be automated?
Jeremy C. Reed
From alexander.gottwald at s1999.tu-chemnitz.de Mon Aug 9 10:37:03 2004
Date: Mon Aug 9 10:37:06 2004
Subject: [Xorg] Mingw build
On Thu, 5 Aug 2004, Steven Edwards wrote:
> Is anyone working on this? The only site I could find with information
> was the old Redhat site.
I've not seen any action in this field for some years now. the win32-x11
project (which is hosted on sources.redhat.com) can be considered dead
now. I'm not sure if there are other projects working on it but i doubt
there are any.
bye
ago
--
From l.lunak at suse.cz Mon Aug 9 10:27:51 2004
From: l.lunak at suse.cz (Lubos Lunak)
Date: Mon Aug 9 10:40:57 2004
Subject: [Xorg] [PATCH] Cached XIM data
Message-ID: <200408091927.51569.l.lunak@suse.cz>
Hello,
could somebody please review the attached XIM patches?
First, the rationale: QApplication constructor (app class in Qt) takes about
0.08s on my computer (850Mhz). But only in case I dump my Compose file and
all fonts. With the Compose file it's 0.31s (and with fonts it goes up to
0.47s, but that's fontconfig, so let's ignore that one). There's also about
500KiB (unshared) memory difference. Multiply this quarter a second and half
a meg e.g. by the number of apps with X connection in normal KDE session to
get even worse numbers. All this just for the ability to compose accented
characters.
The problem is basically that XIM parses the matching Compose file
from /usr/X11R6/lib/X11/locale (which happens to be the huge
en_US.UTF-8 one for UTF8 locales) and builds internal representation of this
data. The file is more or less constant, but XIM parses it once per
application startup.
The imLcIm.c patch tries to solve this problem in similar way KDE's ksycoca
stores data. After XIM parses the Compose file, the code computes how much
memory the internal representation needs, allocates such block of memory, and
copies the internal representation there, including adjusting the pointers.
This avoids malloc() overhead, and allows read-only mmap()-ing of the block
(the internal representation doesn't appear to be ever modified after it's
created). Next time it's attempted to be mmap()-ed at the proper address, and
if that succeeds, bingo, QApplication time is again at 0.08s. Still without
the fonts of course, fontconfig needs something similar.
The second patch caches a repeatedly requested information that is parsed
from another file.
There are several things I'm unsure about the patch:
- It uses things like mmap() or posix_memalign() which could cause trouble to
all those crappy Nulix platforms out there. It should be just a matter of few
#ifdef's, but I don't know how you do checks for such features.
- I'm not sure where to store the cache file. KDE has special place for cache
files, but I don't know how to do that with non-KDE apps. The patch now
stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are Linux-ism
AFAIK. Moreover this should be probably saved per-user for paranoia reasons,
or shouldn't it?
Could somebody helps me with these issues? Comments?
Thanks
PS: The patches are for libX11.
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
-------------- next part --------------
Name: lcFile.c.patch
Type: text/x-diff
Size: 1070 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040809/a4b80303/lcFile
.c.bin
-------------- next part --------------
Name: imLcIm.c.patch
Type: text/x-diff
Size: 9780 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040809/a4b80303/imLcIm
.c.bin
From kem at freedesktop.org Mon Aug 9 10:57:56 2004
Date: Mon Aug 9 10:58:06 2004
<Pine.LNX.4.43.0408091027310.11735-100000@pilchuck.reedmedia.net>
On Mon, Aug 09, 2004 at 10:31:01AM -0700, Jeremy C. Reed wrote:
> On Mon, 9 Aug 2004, Bryce Harrington wrote:
>
> > * Tests worth people running right now
> > + xfw4
>
> What is xfw4? (A quick google search didn't find it.)
VSW4 is a suite for testing the X11 protocol. One place where it can be
found is: http://www.linuxbase.org/download/index.php/test_suites
> > + x11perf
> > + rendertest.
>
> Can these be automated?
It would be great if they could be automated; however, in the mean time,
it is very helpful for people to run these tests by hand and report back
any failures.
Date: Mon Aug 9 10:59:53 2004
On Mon, 9 Aug 2004, Jeremy C. Reed wrote:
> On Mon, 9 Aug 2004, Bryce Harrington wrote:
>
> > * 6 machines are present in Tinderbox currently; this is down from the
> > dozen or so we had last week. It looks like we lost several over the
> > weekend, although don't know why. We may need a signup sheet for
> > Tinderbox volunteers who will be committing to providing tinderbox
> > service so we can contact them if the machine goes away.
>
> I took my NetBSD down. Before I got started I didn't realize that it would
> run continuously. I'd prefer to have it not refetch all code from scratch
> but to do a "cvs up -dP" instead. And I don't want it rebuilding over and
> over again. Oce I look at the configs/code, I will re-add my tinderbox
> client build under NetBSD so it only builds once per day.
*Nod* Understood. I've been poking around to find out more about
options like these. On brief look at the code it appears pretty
configurable, although the process needs to be sorted out and
documented. We may not have an ideal solution figured out for this
prior to the release, though.
> > + xfw4
>
> What is xfw4? (A quick google search didn't find it.)
I may not have the name right; Jim's mentioned this several times.
> > + x11perf
> > + rendertest.
>
> Can these be automated?
Jim indicated that he thought they could, and should. I don't know if
anyones looked into them recently though.
Thanks,
Bryce
Date: Mon Aug 9 11:24:21 2004
In-Reply-To: <200408091927.51569.l.lunak@suse.cz>
References: <200408091927.51569.l.lunak@suse.cz>
Message-ID: <4117C154.2040807@sun.com>
I don't know much about XIM, but the use of MAP_FIXED makes me uncomfortable
and the references to storing pointers in the data makes it sound like on
platforms which support multiple pointer size models (i.e. 32-bit and 64-bit
pointers), you'ld need different cache files for the different pointer
sizes, which I didn't see any provision for.
(I do remember sendmail doing something similar many years ago with frozen
config files, which got dropped a while ago as a bad idea, though I don't
remember why.)
Lubos Lunak wrote:
> Hello,
>
> could somebody please review the attached XIM patches?
>
> First, the rationale: QApplication constructor (app class in Qt) takes about
> 0.08s on my computer (850Mhz). But only in case I dump my Compose file and
> all fonts. With the Compose file it's 0.31s (and with fonts it goes up to
> 0.47s, but that's fontconfig, so let's ignore that one). There's also about
> 500KiB (unshared) memory difference. Multiply this quarter a second and half
> a meg e.g. by the number of apps with X connection in normal KDE session to
> get even worse numbers. All this just for the ability to compose accented
> characters.
>
> The problem is basically that XIM parses the matching Compose file
> from /usr/X11R6/lib/X11/locale (which happens to be the huge
> en_US.UTF-8 one for UTF8 locales) and builds internal representation of this
> data. The file is more or less constant, but XIM parses it once per
> application startup.
>
> The imLcIm.c patch tries to solve this problem in similar way KDE's ksycoca
> stores data. After XIM parses the Compose file, the code computes how much
> memory the internal representation needs, allocates such block of memory, and
> copies the internal representation there, including adjusting the pointers.
> This avoids malloc() overhead, and allows read-only mmap()-ing of the block
> (the internal representation doesn't appear to be ever modified after it's
> created). Next time it's attempted to be mmap()-ed at the proper address, and
> if that succeeds, bingo, QApplication time is again at 0.08s. Still without
> the fonts of course, fontconfig needs something similar.
>
> The second patch caches a repeatedly requested information that is parsed
> from another file.
>
> There are several things I'm unsure about the patch:
>
> - It uses things like mmap() or posix_memalign() which could cause trouble to
> all those crappy Nulix platforms out there. It should be just a matter of few
> #ifdef's, but I don't know how you do checks for such features.
>
> - I'm not sure where to store the cache file. KDE has special place for cache
> files, but I don't know how to do that with non-KDE apps. The patch now
> stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are Linux-ism
> AFAIK. Moreover this should be probably saved per-user for paranoia reasons,
> or shouldn't it?
>
> Could somebody helps me with these issues? Comments?
>
> Thanks
>
> PS: The patches are for libX11.
>
>
>
> ------------------------------------------------------------------------
>
> --- lcFile.c.sav 2004-07-01 22:29:50.000000000 +0200
> +++ lcFile.c 2004-08-08 21:46:05.000000000 +0200
> @@ -491,7 +491,13 @@ _XlcLocaleDirName(dir_name, dir_len, lc_
> static char locale_alias[] = LOCALE_ALIAS;
> char *target_name = (char*)0;
> char *target_dir = (char*)0;
> + static char* last_dir_name = 0;
> + static char* last_lc_name = 0;
>
> + if( last_lc_name != 0 && strcmp( last_lc_name, lc_name ) == 0 ) {
> + strcpy( dir_name, last_dir_name );
> + return dir_name;
> + }
> xlocaledir (dir, PATH_MAX);
> n = _XlcParsePath(dir, args, 256);
> for (i = 0; i < n; ++i) {
> @@ -550,5 +556,13 @@ _XlcLocaleDirName(dir_name, dir_len, lc_
> }
> if (target_name != lc_name)
> Xfree(target_name);
> + if( last_dir_name != 0 )
> + Xfree( last_dir_name );
> + if( last_lc_name != 0 )
> + Xfree( last_lc_name );
> + last_dir_name = Xmalloc( strlen( dir_name ) + 1 );
> + strcpy( last_dir_name, dir_name );
> + last_lc_name = Xmalloc( strlen( lc_name ) + 1 );
> + strcpy( last_lc_name, lc_name );
> return dir_name;
> }
>
>
> ------------------------------------------------------------------------
>
> --- imLcIm.c.sav 2003-09-06 16:06:32.000000000 +0200
> +++ imLcIm.c 2004-08-09 19:04:13.191772440 +0200
> @@ -34,7 +34,21 @@ THIS SOFTWARE.
> ******************************************************************/
> /* $XFree86: xc/lib/X11/imLcIm.c,v 1.11 2003/04/13 19:22:21 dawes Exp $ */
>
> +/* for posix_memalign */
> +#ifndef _XOPEN_SOURCE
> +#define _XOPEN_SOURCE 600
> +#elif _XOPEN_SOURCE < 600
> +#undef _XOPEN_SOURCE
> +#define _XOPEN_SOURCE 600
> +#endif
> +
> #include <stdio.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <unistd.h>
> +#include <sys/mman.h>
> +#include <stdlib.h>
> +
> /*
> #include <X11/Xlib.h>
> */
> @@ -73,11 +87,30 @@ _XimCheckIfLocalProcessing(im)
> return(False);
> }
>
> +struct _XimCachedDefaultTreeStruct
> + {
> + int id;
> + off_t size;
> + int count;
> + void* addr;
> + DefTree defs[ 1 ];
> + };
> +
> +Private struct _XimCachedDefaultTreeStruct* _XimCachedDefaultTree_mmap = NULL
;
> +Private FILE* _XimCachedDefaultTreeFile = NULL;
> +Private DefTree* _XimCachedDefaultTree = NULL;
> +Private int _XimCachedDefaultTreeRefcount = 0;
> +
> Private void
> XimFreeDefaultTree(
> DefTree *top)
> {
> if (!top) return;
> + if( top == _XimCachedDefaultTree ) {
> + --_XimCachedDefaultTreeRefcount;
> + /* No deleting, it's a cache after all. */
> + return;
> + }
> if (top->succession) XimFreeDefaultTree(top->succession);
> if (top->next) XimFreeDefaultTree(top->next);
> if (top->mb) Xfree(top->mb);
> @@ -208,12 +241,242 @@ _XimLocalSetIMValues(
> return(name);
> }
>
> +Private Bool
> +_XimReadCachedDefaultTree(
> + FILE** fp_cache,
> + off_t size)
> +{
> + struct _XimCachedDefaultTreeStruct* m;
> + m = mmap( NULL, size, PROT_READ, MAP_PRIVATE, fileno(*fp_cache), 0 );
> + if( m == NULL || m == MAP_FAILED )
> + return False;
> + if( m->id != 0x3746 || m->size != size || m->count < 0 ) {
> + munmap( m, size );
> + return False;
> + }
> + /* map it to the requested address (so that pointers match), fail otherwi
se */
> + if( m != m->addr ) {
> + void* use_addr = m->addr;
> + m = mmap( use_addr, size, PROT_READ, MAP_PRIVATE | MAP_FIXED, fileno(
*fp_cache), 0 );
> + if( m == NULL || m == MAP_FAILED )
> + return False;
> + if( m->id != 0x3746 || m->size != size || m->count < 0 || m != m->add
r ) {
> + return False;
> + }
> + }
> + _XimCachedDefaultTree_mmap = m;
> + _XimCachedDefaultTree = m->defs;
> + _XimCachedDefaultTreeRefcount = 0;
> + _XimCachedDefaultTreeFile = *fp_cache;
> + *fp_cache = NULL;
> + return True;
> +}
> +
> +/*#define CACHE_FILE_DIR "/var/X11R6/cache"*/
> +#define CACHE_FILE_DIR "/tmp/xim"
> +
> +Private char* _XimCachedDefaultTreeCacheFile( const char* name )
> + {
> + char* pos;
> + char* ret = Xmalloc( strlen( name ) + strlen( CACHE_FILE_DIR ) + 1 );
> + if( ret == NULL )
> + return NULL;
> + strcpy( ret, CACHE_FILE_DIR );
> + pos = ret + strlen( ret ) + 1; /* 1 = not the first slash */
> + strcat( ret, name );
> + while( *pos )
> + {
> + if( *pos == '/' )
> + *pos = '_';
> + ++pos;
> + }
> + return ret;
> + }
> +
> +
> +Private int _XimCountItems(
> +DefTree* top,
> +int* chars_len,
> +int* wchars_len)
> +{
> + int items = 0;
> + DefTree* pos1;
> + DefTree* pos2;
> +
> + if( top->mb != NULL )
> + *chars_len += strlen( top->mb ) + 1;
> + if( top->wc != NULL )
> + *wchars_len += _Xwcslen( top->wc ) + 1;
> + if( top->utf8 != NULL )
> + *chars_len += strlen( top->utf8 ) + 1;
> + for( pos1 = top;
> + pos1 != NULL;
> + pos1 = pos1->next )
> + {
> + ++items;
> + for( pos2 = pos1->succession;
> + pos2 != NULL;
> + pos2 = pos2->succession )
> + items += _XimCountItems( pos2, chars_len, wchars_len );
> + }
> + return items;
> +}
> +
> +Private DefTree*
> +_XimAddCacheItem(
> +DefTree* top,
> +struct _XimCachedDefaultTreeStruct* data,
> +int* item_pos,
> +char* chars,
> +wchar_t* wchars)
> +{
> + int my_item = (*item_pos)++;
> +
> + data->defs[ my_item ] = *top;
> + if( top->mb != NULL )
> + {
> + data->defs[ my_item ].mb = chars;
> + strcpy( chars, top->mb );
> + chars += strlen( top->mb ) + 1;
> + }
> + if( top->wc != NULL )
> + {
> + data->defs[ my_item ].wc = wchars;
> + _Xwcscpy( wchars, top->wc );
> + wchars += _Xwcslen( top->wc ) + 1;
> + }
> + if( top->utf8 != NULL )
> + {
> + data->defs[ my_item ].utf8 = chars;
> + strcpy( chars, top->utf8 );
> + chars += strlen( top->utf8 ) + 1;
> + }
> + if( top->next != NULL )
> + data->defs[ my_item ].next =
> + _XimAddCacheItem( top->next, data, item_pos, chars, wchars );
> + if( top->succession != NULL )
> + data->defs[ my_item ].succession =
> + _XimAddCacheItem( top->succession, data, item_pos, chars, wchars
);
> + return data->defs + my_item;
> +}
> +
> +
> +Private Bool
> +_XimConvertDefaultTreeToCache(
> + Xim im)
> +{
> + struct _XimCachedDefaultTreeStruct* data;
> + int chars_len = 0;
> + int wchars_len = 0;
> + char* chars;
> + wchar_t* wchars;
> + char* wchars_tmp;
> + int item_pos = 0;
> + int size;
> + int pagesize;
> + void* mem;
> +
> + int items = _XimCountItems(im->private.local.top,
> + &chars_len, &wchars_len );
> + if( items == 0 )
> + return False;
> + size = sizeof( struct _XimCachedDefaultTreeStruct )
> + + ( items - 1 ) * sizeof ( DefTree )
> + + wchars_len * sizeof( wchar_t )
> + + chars_len * sizeof( char );
> + pagesize = sysconf( _SC_PAGE_SIZE );
> + if( pagesize < 0 )
> + pagesize = 4096;
> + if( posix_memalign( &mem, pagesize, size ) != 0 )
> + return False;
> + data = _XimCachedDefaultTree_mmap = mem;
> + if( data == NULL )
> + return False;
> + data->size = size;
> + data->count = items;
> + data->id = 0x3746;
> + data->addr = (char*)data;
> + wchars_tmp = ( char* )data
> + + sizeof( struct _XimCachedDefaultTreeStruct )
> + + ( items - 1 ) * sizeof ( DefTree );
> + wchars = (wchar_t*)data;
> + while( (char*)wchars < wchars_tmp )
> + ++wchars;
> + chars = (char*)(wchars+wchars_len);
> + _XimAddCacheItem( im->private.local.top, data, &item_pos, chars, wchars )
;
> + return True;
> +}
> +
> +#if 0
> +char aaa_off[] = "
";
> +Private void print_tr(
> +DefTree* top,
> +int dif)
> +{
> + DefTree* pos1;
> + DefTree* pos2;
> +
> + fprintf( stderr, aaa_off + dif );
> + fprintf( stderr, "+ %p\n", top );
> + --dif;
> + for( pos1 = top;
> + pos1 != NULL;
> + pos1 = pos1->next )
> + {
> + fprintf( stderr, "! %p\n", pos1 );
> + for( pos2 = pos1->succession;
> + pos2 != NULL;
> + pos2 = pos2->succession )
> + {
> + fprintf( stderr, "* %p\n", pos2 );
> + print_tr(pos2,dif);
> + }
> + }
> + ++dif;
> + fprintf( stderr, "- %p\n", top );
> +}
> +#endif
> +
> +Private void
> +_XimWriteCachedDefaultTree(
> + const char* name,
> + Xim im)
> +{
> + FILE* fp_cache;
> + char* tmp_name;
> +
> +#if 0
> + print_tr(im->private.local.top,strlen(aaa_off));
> +#endif
> +
> + if( !_XimConvertDefaultTreeToCache(im))
> + return;
> + tmp_name = Xmalloc( strlen( name ) + 20 );
> + sprintf( tmp_name, "%s_%i", name, getpid());
> + fp_cache = _XFopenFile( tmp_name, "w" );
> + if( fp_cache != NULL ) {
> + fwrite( _XimCachedDefaultTree_mmap,
> + _XimCachedDefaultTree_mmap->size, 1, fp_cache );
> + if( fclose( fp_cache ) == 0 )
> + rename( tmp_name, name );
> + }
> + unlink( tmp_name );
> + XFree( tmp_name );
> +}
> +
> Private void
> _XimCreateDefaultTree(
> Xim im)
> {
> FILE *fp = NULL;
> char *name, *tmpname = NULL;
> + FILE* fp_cache;
> + char *cache_name;
>
> name = getenv("XCOMPOSEFILE");
>
> @@ -243,13 +506,49 @@ _XimCreateDefaultTree(
> if (fp == (FILE *) NULL) {
> fp = _XFopenFile (name, "r");
> }
> + if (fp == (FILE *) NULL) {
> + if (tmpname != (char *) NULL) {
> + Xfree(tmpname);
> + }
> + return;
> + }
> + /* convert name to cached filename */
> + cache_name = _XimCachedDefaultTreeCacheFile( name );
> if (tmpname != (char *) NULL) {
> Xfree(tmpname);
> }
> - if (fp == (FILE *) NULL)
> - return;
> + if( cache_name != NULL ) {
> + fp_cache = _XFopenFile( cache_name, "r" );
> + if( fp_cache != (FILE*)NULL ) {
> + struct stat st, st_cache;
> + if (fstat (fileno (fp), &st) != -1
> + && fstat( fileno( fp_cache ), &st_cache ) != -1
> + && st.st_mtime < st_cache.st_mtime
> + && st_cache.st_mtime > time( NULL ) - 60 * 60 * 24 ) {
> + if( _XimCachedDefaultTree != NULL
> + || _XimReadCachedDefaultTree(&fp_cache, st_cache.st_size)
) {
> + im->private.local.top = _XimCachedDefaultTree;
> +#if 0
> + print_tr(im->private.local.top,strlen(aaa_off));
> +#endif
> + ++_XimCachedDefaultTreeRefcount;
> + fclose(fp);
> + if( fp_cache != NULL )
> + fclose(fp_cache);
> + Xfree(cache_name);
> + return;
> + }
> + }
> + fclose(fp_cache);
> + }
> + }
> _XimParseStringFile(fp, im);
> fclose(fp);
> + if( cache_name != NULL ) {
> + if( _XimCachedDefaultTree == NULL )
> + _XimWriteCachedDefaultTree(cache_name,im);
> + Xfree( cache_name );
> + }
> }
>
> Private XIMMethodsRec Xim_im_local_methods = {
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xorg mailing list
From: fxjrlists at yahoo.com.br (=?iso-8859-1?q?Francisco=20Figueiredo=20Jr.?=)
Date: Mon Aug 9 11:27:04 2004
In-Reply-To: <a728f9f9040809083235108c3e@mail.gmail.com>
--- Alex Deucher <alexdeucher@gmail.com> escreveu:
> >
> > Hi Alex, thanks for your reply.
> >
> > But your "yes" is only to the question about that it is only related to
> xvideo
> > or it is also to my question about if this can damage my lcd?
> >
> > Because I did some tests with mplayer and I could get it working with open
> gl
> > rendering and it was a good performance compared to xvideo in same
> resolution.
> > As in 1400 I can't use xvideo I think I could live with gl rendering.
> >
> > So, I ask that because I'd like to start using 1400 resolution even with
> this
> > xvideo problem. But I also would like to know if this could damage my lcd.
>
> Sorry, I should have been more clear. You LCD should be ok. It's
> just warning you about a bandwidth limitation that causes Xv to be
> disabled.
>
> Alex
>
Thanks Alex!
I will use my lcd at 1400 resolution then.
Regards,
_______________________________________________________
Yahoo! Acesso Gr?tis - navegue de gra?a com conex?o de qualidade! Acesse: http:/
/br.acesso.yahoo.com/
Date: Mon Aug 9 12:30:49 2004
In-Reply-To: <200408091927.51569.l.lunak@suse.cz>
Thanks Lubos, for the data... You are confirming what we were
already suspecting, from a different direction (just the size
information).
>
> The problem is basically that XIM parses the matching Compose file
> from /usr/X11R6/lib/X11/locale (which happens to be the huge
> en_US.UTF-8 one for UTF8 locales) and builds internal representation of this
> data. The file is more or less constant, but XIM parses it once per
> application startup.
Yeah, I can imagine parsing half megabyte files for every
application startup isn't a good idea...
en_US.UTF-8/Compose, and pt_BR.UTF-8/Compose are over a half megabyte
each.
>
> The imLcIm.c patch tries to solve this problem in similar way KDE's ksycoca
> stores data. After XIM parses the Compose file, the code computes how much
> memory the internal representation needs, allocates such block of memory, and
> copies the internal representation there, including adjusting the pointers.
> This avoids malloc() overhead, and allows read-only mmap()-ing of the block
> (the internal representation doesn't appear to be ever modified after it's
> created). Next time it's attempted to be mmap()-ed at the proper address, and
> if that succeeds, bingo, QApplication time is again at 0.08s. Still without
> the fonts of course, fontconfig needs something similar.
>
> The second patch caches a repeatedly requested information that is parsed
> from another file.
>
> There are several things I'm unsure about the patch:
>
> - It uses things like mmap() or posix_memalign() which could cause trouble to
> all those crappy Nulix platforms out there. It should be just a matter of few
> #ifdef's, but I don't know how you do checks for such features.
On platforms without mmap support (are there any around we still care
about?), you'd just open and read the data...
>
> - I'm not sure where to store the cache file. KDE has special place for cache
> files, but I don't know how to do that with non-KDE apps. The patch now
> stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are Linux-ism
> AFAIK. Moreover this should be probably saved per-user for paranoia reasons,
> or shouldn't it?
>
Computing this once at build time seems more sensible to me.
But is there any reason why these files are so gigantic? And whether
there are other solutions? Is there someway we can leverage libc
functions that may not have existed when the Xlib implementation was
(mis)designed?
Does anyone really understand the input method stuff properly?
(we were just discussing this area today on the architecture call,
and what to do about it. Thanks for the ammunition to go after it).
Regards,
- Jim
Date: Mon Aug 9 12:40:12 2004
On Sat, 2004-08-07 at 09:58, Bryce Harrington wrote:
> Tinderbox looks a little messy this morning... Here's a run-down on the
> problems:
>
>
> do_traps.c: machine 'anholt-LC-NODRI FreeBSD' indicates there are some
> errors in this file, although it's the only machine showing this error
> so maybe it's a FreeBSD-only problem? Or maybe the machine is not
> getting its updates correctly? not sure
Looks like the build is picking up the installed render header files in
/usr/X11R6, which lack the new traps stuff, before it gets to the render
headers from the build's exports dir. This does seem to be a real
issue.
--
From aplattner at nvidia.com Mon Aug 9 12:43:07 2004
Date: Mon Aug 9 12:42:40 2004
In-Reply-To: <E1BtI6A-0007A0-MZ@evo.keithp.com>
References: <20040807030059.GA23012@homeworld.dnsalias.net>
<E1BtI6A-0007A0-MZ@evo.keithp.com>
Message-ID: <20040809194307.GB3721@dhcp-178-221.nvidia.com>
Does anyone have any objections to the attached patch? It stores the screen's
mmWidth and mmHeight in the private struct along with virtualX and virtualY, and
uses that to construct the sizes. Then, on RRSetConfig the screen's physical
size is changed. This lets me do this:
bash-2.05b$ xdpyinfo | grep -B1 dots
dimensions: 1600x1200 pixels (402x302 millimeters)
resolution: 101x101 dots per inch
bash-2.05b$ xrandr -o left
bash-2.05b$ xdpyinfo | grep -B1 dots
dimensions: 1200x1600 pixels (302x402 millimeters)
resolution: 101x101 dots per inch <----- yay!
The decision on whether or not to use randrp->virtual[XY] in xf86RandRGetInfo
still seems a little questionable, but it seems to work okay.
-- Aaron
On Fri, Aug 06, 2004 at 08:42:22PM -0700, Keith Packard wrote:
>
> Around 20 o'clock on Aug 6, Aaron Plattner wrote:
>
> > My question is, is this intentional, or a bug? Why isn't the physical
> > size simply set to pScreen->mmWidth x pScreen->mmHeight?
>
> That's a good question; I do what you suggest in the kdrive servers which
> have supported rotation for "a while" now.
>
> Could it have something to do with the virtual desktop mode?
>
> -keith
-------------- next part --------------
Index: hw/xfree86/common/xf86RandR.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86RandR.c,v
diff -u -r1.4 xf86RandR.c
--- hw/xfree86/common/xf86RandR.c 2 Aug 2004 19:35:07 -0000 1.4
+++ hw/xfree86/common/xf86RandR.c 9 Aug 2004 19:17:36 -0000
@@ -38,6 +38,8 @@
CloseScreenProcPtr CloseScreen;
int virtualX;
int virtualY;
+ int mmWidth;
+ int mmHeight;
Rotation rotation;
} XF86RandRInfoRec, *XF86RandRInfoPtr;

@@ -73,7 +75,7 @@
refresh0 = refresh;
pSize = RRRegisterSize (pScreen,
mode->HDisplay, mode->VDisplay,
- pScreen->mmWidth, pScreen->mmHeight);
+ randrp->mmWidth, randrp->mmHeight);
if (!pSize)
return FALSE;
RRRegisterRate (pScreen, pSize, refresh);
@@ -89,8 +91,8 @@
mode = scrp->modes;
pSize = RRRegisterSize (pScreen,
randrp->virtualX, randrp->virtualY,
- pScreen->mmWidth * randrp->virtualX / scrp->curr
entMode->HDisplay,
- pScreen->mmHeight * randrp->virtualY / scrp->cur
rentMode->VDisplay);
+ randrp->mmWidth,
+ randrp->mmHeight);
if (!pSize)
return FALSE;
RRRegisterRate (pScreen, pSize, refresh0);
@@ -117,12 +119,16 @@
static Bool
xf86RandRSetMode (ScreenPtr pScreen,
DisplayModePtr mode,
- Bool useVirtual)
+ Bool useVirtual,
+ int mmWidth,
+ int mmHeight)
{
ScrnInfoPtr scrp = XF86SCRNINFO(pScreen);
XF86RandRInfoPtr randrp = XF86RANDRINFO(pScreen);
int oldWidth = pScreen->width;
int oldHeight = pScreen->height;
+ int oldmmWidth = pScreen->mmWidth;
+ int oldmmHeight = pScreen->mmHeight;
WindowPtr pRoot = WindowTable[pScreen->myNum];

if (pRoot)
@@ -142,16 +148,22 @@
/* If the screen is rotated 90 or 270 degrees, swap the sizes. */
pScreen->width = scrp->virtualY;
pScreen->height = scrp->virtualX;
+ pScreen->mmWidth = mmHeight;
+ pScreen->mmHeight = mmWidth;
}
else
{
pScreen->width = scrp->virtualX;
pScreen->height = scrp->virtualY;
+ pScreen->mmWidth = mmWidth;
+ pScreen->mmHeight = mmHeight;
}
if (!xf86SwitchMode (pScreen, mode))
{
scrp->virtualX = pScreen->width = oldWidth;
scrp->virtualY = pScreen->height = oldHeight;
+ pScreen->mmWidth = oldmmWidth;
+ pScreen->mmHeight = oldmmHeight;
return FALSE;
}
/*
@@ -215,7 +227,7 @@
return FALSE;
}

- if (!xf86RandRSetMode (pScreen, mode, useVirtual))
+ if (!xf86RandRSetMode (pScreen, mode, useVirtual, pSize->mmWidth, pSize->mm
Height))
return FALSE;
/*
* Move the cursor back where it belongs; SwitchMode repositions it
@@ -307,6 +319,8 @@

randrp->virtualX = scrp->virtualX;
randrp->virtualY = scrp->virtualY;
+ randrp->mmWidth = pScreen->mmWidth;
+ randrp->mmHeight = pScreen->mmHeight;

randrp->CreateScreenResources = pScreen->CreateScreenResources;
pScreen->CreateScreenResources = xf86RandRCreateScreenResources;
Date: Mon Aug 9 12:59:33 2004
<4117C154.2040807@sun.com>
Message-ID: <E1BuGId-0004Mz-VU@evo.keithp.com>
Around 11 o'clock on Aug 9, Alan Coopersmith wrote:
> (I do remember sendmail doing something similar many years ago with frozen
> config files, which got dropped a while ago as a bad idea, though I don't
> remember why.)
Not so much because it became a bad idea, more because the time required
to parse the config file was eventually small enough that it became
practical to just parse the file on each invocation.
In the fontconfig case, the problem is that *every* application loads the
configuration, wasting time and memory. A shared (mmap'able)
configuration would eliminate both of these concerns.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040809/15f6220f/attach
ment.pgp
Date: Mon Aug 9 13:05:05 2004
<20040809194307.GB3721@dhcp-178-221.nvidia.com>
Message-ID: <E1BuGO7-0004Nh-VO@evo.keithp.com>
> Does anyone have any objections to the attached patch? It stores the screen's
> mmWidth and mmHeight in the private struct along with virtualX and virtualY, a
nd
> uses that to construct the sizes.
Seems fine. kdrive does something similar...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040809/8b7fe68b/attach
ment.pgp
From Alexander.Gottwald at s1999.tu-chemnitz.de Mon Aug 9 13:49:15 2004
From: Alexander.Gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Aug 9 13:49:47 2004
In-Reply-To: <200408091600.KAA04533@anderson.fc.hp.com>
References: <200408091600.KAA04533@anderson.fc.hp.com>
Message-ID: <Pine.LNX.4.55.0408092245130.21789@lupus.ago.vpn>
> Bug #306 - Egbert checked in the patch, and Jim will be writing
> up documentation on it. Kevin is going to go ahead an close
> this, since there is another bug already open on the documentation.
Cygwin has no user root by default and file ownership and modes are in some
cases (eg on FAT filesystems) not working.
I'll revert the failing to a simple warning as it was before.
Any objections?
bye
ago
--
Alexander.Gottwald@informatik.tu-chemnitz.de
Date: Mon Aug 9 14:19:49 2004
In-Reply-To: <38ac01c47e54$942594a0$1e01a8c0@cnt496>
On Mon, 9 Aug 2004, Carl Karsten wrote:
> > *Nod* Understood. I've been poking around to find out more about
> > options like these. On brief look at the code it appears pretty
> > configurable, although the process needs to be sorted out and
> > documented. We may not have an ideal solution figured out for this
> > prior to the release, though.
>
> Good. I would hope that some significant improvements can be made with some
> minor changes:
>
> 1. cvs up -dP
Jim indicates that this is already how it works... I haven't explored
the code that does this, though.
> 2. if a build fails, log it and do make clean
I would actually suggest that you install ccache; this way you can let
it do make clean each time, but only files which actually change will
have to get recompiled. That'll give you better performance, plus avoid
false positives (rare, but do happen).
> 3. Some sort of scheduler - either the script only runs once and we hook it to
a
> cron job, or a config option to specify how often it should check for updates.
> The later would do better if a build runs long (like if it is set to check for
> updates every 4 hours, don't check if a build is taking 4.5 hours - when the
> build is done, it can check and start over.)
You can essentially do this now. run-client.sh is a short (8 line) bash
script that wrappers the tinderclient code. You'll notice a --throttle
setting there, that appears to control how long it should wait after
doing a build; you could set this to 4 hrs if you want to reduce how
often it's run. I only played with it briefly, but it seemed to work as
advertised.
The trouble with using cron-jobs for this sort of testing is the risk of
getting into race conditions, so it's safer on your system to do it in a
while() loop with a throttle delay.
Note that tinderclient.pl has a few more options for controlling its
behavior on your system. Run ./tinderclient.pl --help to get a list of
them. I don't have experience with any of them other than --throttle,
so YMMV, but that seems to be an effective way to customize it to suit
how you want to use it.
Bryce
From spyderous at gentoo.org Mon Aug 9 20:48:07 2004
From: spyderous at gentoo.org (Donnie Berkholz)
Date: Mon Aug 9 20:48:11 2004
Subject: [Xorg] [PATCH] xorgconfig ignores FontDir
Message-ID: <20040810.8OS.81243100@groupware.gentoo.org>
xorgconfig produces an xorg.conf with the default font paths
(/usr/X11R6/lib/X11/fonts/${fonttype}) even when fonts are installed elsewhere
(e.g., /usr/share/fonts) by defining FontDir at compile time.
The attached patch fixes this by creating a TREEROOTFONT that can be outside
of the usual tree if FontDir is defined. In the default case where FontDir is
not manually set, the patch defaults to previous behavior. This is a parallel
to what has already been done with TREEROOTDOC.
If there are no problems with this patch, I'd like to get it into this
release. The associated bug is #826.
Thanks,
Donnie
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: xorgconfig-fontdir-fixes.patch
Size: 2367 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040809/1f49972d/xorgco
nfig-fontdir-fixes-0001.obj
Date: Mon Aug 9 21:04:06 2004
In-Reply-To: <200408090015.28793.adasi-lists@culm.net>
References: <200408081822.11808.adasi-lists@culm.net>
<200408090015.28793.adasi-lists@culm.net>
Hash: SHA1
On Sunday 08 August 2004 18:15, Witold Krecicki wrote:
> Dnia niedziela 08 sierpie? 2004 18:22, Witold Krecicki napisa?:
> > Any help?
>
> Well, except for the ATI unresolved syms, I've helped myself (adding
> necesarry function exports to hw/xfree86/loader/dixmod.c).
> But, still, when running xcompmgr or metacity with compostie enabled, i've
> got beautiful translucent windows with shadows under them, but..... all
> windows are just gray, nothing inside, just like those weren't properly
> written to offscreen buffer.
The ATI symbol warnings are bug 978, and fixed in CVS as of about 5 minutes
ago. They're harmless warnings though.
- - ajax
iD8DBQFBGEkUW4otUKDs0NMRAtkJAKDnYDDigfLZGnfc2TlkqP4g6q8IsgCglUJd
n1fq+J8SLl5s4efKeV8DAYY=
=I79E
Date: Mon Aug 9 22:09:28 2004
Subject: [Xorg] Current blocker bug list
In order to get wider exposure to the current list of blocker bugs, I
have put together a list of them along with a comment on each (below).
I will keep this list updated and will post it and the bug stats each
night.
We would like to ask your help with the following:
1. Please help us track down solutions for the current blocker bugs
listed below.
2. If there are other bugs that should be considered blockers, please
add them to bugzilla so that we can track them.
FYI, the main blocker bug is #351:
Current blocker bugs: 13
Fixed yesterday: 14
Added yesterday: 4
Current list of blocker bugs:
-----------------------------
* Bug #255: Radeon driver - AGP/PCI autodetection is totally broken
- Need to verify changes from revision 1.1.4.1.6.3 are correct
* Bug #306: PPC64 changes
- Need someone to test PPC64 changes
* Bug #337: Remove trademarked Gumby images
- Keith Packard said he would do this; however, he doesn't need to be
distracted from other tasks (e.g., getting Composite working)
* Bug #738: Bogus contact addresses in Xserver/os/utils.c
- Need someone to create a patch to allow these addresses to be
configurable
- What are the correct default addresses to use here?
* Bug #855: xterm displays DEL but it should instead ignore it
- Has anyone contacted Thomas E. Dickey to see if it is okay to update
X.Org xterm to his version?
* Bug #922: Radeon Render acceleration problems
- Recent patches fix several problems, but there is still what is
thought to be a context switching problem
- Need someone to investigate problem
* Bug #925: Freetype 2.1.8+ symbols break build on many systems
- Several patches have already been applied to fix this problem
- Are there any other patches needed or can we close this bug and move
it over to the release notes bug (#999)?
* Bug #964: X.Org Xprt starts to consume 100% when being idle
- Roland Mainz has been looking into this and he would like to have
some help tracking this problem down
* Bug #972: Xprint installs outside of ProjectRoot when
NothingOutsideProjectRoot is YES
- Three solutions proposed:
1. When NothingOutsideProjectRoot is YES, install the scripts under
ProjectRoot/etc. To make it clear to the sysadmin, a note could
be added that the scripts installed there should be included in
the system's rc.d init scripts.
2. Don't install any init scripts when NothingOutsideProjectRoot is
YES.
3. Create a new program that allows users to start Xprint on their
own.
- Solutions #1 and #2 are straighforward
- Since we are late in the release process, I would suggest that we go
with solution #1
* Bug #991: Composite exposes extra visuals
- Keith Packard is working on a solution
* Bug #993: Build failure with #define BuildXevie NO
- This problem has been fixed, but it raised another issues that has
been discussed on the mailing list before: Should Xevie be included
in Xext or should it be in a separate library by itself?
* Bug #999: Release notes for next release
- Need someone to start documenting changes for release notes
* Bug #1004: XDarwin manpage included on Linux builds
- Expected behavior for quite some time
- Documentation changes are still allowed
- Need someone to feel strongly enough that this should be fixed and
generate a patch to change the expected behavior
Date: Mon Aug 9 22:24:05 2004
Subject: [Xorg] Any patches for X.Org release?
On today's release wranglers call, someone asked if there were any new
fixes from the DRI or Mesa projects that should be included in the next
X.Org release. If there are any, could you please let us know? Thanks!
Date: Mon Aug 9 22:25:50 2004
References: <20040810050923.GA19479@kem.org>
Hash: SHA1
> * Bug #855: xterm displays DEL but it should instead ignore it
> - Has anyone contacted Thomas E. Dickey to see if it is okay to update
> X.Org xterm to his version?
I talked to him briefly about xterm in relation to bug 379, which he had
already fixed. I really can't justify _not_ following Dickey's sources,
since he's doing an excellent job maintaining it and there aren't any license
issues (unless I'm grossly misinformed).
> * Bug #972: Xprint installs outside of ProjectRoot when
> NothingOutsideProjectRoot is YES
> - Three solutions proposed:
> 1. When NothingOutsideProjectRoot is YES, install the scripts under
> ProjectRoot/etc. To make it clear to the sysadmin, a note could
> be added that the scripts installed there should be included in
> the system's rc.d init scripts.
> 2. Don't install any init scripts when NothingOutsideProjectRoot is
> YES.
> 3. Create a new program that allows users to start Xprint on their
> own.
> - Solutions #1 and #2 are straighforward
> - Since we are late in the release process, I would suggest that we go
> with solution #1
Seconded.
- - ajax
iD8DBQFBGFxKW4otUKDs0NMRAgFOAKCMUh5eRLRLlA7gnFdH+tikNM/bmACcC4FR
k0xz/A/wUx89kGdr/lx5N0c=
=QGZ8
From mcnichol at austin.ibm.com Mon Aug 9 14:56:31 2004
From: mcnichol at austin.ibm.com (mcnichol@austin.ibm.com)
Date: Mon Aug 9 23:20:33 2004
Message-ID: <200408092156.QAA24718@xanth.austin.ibm.com>
> From: Jim Gettys <Jim.Gettys@hp.com>
>
> Computing this once at build time seems more sensible to me.
>
> But is there any reason why these files are so gigantic? And whether
> there are other solutions? Is there someway we can leverage libc
> functions that may not have existed when the Xlib implementation was
> (mis)designed?
>
> Does anyone really understand the input method stuff properly?
I mostly understand how this works on AIX anyway.
There is a seperate input method library (libIM.a). When initialized
it loads a shared object (based on the locale and the binary mode (32bit
or 64bit)) that contains the actual input method code and data.
This solves the problems with startup time and memory usage, with the
drawback that it makes it difficult for Joe User to customize things.
Dan
From l.lunak at suse.cz Tue Aug 10 01:14:34 2004
From: l.lunak at suse.cz (Lubos Lunak)
Date: Tue Aug 10 01:10:46 2004
Message-ID: <200408101014.34881.l.lunak@suse.cz>
On Monday 09 of August 2004 21:30, Jim Gettys wrote:
> Thanks Lubos, for the data... You are confirming what we were
> already suspecting, from a different direction (just the size
> information).
>
> > There are several things I'm unsure about the patch:
> >
> > - It uses things like mmap() or posix_memalign() which could cause
> > trouble to all those crappy Nulix platforms out there. It should be just
> > a matter of few #ifdef's, but I don't know how you do checks for such
> > features.
>
> On platforms without mmap support (are there any around we still care
> about?), you'd just open and read the data...
Of course. What I meant was that I didn't know how to write configure checks
equivalents for the make World stuff X currently uses.
> > - I'm not sure where to store the cache file. KDE has special place for
> > cache files, but I don't know how to do that with non-KDE apps. The patch
> > now stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are
> > Linux-ism AFAIK. Moreover this should be probably saved per-user for
> > paranoia reasons, or shouldn't it?
>
> Computing this once at build time seems more sensible to me.
Hmm ... yes, probably. It just started as a proof of concept hack when I was
examining the problem and possible solutions. I wanted to spare me diving
into XIM and finding out how much of it would need rewritting, and since this
patch doesn't change the internal representation format, other parts of XIM
didn't need to be touched. Somehow it ended up as a normal usable solution.
I'm afraid I don't plan becoming XIM hacker in order to offer a better patch.
>
> But is there any reason why these files are so gigantic?
I guess the utf8 Compose file simply includes all possible compositions, be
it Slavic language or Japanese. E.g. the iso8859-2 file is only 5% of the
utf8 size, and it would do for me too. Moreover there are e.g. 5 ways to
enter aacute, the normal one with dead acute+a, plus 4 more using the multi
key (which I even don't know what is).
> And whether
> there are other solutions? Is there someway we can leverage libc
> functions that may not have existed when the Xlib implementation was
> (mis)designed?
>
> Does anyone really understand the input method stuff properly?
>
> (we were just discussing this area today on the architecture call,
> and what to do about it. Thanks for the ammunition to go after it).
> Regards,
> - Jim
How about the second smaller patch? Is that one ok (so that it doesn't get
lost in the discussion)?
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
Date: Tue Aug 10 05:07:23 2004
Subject: [Xorg] xlibs frozen, soversion audit needed, release upcoming
Message-ID: <1092137763.5842.40.camel@catsby.fooishbar.org>
Hi,
Sorry about the hurry here, and the fact I'm being a little arbitrary.
The hurry is caused by the fact we have a platform release to hit soon,
and I think I was trying to do this release like six months ago or
something.
I've got a lot of changes to merge today to a lot of modules, which
makes it possible to bootstrap without ever having had the monolithic
tree installed. I'm doing these changes now, and I've locked down the
tree while I'm doing this, since I'm already trying to merge between
three trees, and I need to touch almost every module. Sorry.
The soversions.
My god, the soversions.
They're almost totally random. I'm guilty of screwing them up badly
myself; I'm still not entirely convinced I understand them *properly*.
But there are good explanations around[0], and I'm going to corner
someone who knows today (he's sitting a couple of feet away, but we're
in a talk, and he's actively participating).
We need a sane strategy for bumping the soversions when need be (which
is *not* 'keep it in sync with the version), and we need to change the
soversions for the previously-static-but-now-shared libraries (libXss,
libXxf86*, et al; some of which I am just importing today) which
currently have soversions of 0.0.0, 0.1.0, or something totally wack.
Anyway. I'll put a list up on the Wiki later today, with best
suggestions, and then I want to start tagging and rolling tarballs --
two days from now (UK time). So, I want every single tarball for xlibs
1.0.1 ready by Thursday Aug 12th 2359 UTC. I'll be doing almost all of
them, but help would be appreciated -- especially building on systems
that are not Linux/(i386|powerpc).
So, executive summary:
* we need a strategy for fixing soversions
* tarballs in pdx:~xlibs/public_html/release/1.0.1 by 08122359 +0000,
must have proper soversions.
GO!
:) d
[0]: http://sources.redhat.com/autobook/autobook/autobook_91.html#SEC91
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040810/1d662467/attach
ment.pgp
Date: Tue Aug 10 05:59:36 2004
On Maw, 2004-08-10 at 06:23, Kevin E Martin wrote:
> On today's release wranglers call, someone asked if there were any new
> fixes from the DRI or Mesa projects that should be included in the next
> X.Org release. If there are any, could you please let us know? Thanks!
Can the VIA DRI stuff get pushed through to the kernel with the S3
stuff please, even if we mark VIA as experimental
From tartan at mindspring.com Tue Aug 10 16:33:16 2004
From: tartan at mindspring.com (Joshua M. McClain)
Date: Tue Aug 10 16:44:07 2004
Subject: [Xorg] xv issue -
Message-ID: <1092180794.8372.133.camel@greddy.185performance.com>
Has any progress been made on the bug discussed here?
http://freedesktop.org/pipermail/xorg/2004-July/001282.html
Capture: Hauppauge PVR-250
Display: Voodoo3 3000 AGP 16MB
I'm running MythTV 0.15.1, and when I leave xv enabled and play live
television, I get resource allocation errors dumped to the console.
Even if I kick the encoding and playback down to 160x160, the same
errors arrive.
However, from within Myth:
* mplayer (using -vo xv) plays dvd's just fine
* mplayer (using -vo xv) plays pre-recorded videos fine (dumped from
"cat /dev/video0 > test.mpg")
People report that this was not an issue in XFree, and I'd rather not
throw in my heavy duty 3D card simply because it has 128MB video ram.
Thanks for the help.
Josh
From andrew at digital-domain.net Tue Aug 10 16:57:42 2004
Date: Tue Aug 10 16:57:48 2004
In-Reply-To: <1092180794.8372.133.camel@greddy.185performance.com>
References: <1092180794.8372.133.camel@greddy.185performance.com>
On Wed, 2004-08-11 at 00:33, Joshua M. McClain wrote:
> Has any progress been made on the bug discussed here?
>
[snip]
> People report that this was not an issue in XFree, and I'd rather not
> throw in my heavy duty 3D card simply because it has 128MB video ram.
>
I have seen several posts to the XFree86 list detailing the same problem
post XFree86 4.3, something happened with Xv between XFree86 4,3 and 4.4
and IIRC this is the time frame that xorg was forked.
> Thanks for the help.
>
> Josh
Andrew
From kem at freedesktop.org Tue Aug 10 17:20:23 2004
Date: Tue Aug 10 17:20:27 2004
Subject: [Xorg] Release name and snapshot testing
This morning the X.Org BOD approved the X11R6.8 name for the upcoming
release.
The CVS tree has been tagged with the XORG-6_7_99_1 snapshot tag. These
snapshot tags (XORG-6_7_99_n where n is the snapshot number) are
intended for people testing the release and for people packaging the
release. We expect that there will be several snapshot tags as bugs are
fixed before the code freeze (scheduled for Friday).
At this time, we ask everyone begin fully testing the release. The
sooner that we can get people testing, the sooner that we can find and
fix the remaining bugs and get the release out.
Detailed test instructions have been added to the release status wiki
page:
http://wiki.freedesktop.org/XOrg/XorgReleaseStatus
After testing, please send your test reports here to the xorg@fdo list,
and I will update the release status matrix.
Thanks!
From roland.mainz at nrubsig.org Tue Aug 10 17:30:21 2004
Date: Tue Aug 10 17:30:36 2004
Subject: [Xorg] shared vs static libraries
References: <410BBE62.3060700@laas.fr>
Message-ID: <4119689D.6E3C0F93@nrubsig.org>
> It looks like some of the new libraries are built static only. In the
> past (in XFree86) this has been often seen as a problem by 3rd party
> developpers who want to build application in terms of loadable (with
> dlopen) modules and need functions in these libraries. This is among
> others the case of KDE.
>
> This would affect libdmx, libXprintAppUtil, libXprintutil.
Both XprintUtil and XprintAppUtil are not stable yet (and at least
XprintUtil needs a rewrite, parts of the code would win various awards
for ugly code... =:-), there are still some API changes required before
the stuff can be shipped as shared library.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From tartan at mindspring.com Tue Aug 10 17:48:35 2004
From: tartan at mindspring.com (Joshua M. McClain)
Date: Tue Aug 10 17:52:56 2004
Message-ID: <1092185314.8372.148.camel@greddy.185performance.com>
> I have seen several posts to the XFree86 list detailing the same problem
> post XFree86 4.3, something happened with Xv between XFree86 4,3 and 4.4
> and IIRC this is the time frame that xorg was forked.
Here's another test case -- and this is odd. When I record a tv show in
myth (using 480x480, in fact), then play it back in myth, I get two
results:
* when played back from MythTV's "play recordings" feature, I get the
same old bug
* when played back from MythVideo, it works. (mplayer -vo xv)
Soooo, I'm gonna take this to the myth crowd also. Probably, it's a
combination of the two.
josh
Date: Tue Aug 10 18:00:46 2004
In-Reply-To: <4119689D.6E3C0F93@nrubsig.org>
References: <410BBE62.3060700@laas.fr> <4119689D.6E3C0F93@nrubsig.org>
On Wed, 2004-08-11 at 01:30, Roland Mainz wrote:
> Both XprintUtil and XprintAppUtil are not stable yet (and at least
> XprintUtil needs a rewrite, parts of the code would win various awards
> for ugly code... =:-), there are still some API changes required before
> the stuff can be shipped as shared library.
Changing API is no excuse for not having a shared library; you change
the API and bump the soname, it's as simple as that. If you change the
API in a static library, people still need to change their code anyway.
Change, bump.
If you need any help with soversions, feel free to contact me.
:) d
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040811/84576425/attach
ment.pgp
From fxjrlists at yahoo.com.br Tue Aug 10 20:19:14 2004
Date: Tue Aug 10 20:14:55 2004
Subject: [Xorg] Change log for i810 driver in new release?
Message-ID: <41199032.1020808@yahoo.com.br>
Hi all,
I'm seeing from the threads that a new release of xorg is comming.
I have an i810 based video card and I would like to know where I can
find info about improvements and changes in the driver.
Is there some?
Also, is the i810 driver different from intel's?
I think the code may be, but is there some feature diffs?
Can I install intel drivers in fc2?
Thanks in advance.
Regards,
Date: Tue Aug 10 21:42:47 2004
night.
listed below.
Fixed yesterday: 1
Added yesterday: 5
-----------------------------
* Bug #255: Radeon driver - AGP/PCI autodetection is totally broken
- Need to verify changes from revision 1.1.4.1.6.3 are correct
* Bug #303: PPC64 changes
- Need someone to test PPC64 changes
- Keith Packard said he would do this; however, he doesn't need to be
distracted from other tasks (e.g., getting Composite working)
* Bug #738: Bogus contact addresses in Xserver/os/utils.c
- Need someone to create a patch to allow these addresses to be
configurable
- What are the correct default addresses to use here?
- Has anyone contacted Thomas E. Dickey to see if it is okay to update
X.Org xterm to his version?
- Recent patches fix several problems, but there is still what is
thought to be a context switching problem
- Need someone to investigate problem
* Bug #925: Freetype 2.1.8+ symbols break build on many systems
- Several patches have already been applied to fix this problem
- Are there any other patches needed or can we close this bug and move
it over to the release notes bug (#999)?
- Roland Mainz has a proposed solution but needs some review of the
patch
* Bug #972: Xprint installs outside of ProjectRoot when
NothingOutsideProjectRoot is YES
- Three solutions proposed:
1. When NothingOutsideProjectRoot is YES, install the scripts under
ProjectRoot/etc. To make it clear to the sysadmin, a note could
be added that the scripts installed there should be included in
the system's rc.d init scripts.
2. Don't install any init scripts when NothingOutsideProjectRoot is
YES.
3. Create a new program that allows users to start Xprint on their
own.
- Solutions #1 and #2 are straighforward
- Since we are late in the release process, I would suggest that we go
with solution #1
* Bug #1004: XDarwin manpage included on Linux builds
- Expected behavior for quite some time
- Documentation changes are still allowed
- Need someone to feel strongly enough that this should be fixed and
generate a patch to change the expected behavior
* Bug 1024: Japanese ctext conversion bug
- Patch available, just needs review
* Bug 1026: Xnest is missing XKB on BuildServersOnly
- Presumably this will also be a problem with DMX
- Fix proposed
* Bug 1029: Hard failure if socket directories cannot be chowned to root
- This solution breaks on systems that do not have setuid
- xfs uses xtrans also and since it is not setuid root, it cannot
chown to root and bails
- Perhaps solution proposed is too draconian and should be backed out
* Bug 1032: Damage causes rootless XDarwin to crash
- Several backtraces suggest this is caused by damage
- Keith suggests that perhaps DamageSetup hasn't been called
- Needs further investigation
Date: Tue Aug 10 22:27:28 2004
<1092186015.7140.19.camel@catsby.fooishbar.org>
Message-ID: <411999A5.6EF18405@nrubsig.org>
Daniel Stone wrote:
>
> On Wed, 2004-08-11 at 01:30, Roland Mainz wrote:
> > Both XprintUtil and XprintAppUtil are not stable yet (and at least
> > XprintUtil needs a rewrite, parts of the code would win various awards
> > for ugly code... =:-), there are still some API changes required before
> > the stuff can be shipped as shared library.
>
> Changing API is no excuse for not having a shared library; you change
> the API and bump the soname, it's as simple as that. If you change the
> API in a static library, people still need to change their code anyway.
>
> Change, bump.
No, that's not possible. We would have to gurantee backwards
compatibility to the old version (at least the commercial Unices may
require that), either via lots of #ifdef in the code or via storing the
old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
example of this nightmare.
Right now both APIs are NOT stable and should NOT be shipped as shared
libraries for X11R6.8.0. Otherwise the pain will be much bigger than the
benefit.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From andrew at digital-domain.net Wed Aug 11 00:28:53 2004
Date: Wed Aug 11 00:28:58 2004
In-Reply-To: <1092185314.8372.148.camel@greddy.185performance.com>
<1092185314.8372.148.camel@greddy.185performance.com>
On Wed, 2004-08-11 at 01:48, Joshua M. McClain wrote:
[snip]
> Soooo, I'm gonna take this to the myth crowd also. Probably, it's a
> combination of the two.
>
If it's the same bug as this one:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123996
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=474
Then it is quite variable.... also you could add your information to the
freedesktop.org bugzilla entry.
> josh
>
Cheers,
Andrew
From Alan.Coopersmith at Sun.COM Wed Aug 11 00:42:37 2004
Date: Wed Aug 11 00:42:36 2004
In-Reply-To: <411999A5.6EF18405@nrubsig.org>
<411999A5.6EF18405@nrubsig.org>
Message-ID: <4119CDED.2000107@sun.com>
Roland Mainz wrote:
> No, that's not possible. We would have to gurantee backwards
> compatibility to the old version (at least the commercial Unices may
> require that), either via lots of #ifdef in the code or via storing the
> old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
> example of this nightmare.
This commercial Unix vendor no longer ships any static libraries. If it's
not stable enough yet, we just won't ship it, shared or static.
--
From Alan.Coopersmith at Sun.COM Wed Aug 11 00:50:23 2004
Date: Wed Aug 11 00:50:21 2004
Subject: [Xorg] ATI driver fails to build on non-DRI platforms
Message-ID: <4119CFBF.2060305@sun.com>
I haven't had a chance to look into what change broke it, but
after pulling over from Xorg head today, the ATI drivers no longer
build on Solaris x86 (which doesn't use DRI).
Specifically, the failures are:
"radeon_render.c", line 438: undefined struct/union member: CPStarted
"radeon_render.c", line 746: undefined struct/union member: CPStarted
The problem is simply that radeon.h defines CPStarted inside an
#ifdef XF86DRI block, but radeon_render.c uses them without wrapping
inside ifdef's.
Can someone who knows this code please fix?
Thanks,
-alan-
--
From eta at lclark.edu Wed Aug 11 00:57:00 2004
Date: Wed Aug 11 00:57:06 2004
In-Reply-To: <4119CFBF.2060305@sun.com>
References: <4119CFBF.2060305@sun.com>
On Wed, 2004-08-11 at 00:50, Alan Coopersmith wrote:
> I haven't had a chance to look into what change broke it, but
> after pulling over from Xorg head today, the ATI drivers no longer
> build on Solaris x86 (which doesn't use DRI).
>
> Specifically, the failures are:
> "radeon_render.c", line 438: undefined struct/union member: CPStarted
>
> The problem is simply that radeon.h defines CPStarted inside an
> #ifdef XF86DRI block, but radeon_render.c uses them without wrapping
> inside ifdef's.
>
> Can someone who knows this code please fix?
>
> Thanks,
Yeah, I'll take a look at it RSN. I'm trying to get the do_traps.c
issue fixed first.
--
Date: Wed Aug 11 00:58:00 2004
In-Reply-To: <411999A5.6EF18405@nrubsig.org>
<411999A5.6EF18405@nrubsig.org>
> Daniel Stone wrote:
> > Changing API is no excuse for not having a shared library; you change
> > the API and bump the soname, it's as simple as that. If you change the
> > API in a static library, people still need to change their code anyway.
> >
> > Change, bump.
>
> No, that's not possible. We would have to gurantee backwards
> compatibility to the old version (at least the commercial Unices may
> require that), either via lots of #ifdef in the code or via storing the
> old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
> example of this nightmare.
> Right now both APIs are NOT stable and should NOT be shipped as shared
> libraries for X11R6.8.0. Otherwise the pain will be much bigger than the
> benefit.
If you need to change the code when it's a static lib, then you need to
change the code when it's a shared library. It's actually quite easy to
retain library backwards compatibility with dynamic libraries.
Static libraries are not the solution. It fixes a symptom of your
problem, rather than the problem itself.
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040811/ce51e887/attach
ment.pgp
Date: Wed Aug 11 01:38:43 2004
In-Reply-To: <4119CFBF.2060305@sun.com>
References: <4119CFBF.2060305@sun.com>
> I haven't had a chance to look into what change broke it, but
> after pulling over from Xorg head today, the ATI drivers no longer
> build on Solaris x86 (which doesn't use DRI).
>
> Specifically, the failures are:
>
> The problem is simply that radeon.h defines CPStarted inside an
> #ifdef XF86DRI block, but radeon_render.c uses them without wrapping
> inside ifdef's.
>
> Can someone who knows this code please fix?
http://freedesktop.org/bugzilla/show_bug.cgi?id=922
See the current patch for a build fix. I'll test this out and commit
tomorrow I hope.
--
From alan at lxorguk.ukuu.org.uk Wed Aug 11 03:21:26 2004
Date: Wed Aug 11 04:23:49 2004
In-Reply-To: <Pine.LNX.4.58.0408110128210.3763@skynet>
<Pine.LNX.4.58.0408110128210.3763@skynet>
On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
> >
> > Can the VIA DRI stuff get pushed through to the kernel with the S3
> > stuff please, even if we mark VIA as experimental
>
> the DRM stuff? We need to mark as insecure, I really don't want anything
> that the authors consider insecure to go anywhere outside the DRM...
Who considers it insecure and where is it documented then I'll go and
have a look at the issue. I keep hearing indirect references to this but
nobody ever answering in detail.
BTW: the SiS DRM is also insecure - the memory manager can be used to
crash the box. Just feed it random crap in a tight loop and wait. If you
use sisfb however it seems ok - that uses a different memory handler.
Date: Wed Aug 11 04:24:20 2004
On Mer, 2004-08-11 at 02:00, Mike Mestnik wrote:
> --- Dave Airlie <airlied@linux.ie> wrote:
>
> > >
> > > Can the VIA DRI stuff get pushed through to the kernel with the S3
> > > stuff please, even if we mark VIA as experimental
> >
> > the DRM stuff? We need to mark as insecure, I really don't want anything
> > that the authors consider insecure to go anywhere outside the DRM...
> >
> Just for calarity.
> The DRM stuff is insecure, it should not go anywhere outside CVS.
Details ?
Date: Wed Aug 11 04:25:33 2004
<Pine.LNX.4.58.0408110217510.3763@skynet>
> the VIA/mach64/savage DRM when setup by the current DDXs all allow evil
> things from my current understanding, that is why they're DDXs haven't got
> the DRI support turned on by default in Xorg, so those DRMs are not to be
> built into a release, I think Eric has a good handle on what is and isn't
> allowed anyways ...
Mach64 isn't entirely secure. Yes we know that the author said so. The
via one I'm still trying to track down but its entirely A said B said
C thought D considered it insecure.
I need the original source of the rumour so I can find out if its true
From Jim.Gettys at hp.com Wed Aug 11 07:37:20 2004
Date: Wed Aug 11 07:37:41 2004
In-Reply-To: <4119CDED.2000107@sun.com>
<411999A5.6EF18405@nrubsig.org> <4119CDED.2000107@sun.com>
And recent experience showed us that making a library static
reduced our options greatly in compatibility.

This caused great anguish with the changes to xinerama; we couldn't
update apps to use a new protocol version.
So shipping static libraries only makes things worse, not
better.
- Jim

> Roland Mainz wrote:
> > No, that's not possible. We would have to gurantee backwards
> > compatibility to the old version (at least the commercial Unices may
> > require that), either via lots of #ifdef in the code or via storing the
> > old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
> > example of this nightmare.
>
> This commercial Unix vendor no longer ships any static libraries. If it's
> not stable enough yet, we just won't ship it, shared or static.
Date: Wed Aug 11 07:53:00 2004
Message-ID: <411A32AF.59D72519@nrubsig.org>
>
> Roland Mainz wrote:
> > No, that's not possible. We would have to gurantee backwards
> > compatibility to the old version (at least the commercial Unices may
> > require that), either via lots of #ifdef in the code or via storing the
> > old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
> > example of this nightmare.
>
> This commercial Unix vendor no longer ships any static libraries. If it's
> not stable enough yet, we just won't ship it, shared or static.
Erm... I wasn't even thinking about shipping it right now, regardless
whether it's shared or static.
Even Mozilla and Qt link XprintUtils currently statically for the same
reason: The API isn't stable yet... they even have their own (forked)
copies of the code right now. IMO this stuff should be treated as helper
libraries for the tools in the X.org tree (instead of symlinking the
files into the single tool directories).
If someone wants other examples for this: liblbxutil isn't a shared
library either...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Wed Aug 11 09:03:15 2004
Message-ID: <411A341A.5795EBAD@nrubsig.org>
Jim Gettys wrote:
> > Roland Mainz wrote:
> > > No, that's not possible. We would have to gurantee backwards
> > > compatibility to the old version (at least the commercial Unices may
> > > require that), either via lots of #ifdef in the code or via storing the
> > > old code in a seperate dir. The mess with libXaw6 vs. libXaw7 is a good
> > > example of this nightmare.
> >
> > This commercial Unix vendor no longer ships any static libraries. If it's
> > not stable enough yet, we just won't ship it, shared or static.
>
> And recent experience showed us that making a library static
> reduced our options greatly in compatibility.
>
> This caused great anguish with the changes to xinerama; we couldn't
> update apps to use a new protocol version.
>
> So shipping static libraries only makes things worse, not
> better.
We weren't thinking about shipping the two libs right now, only linking
the consumers in the X.org tree against it to avoid the pain of
symlinking the files around and undo that for the next release when the
API has become stable. I am not ready with testing the new version (and
found a very bad time to fall sick again) and Tanja isn't ready with the
manual pages either.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Wed Aug 11 09:55:39 2004
In-Reply-To: <55217.192.138.110.87.1092228831.squirrel@www.shipmail.org>
<Pine.LNX.4.58.0408110217510.3763@skynet>
<55217.192.138.110.87.1092228831.squirrel@www.shipmail.org>
On Mer, 2004-08-11 at 13:53, Thomas Hellstr?m wrote:
> When I did some cleaning up of the via drm code I noticed that the memory
> manager seems identical to the SiS one, so if there is a problem with
> that, then there is a problem with the via driver.
Yeah I know about one.
> Also the unichrome 2d driver allows XvMC dri clients to map (RW) the
> framebuffer and the whole register space, and I know that at certain video
> register write combinations will lock my machine hard. From my point of
> view, however, this is a deficiency in the unichrome 2d driver rather
> than in the via drm driver.
DRI allows for locking the box. I can lock the radeon, I can lock the
matrox. Its supposed to not allow worse than that. The XvMC slice
registers for mpeg are all in one location - is that too close to other
registers to split up the map ? If not perhaps the slice load should be
in the DRI module ?
From keith at tungstengraphics.com Wed Aug 11 10:18:54 2004
Date: Wed Aug 11 10:19:02 2004
<Pine.LNX.4.58.0408110128210.3763@skynet>
Message-ID: <411A54FE.4080306@tungstengraphics.com>
Alan Cox wrote:
> On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
>
>>>Can the VIA DRI stuff get pushed through to the kernel with the S3
>>>stuff please, even if we mark VIA as experimental
>>
>>the DRM stuff? We need to mark as insecure, I really don't want anything
>>that the authors consider insecure to go anywhere outside the DRM...
>
>
> Who considers it insecure and where is it documented then I'll go and
> have a look at the issue. I keep hearing indirect references to this but
> nobody ever answering in detail.
In general the issue is with chips that can write back to system memory or
read from it in one way or another.
There are two broad categories for this: 1) using the blit or dma engine and
2) 'status' writebacks.
1) is pretty obvious - there are cards which can target regular memory taking
physical addresses for blits, render targets, whatever.
2) refers to cards which have 'breadcrumb' or other helpful mechanisms which
write back a word or two of status data to some physical address in main
memory so that drivers can avoid polling the card.
If either of these can be set up & activated by the command stream exposed to
the DRI client, the card is considered insecure.
One way we've tried to operate is to seperate geometry/triangle data from
general commands, which the driver legitimately wants to use to set state, but
which could be used maliciously for the purposes above. A lot of hardware
allows geometry data to be passed via seperate mechanisms from the general
command stream, so we can, eg. put vertices in an agp buffer while passing a
command stream or abstracted packets to the kernel for verification before
handing off to hardware.
This depends on the existence of a method for passing vertex data seperately
from other commands. The mach64, for example, doesn't have such a mechanism,
vertex data looks just like other commands & has to go through the same
stream. This is when passing data through the kernel starts to look daunting,
as it *all* has to go that route and be verified along the way.
That said, in the current i915 driver, I've got just such a pathway, which
I've tested (on fast CPU's) and it wasn't too bad...
Keith
From ufz6 at rz.uni-karlsruhe.de Wed Aug 11 12:31:57 2004
Date: Wed Aug 11 13:05:53 2004
Subject: [Xorg] Region Routines in the ScreenRect
Message-ID: <20040811200551.300409EB6A@freedesktop.org>
I would to understand the usage of Regions operations which almost used in
the code.
I will try simply describing what I have understood.
Region describe the state of a rectangular in screen, each X,Y in this
Region has value 0 or 1. The purpose of this is that we could control the
viewable parts of screen. When X, Y position of a Region is 1, then that
pixel can me filled. Most of GC Operation use Region to simplify the
operations.
Please if I am wrong correct me or describe it better.

Amir Bukhari
From molter at tin.it Wed Aug 11 13:14:30 2004
From: molter at tin.it (Marco Molteni)
Date: Wed Aug 11 13:21:35 2004
Subject: [Xorg] make World fails on FreeBSD (looks into /usr/X11R6)
Message-ID: <20040811221430.3fd460dd.molter@tin.it>
Hi,
I am trying to build xorg (cvs updated as of yesterday) on FreeBSD -current
and the build, launched as "make World", fails as in the log below.
My feeling is that the build fails because it is not self-hosted; with
this I mean that it goes peeking for include files into /usr/X11R6,
which contain Xfree86, and the result is the following:
======================================================
cc -O2 -fno-strict-aliasing -ansi -pedantic -Wno-system-headers -Dasm=__asm
-Wall -Wpointer-arith -Wundef -I/usr/X11R6/include -I/usr/local/include -I/usr
/local/include/freetype2 -I/usr/local/include/freetype2/config -I../../exports/i
nclude/X11 -I../.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNA
RROWPROTO -DMITSHM -DXFT -DXFREE86_FT2 -DXRENDER -c do_traps.c
do_traps.c:113: error: syntax error before '*' token
do_traps.c:113: warning: type defaults to ìnt' in declaration of `traps'
do_traps.c:113: error: ISO C forbids data definition with no type or storage cla
ss
do_traps.c: In function ÌnitFixedTraps':
do_traps.c:130: error: `XTrap' undeclared (first use in this function)
do_traps.c:130: error: (Each undeclared identifier is reported only once
do_traps.c:130: error: for each function it appears in.)
do_traps.c:130: error: `curTrap' undeclared (first use in this function)
do_traps.c:131: warning: ISO C90 forbids mixed declarations and code
do_traps.c:145: error: syntax error before ')' token
do_traps.c:129: warning: unused variable `left'
do_traps.c:129: warning: unused variable `right'
do_traps.c:129: warning: unused variable `top'
do_traps.c:129: warning: unused variable `bot'
do_traps.c: In function `DoFixedTraps':
do_traps.c:249: warning: implicit declaration of function `XRenderAddTraps'
do_traps.c: In function ÌnitFixedTraps':
do_traps.c:208: warning: value computed is not used
*** Error code 1
Stop in /home/src/xorg/build/programs/x11perf.
*** Error code 1
Stop in /home/src/xorg/build/programs.
*** Error code 1
Stop in /home/src/xorg/build.
*** Error code 1
Stop in /home/src/xorg/build.
======================================================
I am not at all an expert in building X, but if I look in xc/config/cf,
the only .cf file that references X11Base is FreeBSD's:
molter@gattaccio[/home/src/xorg/xc/config/cf]$ grep X11Base *.cf
FreeBSD.cf:#ifndef X11Base
FreeBSD.cf:#define X11Base /usr/X11R6
So, what am I doing wrong? Why is the make World using /usr/X11R6 at all?
thanks
marco
Date: Wed Aug 11 13:31:31 2004
In-Reply-To: <411A341A.5795EBAD@nrubsig.org>
<411A341A.5795EBAD@nrubsig.org>
> We weren't thinking about shipping the two libs right now, only linking
> the consumers in the X.org tree against it to avoid the pain of
> symlinking the files around and undo that for the next release when the
> API has become stable. I am not ready with testing the new version (and
> found a very bad time to fall sick again) and Tanja isn't ready with the
> manual pages either.
So, in that case, it is not ready, and must be removed from the tree. To
use your own words, 'I am not happy with playing alphatester for such a
combination in a _production_ environment'; please decide whether it is
ready for shipping, in which case it should be a shared library with
soversion 0.0.0, or it is not ready for shipping, in which case you
retract it to your own tree.
:) d
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040811/176f2383/attach
ment.pgp
Date: Wed Aug 11 13:32:02 2004
In-Reply-To: <20040811221430.3fd460dd.molter@tin.it>
References: <20040811221430.3fd460dd.molter@tin.it>
On Wed, 2004-08-11 at 13:14, Marco Molteni wrote:
> Hi,
>
> I am trying to build xorg (cvs updated as of yesterday) on FreeBSD -current
> and the build, launched as "make World", fails as in the log below.
>
> My feeling is that the build fails because it is not self-hosted; with
> this I mean that it goes peeking for include files into /usr/X11R6,
> which contain Xfree86, and the result is the following:
I believe I fixed this last night. Is your CVS checkout current as of
about 11 hours ago, and did you make Everything or make World since
updating if you had checked out previously?
--
Date: Wed Aug 11 13:38:52 2004
In-Reply-To: <1092256261.3402.11.camel@catsby.fooishbar.org>
On Wed, 2004-08-11 at 13:31, Daniel Stone wrote:
> On Wed, 2004-08-11 at 15:58, Roland Mainz wrote:
> > We weren't thinking about shipping the two libs right now, only linking
> > the consumers in the X.org tree against it to avoid the pain of
> > symlinking the files around and undo that for the next release when the
> > API has become stable. I am not ready with testing the new version (and
> > found a very bad time to fall sick again) and Tanja isn't ready with the
> > manual pages either.
>
> So, in that case, it is not ready, and must be removed from the tree. To
> use your own words, 'I am not happy with playing alphatester for such a
> combination in a _production_ environment'; please decide whether it is
> ready for shipping, in which case it should be a shared library with
> soversion 0.0.0, or it is not ready for shipping, in which case you
> retract it to your own tree.
I would disagree with this, and say that instead it's fine to build and
use the static lib internally in X.Org, but the lib must not be
installed unless it is also installed shared and soversion bumping is
done on API changes as appropriate.
--
From Deron.Johnson at Sun.COM Wed Aug 11 13:44:05 2004
Date: Wed Aug 11 13:44:08 2004
Subject: [Xorg] Region Routines in the ScreenRect
In-Reply-To: <20040811200551.300409EB6A@freedesktop.org>
References: <20040811200551.300409EB6A@freedesktop.org>
Message-ID: <411A8515.2050808@Sun.COM>
No. A region is a LIST of rectangles. Regions are typically used to
describe the shapes of windows, or where it is legal to draw within
a window, but regions are sometimes used for other things as well.
Here is an example of a complex region which contains many rectangles.
**
****
******
********
******
****
**
Each line in this diagram represents one of the rectangles in the
region list. In this case, all of the rectangles are 1 pixel high.
(A 1 pixel high rectangle is called a "span" in the X server).
> Region has value 0 or 1. The purpose of this is that we could control the
> viewable parts of screen.
No. What you are describing is a pixmap input specification to the shape
extension, which consists of 0's and 1's. The shape extension also takes
a region input specification, which consists of a list of rectangles.
When X, Y position of a Region is 1, then that
> pixel can me filled. Most of GC Operation use Region to simplify the
> operations.
From airlied at linux.ie Wed Aug 11 13:59:43 2004
From: airlied at linux.ie (Dave Airlie)
Date: Wed Aug 11 14:00:20 2004
<Pine.LNX.4.58.0408110217510.3763@skynet>
Message-ID: <Pine.LNX.4.58.0408112157500.29719@skynet>
>
> Mach64 isn't entirely secure. Yes we know that the author said so. The
> via one I'm still trying to track down but its entirely A said B said
> C thought D considered it insecure.
>
> I need the original source of the rumour so I can find out if its true
Well I've be spreading the rumour from IRC logs..
http://dri.sourceforge.net/IRC-logs/20040628.txt
>From Erdi Chen: "<erdi> the Via unichrome chip supports system memory to
framebuffer DMA bitblt, currently the DRI driver maps the IO registers to
user space, that maybe a problem"
Now that statement is enough for me to block it going anywhere until I
hear different ..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Date: Wed Aug 11 14:09:51 2004
<Pine.LNX.4.58.0408110217510.3763@skynet>
<Pine.LNX.4.58.0408112157500.29719@skynet>
> >From Erdi Chen: "<erdi> the Via unichrome chip supports system memory to
> framebuffer DMA bitblt, currently the DRI driver maps the IO registers to
> user space, that maybe a problem"
>
> Now that statement is enough for me to block it going anywhere until I
> hear different ..
Ok so that allows stealing data which is borderline problematic, and
I concur on the wrong side. I'll take a look at pushing the render
sequences into an ioctl at some point, since it generates long
command lists that should be fine.
Date: Wed Aug 11 14:56:56 2004
<1092256726.884.9.camel@leguin>
On Wed, 2004-08-11 at 21:38, Eric Anholt wrote:
> On Wed, 2004-08-11 at 13:31, Daniel Stone wrote:
> > So, in that case, it is not ready, and must be removed from the tree. To
> > use your own words, 'I am not happy with playing alphatester for such a
> > combination in a _production_ environment'; please decide whether it is
> > ready for shipping, in which case it should be a shared library with
> > soversion 0.0.0, or it is not ready for shipping, in which case you
> > retract it to your own tree.
>
> I would disagree with this, and say that instead it's fine to build and
> use the static lib internally in X.Org, but the lib must not be
> installed unless it is also installed shared and soversion bumping is
> done on API changes as appropriate.
It's going to stick around, and it's going to be hell, and it will cause
us hell in the future. It's there -> great! let's use it!, in most
people's minds, and externally deployed pseudo-random apps are far
easier to supersede than, say, X deployments.
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040811/2738e7ef/attach
ment.pgp
From ajax at nwnk.net Wed Aug 11 16:31:18 2004
Date: Wed Aug 11 16:38:05 2004
Subject: [Xorg] Friday's freeze
Hash: SHA1
What's the plan for the beta freeze Friday? Will we resync 6_7_99_1 from HEAD
or make a new 6_7_99_2 tag?
- - ajax
iD8DBQFBGqxIW4otUKDs0NMRAgEaAJ9y3qBoodJSGpnzJbI0UUcrbTs8tgCfSMLO
K/0+K72WBQ6wzZgRNV4j4p0=
=1tAl
From torgeir at pobox.com Wed Aug 11 16:41:29 2004
From: torgeir at pobox.com (Torgeir Veimo)
Date: Wed Aug 11 16:41:40 2004
Subject: [Xorg] CVS snapshot RPMs for Fedore Core 2
In-Reply-To: <41139DAA.1090603@bitplanet.net>
References: <41139DAA.1090603@bitplanet.net>
Message-ID: <1092267689.6719.1.camel@atlantis.netenviron.com>
On Fri, 2004-08-06 at 17:03 +0200, Kristian H?gsberg wrote:
> Hi,
>
> I have put together a set of RPMs for Xorg CVS as of August 5 in
>
> http://freedesktop.org/~krh
>
> In other words, these RPMs have the new set of extensions, but also a
> set of known bugs (see #351).
Are more recent RPMs being built? I'd like to test with more recent code
before filing bugs. (Am having problems in 16bit depth w radeon 7500,
fine in 24bit).
--
-Torgeir
Date: Wed Aug 11 16:44:21 2004
Subject: [Xorg] Friday's freeze
In-Reply-To: <200408111931.21991.ajax@nwnk.net>
On Wed, Aug 11, 2004 at 07:31:18PM -0400, Adam Jackson wrote:
> What's the plan for the beta freeze Friday? Will we resync 6_7_99_1 from HEAD

> or make a new 6_7_99_2 tag?
I will be making another snapshot tag late this evening after I work
through a few more bugs. I'll post an update here when that work is
complete.
FYI, I expect that there will be several more snapshot tags before the
code freeze as bugs are fixed.
Date: Wed Aug 11 18:29:19 2004
Subject: [Xorg] Re: Any patches for X.Org release?
If you could pick up the latest radeon_vtxfmt.c, r200_pixel.c,
r200_sanity.c files, they are pretty simple fixes...
I've looked at radeon,r200,i915,i810,i830,mach64,gamma,mga,r128 drivers
I'm not sure what the state of tdfx is, it has some changes...
Dave.
On Tue, 10 Aug 2004, Kevin E Martin wrote:
> On today's release wranglers call, someone asked if there were any new
> fixes from the DRI or Mesa projects that should be included in the next
> X.Org release. If there are any, could you please let us know? Thanks!
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Date: Wed Aug 11 18:33:44 2004
<Pine.LNX.4.58.0408120223290.21141@skynet>
Hash: SHA1
On Wednesday 11 August 2004 21:28, Dave Airlie wrote:
> If you could pick up the latest radeon_vtxfmt.c, r200_pixel.c,
> r200_sanity.c files, they are pretty simple fixes...
>
> I've looked at radeon,r200,i915,i810,i830,mach64,gamma,mga,r128 drivers
>
> I'm not sure what the state of tdfx is, it has some changes...
tdfx_render.c has a one-liner change; the rest is in sync with Mesa.
- - ajax
iD8DBQFBGsjyW4otUKDs0NMRAmlRAJ9FvEkd3xhX7UYgC/Iichboye7i9wCdG5M2
fCdiV4L+VAiy+fuHGGqecMI=
=7+mu
Date: Wed Aug 11 18:49:15 2004
<Pine.LNX.4.58.0408120223290.21141@skynet>
On Wed, 2004-08-11 at 18:28, Dave Airlie wrote:
> If you could pick up the latest radeon_vtxfmt.c, r200_pixel.c,
> r200_sanity.c files, they are pretty simple fixes...
>
> I've looked at radeon,r200,i915,i810,i830,mach64,gamma,mga,r128 drivers
>
> I'm not sure what the state of tdfx is, it has some changes...
Reminder to whoever decides to pick this up, please do this by importing
the affected files to the mesa vendor branch, not committing to head.
If you don't feel comfortable with this, please just file a bugzilla and
assign to me and I'll get to it after the composite fires are put out.
(also note that dri developers can do this :)
--
Date: Wed Aug 11 18:59:37 2004
<Pine.LNX.4.58.0408120223290.21141@skynet>
<1092275347.1200.8.camel@leguin>
>
> Reminder to whoever decides to pick this up, please do this by importing
> the affected files to the mesa vendor branch, not committing to head.
> If you don't feel comfortable with this, please just file a bugzilla and
> assign to me and I'll get to it after the composite fires are put out.
Also we should probably make a tag in the mesa/drm trees everytime we
merge it across so diffs can be done easier...
Dave.
>
> (also note that dri developers can do this :)
>
>
--
From jserv at linux2.cc.ntu.edu.tw Wed Aug 11 19:56:50 2004
Date: Wed Aug 11 19:57:03 2004
Subject: [Xorg] PATCH: fix xkb in KDrive
Hello all,
Since xkb in KDrive was organized, I think the XKB_IN_SERVER
macro seems to be redundant, and I made a small patch to get
xkb support in KDrive working.
Please consult the attachment to see if the patch is proper.
cheers,
Jim Huang
-------------- next part --------------
Index: xkb/maprules.c
===================================================================
RCS file: /cvs/xserver/xserver/xkb/maprules.c,v
diff -u -r1.1 maprules.c
--- xkb/maprules.c 25 Apr 2004 13:52:20 -0000 1.1
+++ xkb/maprules.c 11 Aug 2004 12:42:01 -0000
@@ -34,8 +34,6 @@
#define XOS_USE_NO_LOCKING
#include <X11/Xos_r.h>

-#ifndef XKB_IN_SERVER
-
#include <X11/Xproto.h>
#include <X11/Xlib.h>
#include <X11/Xos.h>
@@ -47,8 +45,9 @@
#include <X11/extensions/XKMformat.h>
#include <X11/extensions/XKBfileInt.h>
#include <X11/extensions/XKBrules.h>
+#include <X11/extensions/XKBsrv.h>

-#else
+#if 0

#define NEED_EVENTS
#include <X11/Xproto.h>
Date: Wed Aug 11 19:58:37 2004
Subject: [Xorg] remains of old mesa imports into X org tree
In a standard X org tree the extras/Mesa/src directory has a big bunch of
[ch] files that look to be left over from when Mesa went to the
newtree, there are probably others these are the most obvious,
most of those file are moved to extra/Mesa/src/mesa/main
Should they be removed (probably after the release just in case),
Dave.
--
Date: Wed Aug 11 22:16:36 2004
Subject: [Xorg] XORG-6_7_99_2 snapshot testing
The CVS tree has been tagged with the XORG-6_7_99_2 snapshot tag. We
expect that there will be several snapshot tags before the code freeze
as bugs are fixed.
For those doing package testing, please built updated packages against
this tag. For everyone, please test this snapshot as described on the
release status page:
If you find any problems, please report them here and in bugzilla.
Thanks!
Date: Wed Aug 11 22:17:31 2004
night.
listed below.
Fixed yesterday: 10
Added yesterday: 7
-----------------------------
- Keith Packard said he would do this
- He found another sprite that would be sufficient
* Bug #594: X crash with invalid file in gv
- fb needs to range check arguments to CreatePixmap
- What about other areas of the server?
* Bug 770: Hangs with Chromium
- Eric Anholt is looking into this one
- Keith Packard said he would talk with Thomas E. Dickey about using
his upstream xterm in this X.Org release
- Recent patches purport to fix this problem and have been checked in
- More testing is needed
- Roland Mainz suggests reverting behavior back to X11R6.6 version
- Review needed by Matthieu Herrb who made the post-R6.6 change
- He said he would check in a patch to disable the extra visuals in
the connection block ASAP so that testing can proceed
- Answer from 11 Aug 04 release wranglers call is yes
- Stuart Kreitman is working on making Xevie a separate library
* Bug 1024: Japanese ctext conversion bug
* Bug 1029: Hard failure if socket directories cannot be chowned to root
- Proposed solutions:
1. Create a helper program that is setuid root to create dir, or
2. Revert the change back to X11R6.7 version
* Bug 1032: Damage causes rootless XDarwin to crash
- Possible wrapper ordering issue
* Bug 1042: File INSTALL breaks make install on cygwin
- Suggested fix available
* Bug 1051: Mesa/DRI drivers need updating
- Eric Anholt said that he would handle the merge after finishing his
current work
Date: Wed Aug 11 22:34:29 2004
Subject: [Xorg] remains of old mesa imports into X org tree
References: <Pine.LNX.4.58.0408120356020.21141@skynet>
On Wed, 2004-08-11 at 19:58, Dave Airlie wrote:
> In a standard X org tree the extras/Mesa/src directory has a big bunch of
> [ch] files that look to be left over from when Mesa went to the
> newtree, there are probably others these are the most obvious,
>
> most of those file are moved to extra/Mesa/src/mesa/main
>
> Should they be removed (probably after the release just in case),
Yes, they should be removed, along with large chunks of Mesa not related
to X.Org (GLU, glut, programs, ?). It's on my mental todo, but not in a
bug yet. I'd like to get that done for the release, to bring dist size
back down.
--
Date: Thu Aug 12 00:19:49 2004
Subject: [Xorg] ARGB visuals from Composite extension
Message-ID: <E1Bv9sF-0001Zy-I0@evo.keithp.com>
The Composite extension creates an ARGB visual for applications to use in
constructing translucent windows. In the current implementation, that
visual is a part of the normal connection setup information, making it
possible for applications to discover the visual through the normal Xlib
methods.
However, this new visual is known to confuse the Flash plugin for Mozilla
(it assumes the Mozilla window uses this visual and crashes as a result).
So, to avoid this problem, I proposed that the Composite specific visuals
be hidden from the normal connection setup information and only made
available through an extension request.
So far, so good. Applications using core requests won't see the new
visuals, and applications using Composite will.
Now comes the tricky part.
Once an application has used the Composite extension to discover this shiny
new visual, it has to pass that visual structure around to create windows,
pictures and the like. Xlib is mostly happy to be handed some random
visual structure and so it mostly works. However, Xlib does believe that
it knows all of the available visuals, so extension functions like
_XVIDtoVisual will *not* find a visual structure from the new visual ID.
This turns out to be really bad -- the Render extension needs to locate
PictFormats associated with visuals, and it does so by locating the visual
based on the ID passed back by the X server. This means that applications
cannot locate PictFormats for these new visuals, which makes it pretty
hard to create Pictures for ARGB windows.
I don't know what other parts of the system assume that every visual is
stored in the Xlib visual structures.
My current kludge in the xlibs project is to report the visuals in the core
setup and then use a magic environment variable to hide these depth-32
visuals from mozilla.
I could hack Xcomposite to *modify* the list of Visuals held by Xlib so
that all of the existing Xlib functions work correctly. This will only fix
the Render problem if this Xcomposite function is called before the Render
extension is initialized. I could further hack Xcomposite to go mash the
Xrender structures as well. Yuck.
Right now, I'm leaning towards just leaving things as they are and
expecting that the Flash plugin will get fixed at some point, or that
we'll kludge Mozilla to handle the problem automatically.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040812/693a67a1/attach
ment-0001.pgp
From de_lupus at pandora.be Thu Aug 12 03:41:38 2004
From: de_lupus at pandora.be (Kristof Vansant)
Date: Thu Aug 12 01:52:17 2004
Subject: [Xorg] Is there no way to have PNP monitor support?
Message-ID: <1092307298.4648.2.camel@lupus.lupusje.org>
Isn't there a way to have PNP monitor support without having to manual
edit xorg.conf or edit xorg.conf by a external program like kudzu.
What is needed to have some decent monitor detection?
--
lupusBE (Kristof Vansant Belgium
From ufz6 at rz.uni-karlsruhe.de Thu Aug 12 02:26:50 2004
Date: Thu Aug 12 02:26:13 2004
Subject: [Xorg] SHAPE and Composite Extensions
Message-ID: <20040812092606.5F1A39EB19@freedesktop.org>
The Shape Extension gives Applications the ability to define non-rectangular
window. What happened when this window is redirect to an off-screen? Did
this will affect also GC Operations wrapped by Composite?
Amir Bukhari
From joerg at britannica.bec.de Thu Aug 12 02:01:10 2004
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Thu Aug 12 02:39:28 2004
Subject: [Xorg] Basic DragonFly support for 6.8
Message-ID: <20040812090109.GA24898@britannica.bec.de>
Hi all,
it would be nice if the patch at ftp://dragonflybsd.dyndns.org/df.diff
could be included. It's not enough to fully build the World with our
system GCC 3.4, but those can be handled separately. The DragonFly.cf
was initially submit by Andreas Hauser (<andy@splashground.de>) for
the DragonFly port.
Joerg
Date: Thu Aug 12 04:06:16 2004
Subject: [Xorg] what is the status of xcb?
What is the status of xcb? The api still not stable? What is taking it
so long :) only after a stable release, toolkits like gtk will start
using it.
--
Date: Thu Aug 12 05:24:41 2004
In-Reply-To: <E1Bv9sF-0001Zy-I0@evo.keithp.com>
References: <E1Bv9sF-0001Zy-I0@evo.keithp.com>
Yeah, I had a nagging feeling that this would happen, on our
last call. Sigh...
I think the environment variable kludge is the least evil
under the circumstances, and working with vendors to fix
broken applications. Oh well.
Please add a bugzilla entry that blocks the documentation
bug so we make sure to release note this.
Anyone happen to know the flash developer(s)? We should give
them a heads up in any case.
- Jim
On Thu, 2004-08-12 at 03:19, Keith Packard wrote:
> The Composite extension creates an ARGB visual for applications to use in
> constructing translucent windows. In the current implementation, that
> visual is a part of the normal connection setup information, making it
> possible for applications to discover the visual through the normal Xlib
> methods.
>
> However, this new visual is known to confuse the Flash plugin for Mozilla
> (it assumes the Mozilla window uses this visual and crashes as a result).
> So, to avoid this problem, I proposed that the Composite specific visuals
> be hidden from the normal connection setup information and only made
> available through an extension request.
>
> So far, so good. Applications using core requests won't see the new
> visuals, and applications using Composite will.
>
> Now comes the tricky part.
>
> Once an application has used the Composite extension to discover this shiny
> new visual, it has to pass that visual structure around to create windows,
> pictures and the like. Xlib is mostly happy to be handed some random
> visual structure and so it mostly works. However, Xlib does believe that
> it knows all of the available visuals, so extension functions like
> _XVIDtoVisual will *not* find a visual structure from the new visual ID.
>
> This turns out to be really bad -- the Render extension needs to locate
> PictFormats associated with visuals, and it does so by locating the visual
> based on the ID passed back by the X server. This means that applications
> cannot locate PictFormats for these new visuals, which makes it pretty
> hard to create Pictures for ARGB windows.
>
> I don't know what other parts of the system assume that every visual is
> stored in the Xlib visual structures.
>
> My current kludge in the xlibs project is to report the visuals in the core
> setup and then use a magic environment variable to hide these depth-32
> visuals from mozilla.
>
> I could hack Xcomposite to *modify* the list of Visuals held by Xlib so
> that all of the existing Xlib functions work correctly. This will only fix
> the Render problem if this Xcomposite function is called before the Render
> extension is initialized. I could further hack Xcomposite to go mash the
> Xrender structures as well. Yuck.
>
> Right now, I'm leaning towards just leaving things as they are and
> expecting that the Flash plugin will get fixed at some point, or that
> we'll kludge Mozilla to handle the problem automatically.
>
> -keith
>
>
>
> ______________________________________________________________________
> _______________________________________________
> xorg mailing list
From sandmann at daimi.au.dk Thu Aug 12 05:20:30 2004
Date: Thu Aug 12 05:30:13 2004
In-Reply-To: <E1Bv9sF-0001Zy-I0@evo.keithp.com>
References: <E1Bv9sF-0001Zy-I0@evo.keithp.com>
Message-ID: <ye8oelgy2cx.fsf@ec04.daimi.au.dk>
Keith Packard <keithp@keithp.com> writes:
> Right now, I'm leaning towards just leaving things as they are and
> expecting that the Flash plugin will get fixed at some point, or that
> we'll kludge Mozilla to handle the problem automatically.
That seems like exactly the right thing to do. There is no theoretical
reason an X server without composite could not report similar visuals,
right?
S?ren
From lars at trolltech.com Thu Aug 12 05:37:58 2004
From: lars at trolltech.com (Lars Knoll)
Date: Thu Aug 12 05:31:04 2004
Subject: [Xorg] what is the status of xcb?
In-Reply-To: <1092315522.5390.1.camel@lupus.lupusje.org>
References: <1092315522.5390.1.camel@lupus.lupusje.org>
Message-ID: <200408121437.58513.lars@trolltech.com>
On Thursday 12 August 2004 14:58, Kristof Vansant wrote:
> What is the status of xcb? The api still not stable? What is taking it
> so long :) only after a stable release, toolkits like gtk will start
> using it.
We had a look at it trying to evaluate whether it might be interesting for Qt
in the future. But as long as regular xlib is not xcb based, it's almost
impossible to switch.
The main reasons are that some applications circumvent the toolkit, calling
xlib commands themselves and the opengl libraries that require xlib. If we'd
base Qt on xcb, application calls into xlib would fail and you wouldn't be
able to use opengl anymore.
Using xcb as basis for xlib still seems to require some work, as at least the
XIM code is not really implemented for xcb based xlibs.
Cheers,
Lars
Date: Thu Aug 12 05:34:21 2004
Message-ID: <a728f9f90408120534390c7f10@mail.gmail.com>
On Thu, 12 Aug 2004 10:41:38 +0000, Kristof Vansant <de_lupus@pandora.be> wrote:
> Isn't there a way to have PNP monitor support without having to manual
> edit xorg.conf or edit xorg.conf by a external program like kudzu.
> What is needed to have some decent monitor detection?
just about all current xorg video drivers support DDC so most monitors
should work automagically.
Alex
>
> --
> lupusBE (Kristof Vansant Belgium
>
Date: Thu Aug 12 05:36:31 2004
Subject: [Xorg] Basic DragonFly support for 6.8
In-Reply-To: <20040812090109.GA24898@britannica.bec.de>
References: <20040812090109.GA24898@britannica.bec.de>
Message-ID: <a728f9f9040812053644277aa2@mail.gmail.com>
Since we are in a feature freeze, you'll probably have to wait for the
next release. your best bet it to open a bug against xorg on
http://bugs.freedesktop.org and include the patch. then it can be
reviewed and committed.
Alex
On Thu, 12 Aug 2004 11:01:10 +0200, Joerg Sonnenberger
<joerg@britannica.bec.de> wrote:
> Hi all,
> it would be nice if the patch at ftp://dragonflybsd.dyndns.org/df.diff
> could be included. It's not enough to fully build the World with our
> system GCC 3.4, but those can be handled separately. The DragonFly.cf
> was initially submit by Andreas Hauser (<andy@splashground.de>) for
> the DragonFly port.
>
> Joerg
Date: Thu Aug 12 05:48:47 2004
<a728f9f90408120534390c7f10@mail.gmail.com>
<1092322728.5462.17.camel@lupus.lupusje.org>
Message-ID: <a728f9f90408120548707af770@mail.gmail.com>
On Thu, 12 Aug 2004 14:58:48 +0000, Kristof Vansant <de_lupus@pandora.be> wrote:
> but what do I have to enable to have things configured auto?
>
just plug in the monitor and assuming the video and monitor support
DDC and you have a working X config, it should just work.
Alex
>
>
> > On Thu, 12 Aug 2004 10:41:38 +0000, Kristof Vansant <de_lupus@pandora.be> wr
ote:
> > > Isn't there a way to have PNP monitor support without having to manual
> > > edit xorg.conf or edit xorg.conf by a external program like kudzu.
> > > What is needed to have some decent monitor detection?
> >
> > just about all current xorg video drivers support DDC so most monitors
> > should work automagically.
> >
> > Alex
> >
> > >
> > > --
> > > lupusBE (Kristof Vansant Belgium
> > >
> --
>
>
Date: Thu Aug 12 05:50:36 2004
In-Reply-To: <a728f9f90408120534390c7f10@mail.gmail.com>
Message-ID: <411B6724.9000208@winischhofer.net>
Alex Deucher wrote:
> On Thu, 12 Aug 2004 10:41:38 +0000, Kristof Vansant <de_lupus@pandora.be> wrot
e:
>
>>Isn't there a way to have PNP monitor support without having to manual
>>edit xorg.conf or edit xorg.conf by a external program like kudzu.
>>What is needed to have some decent monitor detection?
>
>
> just about all current xorg video drivers support DDC so most monitors
> should work automagically.
... provided that you don't overrule the timings with the HorizSync
and/or VertRefresh options (which many people unfortunatly still do).
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Thu Aug 12 06:03:40 2004
In-Reply-To: <a728f9f90408120534390c7f10@mail.gmail.com>
but what do I have to enable to have things configured auto?
e:
> > Isn't there a way to have PNP monitor support without having to manual
> > edit xorg.conf or edit xorg.conf by a external program like kudzu.
> > What is needed to have some decent monitor detection?
>
> just about all current xorg video drivers support DDC so most monitors
> should work automagically.
>
> Alex
>
> >
> > --
> > lupusBE (Kristof Vansant Belgium
> >
--
Date: Thu Aug 12 07:21:18 2004
In-Reply-To: <20040812051727.GB6102@kem.org>
References: <20040812051727.GB6102@kem.org>
Message-ID: <ye83c2sxwrq.fsf@ec04.daimi.au.dk>
Kevin E Martin <kem@freedesktop.org> writes:
> * Bug #999: Release notes for next release
> - Need someone to start documenting changes for release notes
I'll take a look at this.
S?ren
Date: Thu Aug 12 08:03:59 2004
Subject: [Xorg] Solicitation of screen shots of new facilities in action...
Well, we have a release coming up.
It sure would be nice to have some up to date eye candy screen
shots showing off what the new facilities (e.g. Composite, Damage,
Evie, etc.) to go with the release.
We clearly have Keithp's dated page from last fall, which
also explains how this stuff all works; but the shots on that
page, while interesting to practitioners of the art, aren't really
suitable for general consumption overall. And since then,
we have lots of other kool stuff (tm) we can showcase, up to
and including LookingGlass and Croquet exploiting the new
features.
So if people will send me screenshots or pointers to screenshots,
I'll try to put together a page that showcases better what
becomes possible given the new technology about to hit the streets.
Thanks greatly!
- Jim
Date: Thu Aug 12 08:06:55 2004
In-Reply-To: Your message of "Thu, 12 Aug 2004 11:26:50 +0200."
<20040812092606.5F1A39EB19@freedesktop.org>
Message-ID: <E1BvHAA-0001mn-2X@evo.keithp.com>
Around 11 o'clock on Aug 12, "Amir Bukhari" wrote:
> The Shape Extension gives Applications the ability to define non-rectangular
> window. What happened when this window is redirect to an off-screen?
The window will be stored in a pixmap of the size of the window as if it
were unshaped; areas beyond the shape will be undefined. Automatic
compositing will copy only those areas within the shape. Manual
compositing should respect the shape. xcompmgr demonstrates how to do
this by constructing a region from the window clip list.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040812/f726fc90/attach
ment.pgp
Date: Thu Aug 12 08:10:23 2004
<ye8oelgy2cx.fsf@ec04.daimi.au.dk>
Message-ID: <E1BvHDT-0001nA-1L@evo.keithp.com>
> That seems like exactly the right thing to do. There is no theoretical
> reason an X server without composite could not report similar visuals,
> right?
Correct. And, without a compositing manager, it works perfectly normally,
but with a compositing manager, placing zeros in the upper 8 bits leaves
the window completely transparent...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040812/6ed9f48b/attach
ment.pgp
From tmccrary at ndindustries.com Thu Aug 12 08:27:45 2004
From: tmccrary at ndindustries.com (Tony McCrary)
Date: Thu Aug 12 08:27:49 2004
Message-ID: <411B8C71.9070201@ndindustries.com>
Hi,
I have installed the new branch of Xorg and enabled the composite
extension (which loads fine).
However, I cannot seem to find anything like xcompmgr to enable cool
effects like transparency or drop shadows.
Could anyone point me in the direction of where to download/checkout
a version of xcompmgr or has there been a replacement for this type of
functionality (compositing manager I believe)?
--
Regards,
Tony McCrary

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040812/e8570672/attachm
ent.htm
From Deron.Johnson at Sun.COM Thu Aug 12 09:05:37 2004
Date: Thu Aug 12 09:05:43 2004
In-Reply-To: <20040812092606.5F1A39EB19@freedesktop.org>
References: <20040812092606.5F1A39EB19@freedesktop.org>
Message-ID: <411B9551.1060903@Sun.COM>
The right thing will still happen. The backing pixmap will be the size
of the rectangle which encloses the borderSize region. The portion of
the backing pixmap which is not within the borderSize region will
never be rendered to. (In my LG3D-modified X server, I actually
zero out these pixels which are never rendered, but I only do this
because I currently don't support the shape extension. When this
support is added I can probably toss the zeroing code).
Amir Bukhari wrote:
> The Shape Extension gives Applications the ability to define non-rectangular
> window. What happened when this window is redirect to an off-screen? Did
> this will affect also GC Operations wrapped by Composite?
>
> Amir Bukhari
> E-Mail: ufz6@rz.uni-karlsruhe.de
>
> _______________________________________________
> xorg mailing list
Date: Thu Aug 12 09:25:01 2004
In-Reply-To: <411B8C71.9070201@ndindustries.com>
References: <411B8C71.9070201@ndindustries.com>
Message-ID: <411B995C.9060706@bitplanet.net>
Tony McCrary wrote:
> Hi,
>
> I have installed the new branch of Xorg and enabled the composite
> extension (which loads fine).
>
> However, I cannot seem to find anything like xcompmgr to enable cool
> effects like transparency or drop shadows.
>
> Could anyone point me in the direction of where to download/checkout
> a version of xcompmgr or has there been a replacement for this type of
> functionality (compositing manager I believe)?
Check this document for instructions:
http://ruinaudio.com/xorg-cvs-howto.txt
Kristian
From molter at tin.it Thu Aug 12 10:40:38 2004
From: molter at tin.it (Marco Molteni)
Date: Thu Aug 12 10:42:19 2004
References: <20040811221430.3fd460dd.molter@tin.it>
<1092256317.884.6.camel@leguin>
Message-ID: <20040812194038.2adacf5e.molter@tin.it>
On Wed, 11 Aug 2004 Eric Anholt <eta@lclark.edu> wrote:
> On Wed, 2004-08-11 at 13:14, Marco Molteni wrote:
> > Hi,
> >
> > I am trying to build xorg (cvs updated as of yesterday) on FreeBSD
> > -current and the build, launched as "make World", fails as in the
> > log below.
> >
> > My feeling is that the build fails because it is not self-hosted;
> > with this I mean that it goes peeking for include files into
> > /usr/X11R6, which contain Xfree86, and the result is the following:
>
> I believe I fixed this last night. Is your CVS checkout current as of
> about 11 hours ago, and did you make Everything or make World since
> updating if you had checked out previously?
Eric,
I am impressed :-) Builds fine now.
Thanks
marco
From tmccrary at ndindustries.com Thu Aug 12 12:19:06 2004
From: tmccrary at ndindustries.com (Tony McCrary)
Date: Thu Aug 12 12:19:13 2004
In-Reply-To: <411B995C.9060706@bitplanet.net>
References: <411B8C71.9070201@ndindustries.com>
<411B995C.9060706@bitplanet.net>
Message-ID: <411BC2AA.60604@ndindustries.com>
Thanks Kristian!
Unfortunately, I get all kinds of crazy artifacts when I run xcompmgr.
I have also noticed that any gecko control in an application (Firefox
browser window, Thunderbird HTML panel, etc) seems to flicker like
crazy. In Firefox's case, the tabs seem to flip back and forth
automatically.
The effects look cool until my computer completely locks up though. :)
I'll have to file a bug report.
> Tony McCrary wrote:
>
>> Hi,
>>
>> I have installed the new branch of Xorg and enabled the composite
>> extension (which loads fine).
>>
>> However, I cannot seem to find anything like xcompmgr to enable
>> cool effects like transparency or drop shadows.
>>
>> Could anyone point me in the direction of where to
>> download/checkout a version of xcompmgr or has there been a
>> replacement for this type of functionality (compositing manager I
>> believe)?
>
>
> Check this document for instructions:
>
> http://ruinaudio.com/xorg-cvs-howto.txt
>
> Kristian
>
>
--
Regards,
Tony McCrary
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040812/ca4c4449/attachm
ent.html
From dominatus at gmail.com Thu Aug 12 12:41:10 2004
Date: Thu Aug 12 12:41:20 2004
References: <1092323016.3250.107.camel@localhost.localdomain>
Message-ID: <d3ca506904081212412a5d1d06@mail.gmail.com>
Well, I have these but it's using the xcompmgr on KDrive, not on the
correct xorg tree as it still crashes the WM after about...2 minutes,
but I think these pics are quite nice looking if I do say so myself :p
And they show off the shadows pretty well:
http://www.lynucs.org/index.php?screen_id=1759409500411796a9ba106&p=screen
and
http://www.gnome-look.org/content/show.php?content=14958
On Thu, 12 Aug 2004 11:03:36 -0400, Jim Gettys <jim.gettys@hp.com> wrote:
> Well, we have a release coming up.
>
> It sure would be nice to have some up to date eye candy screen
> shots showing off what the new facilities (e.g. Composite, Damage,
> Evie, etc.) to go with the release.
>
> We clearly have Keithp's dated page from last fall, which
> also explains how this stuff all works; but the shots on that
> page, while interesting to practitioners of the art, aren't really
> suitable for general consumption overall. And since then,
> we have lots of other kool stuff (tm) we can showcase, up to
> and including LookingGlass and Croquet exploiting the new
> features.
>
> So if people will send me screenshots or pointers to screenshots,
> I'll try to put together a page that showcases better what
> becomes possible given the new technology about to hit the streets.
> Thanks greatly!
> - Jim
>
> _______________________________________________
> xorg mailing list
>
From alan at lxorguk.ukuu.org.uk Thu Aug 12 13:31:37 2004
Date: Thu Aug 12 14:34:01 2004
In-Reply-To: <411BD2CA.9020606@chen11.com>
<Pine.LNX.4.58.0408110217510.3763@skynet>
<Pine.LNX.4.58.0408112157500.29719@skynet>
<411BD2CA.9020606@chen11.com>
On Iau, 2004-08-12 at 21:27, Erdi Chen wrote:
> I have some working test code that implements AGP ring buffers (the
> current DRI code waits for engine idle and ping pongs between two big
> buffers). For multiple clients, each client would have its private
> buffer allocate it system memory. The private buffer is copied to the
> ring buffer when the client does a flush. I am hoping to integrate this
> ring buffer code into the DRM driver sometime soon.
Cool stuff - thanks for the status report.
Alan
Date: Thu Aug 12 14:34:49 2004
In-Reply-To: <E1BvHDT-0001nA-1L@evo.keithp.com>
References: <E1BvHDT-0001nA-1L@evo.keithp.com>
On Iau, 2004-08-12 at 16:10, Keith Packard wrote:
> Correct. And, without a compositing manager, it works perfectly normally,
> but with a compositing manager, placing zeros in the upper 8 bits leaves
> the window completely transparent...
Isn't that in truth a property of how you encode alpha values rather
than a fundamental unarguable happening ?
Date: Thu Aug 12 14:52:37 2004
In-Reply-To: Your message of "Thu, 12 Aug 2004 21:32:21 BST."
Message-ID: <E1BvNUk-00022f-AW@evo.keithp.com>
> Isn't that in truth a property of how you encode alpha values rather
> than a fundamental unarguable happening ?
Yes. We could (somehow) encode alpha values as translucency rather than
opacity, but the resulting confusion for applications attempting to use
those visuals as intended would probably be spectacular.
I did hack the Xserver to make the RGB->pixel conversion routines mask in
appropriate alpha bits, and fixed Gdk to do the same, so applications
using either of those two mechanisms actually end up working correctly.
And, we could hack the compositing manager to ignore alpha bits for some
windows easily enough.
The real problem here is that Flash assumes that Mozilla selects the ARGB
visual, when in fact it appears to avoid it somehow. The result is that
Flash crashes all of mozilla, which is pretty harsh. That's independent
of how that visual is used within the system.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040812/68e28e14/attach
ment.pgp
From ttb at tentacle.dhs.org Thu Aug 12 15:39:40 2004
From: ttb at tentacle.dhs.org (John McCutchan)
Date: Thu Aug 12 16:04:26 2004
In-Reply-To: <E1BvNUk-00022f-AW@evo.keithp.com>
References: <E1BvNUk-00022f-AW@evo.keithp.com>
Message-ID: <1092350380.22268.7.camel@vertex>
On Thu, 2004-08-12 at 17:52, Keith Packard wrote:
>
> I did hack the Xserver to make the RGB->pixel conversion routines mask in
> appropriate alpha bits, and fixed Gdk to do the same, so applications
> using either of those two mechanisms actually end up working correctly.
>
> And, we could hack the compositing manager to ignore alpha bits for some
> windows easily enough.
>
> The real problem here is that Flash assumes that Mozilla selects the ARGB
> visual, when in fact it appears to avoid it somehow. The result is that
> Flash crashes all of mozilla, which is pretty harsh. That's independent
> of how that visual is used within the system.
Both of those are bugs in mozilla and flash.
Composite is experimental, users of it should expect things to break.
You shouldn't be hacking around application bugs in composite. I say we
let mozilla and macromedia know of the bug (They should already, I
remember reading about this bug a LONG time ago).
In the kernel world, if the kernel changes in a valid way and breaks
apps Linus doesn't introduce some hack to fix it. He tells the app
authors to fix their bugs -- and rightly so.
I think this comes down to who is the leader? X.org or macromedia (could
be any program/company)?
Who sets the rules?
John
From ryan.gallagher at comcast.net Thu Aug 12 16:00:42 2004
From: ryan.gallagher at comcast.net (Ryan)
Date: Thu Aug 12 16:05:19 2004
Here's one that looks deceptively good.
http://ruinaudio.com/Xorg-xcompmgr.png
-ry
On Thu, 2004-08-12 at 11:03 -0400, Jim Gettys wrote:
>
>
> We clearly have Keithp's dated page from last fall, which
> also explains how this stuff all works; but the shots on that
> page, while interesting to practitioners of the art, aren't really
> suitable for general consumption overall. And since then,
> we have lots of other kool stuff (tm) we can showcase, up to
> and including LookingGlass and Croquet exploiting the new
> features.
>
> Thanks greatly!
> - Jim
>
>
>
>
> _______________________________________________
> xorg mailing list
Date: Thu Aug 12 16:46:31 2004
In-Reply-To: <1092350380.22268.7.camel@vertex>
<1092350380.22268.7.camel@vertex>
Message-ID: <ye8d61v7wds.fsf@horse08.daimi.au.dk>
John McCutchan <ttb@tentacle.dhs.org> writes:
> Both of those are bugs in mozilla and flash.
The one about crashing is; they should figure out a way to agree on
the visual used. But I'm not sure about the other. A client faced with
a 32 bit visual with 8 bits of r, g and b is not required to do
anything special with the remaining 8 bits, right? So the X server
suddenly assuming they are alpha bits is not backwards compatible.
> I think this comes down to who is the leader? X.org or macromedia (could
> be any program/company)?
>
> Who sets the rules?
How do you propose an application predicts that previously unused bits
are suddenly going to be interpreted as something the application has
never even heard about?
Soren
From ttb at tentacle.dhs.org Thu Aug 12 17:34:03 2004
From: ttb at tentacle.dhs.org (John McCutchan)
Date: Thu Aug 12 17:30:31 2004
In-Reply-To: <ye8d61v7wds.fsf@horse08.daimi.au.dk>
<1092350380.22268.7.camel@vertex> <ye8d61v7wds.fsf@horse08.daimi.au.dk>
Message-ID: <1092357243.22996.6.camel@vertex>
On Thu, 2004-08-12 at 19:46, Soeren Sandmann wrote:
> John McCutchan <ttb@tentacle.dhs.org> writes:
>
> > Both of those are bugs in mozilla and flash.
>
> The one about crashing is; they should figure out a way to agree on
> the visual used. But I'm not sure about the other. A client faced with
> a 32 bit visual with 8 bits of r, g and b is not required to do
> anything special with the remaining 8 bits, right? So the X server
> suddenly assuming they are alpha bits is not backwards compatible.
>
Of course its not backwards compatible. Like I said composite is
EXPERIMENTAL.. so users of it should expect things to not work
perfectly. Users *have to turn this on*, so it is not going to break
anyones desktop out of nowhere. Mozilla/Macromedia/Whoever should take
this time period to fix there apps to work with future versions of X
with the composite extension.
> > I think this comes down to who is the leader? X.org or macromedia (could
> > be any program/company)?
> >
> > Who sets the rules?
>
> How do you propose an application predicts that previously unused bits
> are suddenly going to be interpreted as something the application has
> never even heard about?
>
I don't. But they need to adapt to these changes. We shouldn't work
around there problems.
I would even go as far as to say that any app that doesn't get fixed
during the experimental phase of the composite extension should probably
be abandoned by it's users -- it is obviously unmaintained.
John
From Alan.Coopersmith at Sun.COM Thu Aug 12 17:30:44 2004
Date: Thu Aug 12 17:30:46 2004
Subject: [Xorg] Re: X.Org BUG REPORT: kenrel mode optimisations ?
In-Reply-To: <200408130019.BAA22124@xoneweb.opengroup.org>
References: <200408130019.BAA22124@xoneweb.opengroup.org>
Message-ID: <411C0BB4.5050902@Sun.COM>
Thierry Haven wrote:
> The main difference between the linux kernel and the windows kernel is that wi
ndows trades windows management in its own kernel directly. Maybe X.org should f
orget sometimes some client/server aspects and include some optimizations ? I th
ink linux could be much faster for a desktop use, or ?
Discussions like this are best held on a discussion list like
xorg@freedesktop.org, not mailed to the bug reporting address,
so I've cc'ed it there.
The obvious problems with putting it in the kernel are:
- reduces kernel stability - I believe those who've tried putting
window systems in the kernel before learned this the hard way.
- changes Xorg from a solution useful on many platforms
(Linux, BSD, Solaris, MacOS X, Cygwin, etc.) to one limited to Linux
--
From dominatus at gmail.com Thu Aug 12 19:47:29 2004
Date: Thu Aug 12 19:54:14 2004
Subject: [Xorg] Solicitation of screen shots of new facilities in
action...
In-Reply-To: <20040812221435.43fb9b74.diegocg@teleline.es>
<d3ca506904081212412a5d1d06@mail.gmail.com>
<20040812221435.43fb9b74.diegocg@teleline.es>
Message-ID: <d3ca50690408121947336c25df@mail.gmail.com>
niether of those shots are OS X. They are both Linux.
The dock is engage, in the E17 cvs. It performs even better than it looks.
Date: Thu Aug 12 20:12:31 2004
On Thu, Aug 12, 2004 at 11:03:36AM -0400, Jim Gettys wrote:
> Thanks greatly!
> - Jim
Hi Jim,
I am glad to share my screenshots, and please take a look over:
1. KDrive + Matchbox + Chinese Environment + gcin[1]
http://jserv.sayya.org/misc/matchbox-gcin.png
2. KDrive + Matchbox + GPE + Arphic Chinese fonts /
Taipei Chinese fonts
http://jserv.sayya.org/misc/matchbox-xcomposite4.png
Both are composite extension enabled with built-in manager of
Matchbox.
cheers,
Jim Huang
[1] A new Chinese input method for XIM
http://www.csie.nctu.edu.tw/~cp76/gcin/
From hiryu at audioseek.net Thu Aug 12 21:41:05 2004
From: hiryu at audioseek.net (Cameron)
Date: Thu Aug 12 21:54:16 2004
Subject: [Xorg] KDrive->bufio.h
Message-ID: <200408122141.05577.hiryu@audioseek.net>
I am unable to build kdrive due to a missing bufio.h, which doesn't appear to
exist on my system. I am unable to locate file anywhere on my system and gcc
certainly isn't able to:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include/X11/fonts -I../include
-I../include/X11/fonts
-DFONT_ENCODINGS_DIRECTORY=\"/opt/fdo/lib/X11/fonts/encodings/encodings.dir\"
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing -g -O2
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -I/opt/fdo/include
-I/opt/fdo/include/X11/Xtrans -MT bufio.lo -MD -MP -MF .deps/bufio.Tpo -c
bufio.c -fPIC -DPIC -o .libs/bufio.o
bufio.c:39:19: bufio.h: No such file or directory
Thanks!
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From kem at freedesktop.org Thu Aug 12 22:27:09 2004
Date: Thu Aug 12 22:27:14 2004
night.
listed below.
Fixed yesterday: 2
Added yesterday: 6
-----------------------------
* Bug #687: Matrox Mystique screen corruption
- Patch supplied
* Bug #770: Hangs with Chromium
- Keith Packard said he would talk with Thomas E. Dickey about using
his upstream xterm in this X.Org release
- Recent patches purport to fix this problem and have been checked in
- More testing is needed
- Roland Mainz suggests reverting behavior back to X11R6.6 version
- Review needed by Matthieu Herrb who made the post-R6.6 change
- He said he would check in a patch to disable the extra visuals in
the connection block ASAP so that testing can proceed
* Bug #1024: Japanese ctext conversion bug
* Bug #1029: Hard failure if socket directories cannot be chowned to root
* Bug #1032: Damage causes rootless XDarwin to crash
- Possible wrapper ordering issue
* Bug #1041: xf86RandRSetMode calls wrong EnableDisableFBAccess
- This patch looks okay and could be checked in
* Bug #1042: File INSTALL breaks make install on cygwin
- Suggested fix available
* Bug #1050: xrandr should set screen physical size to avoid incorrect dpi
- Patch supplied, just needs review
* Bug #1055: #define BuildXprint NO is broken
- Several patches suggested
- Needs further review
* Bug #1060: BuildXprintLib NO causes libXaw build to fail
- Features added to Xaw making Xprint library required
- Is this desirable?
* Bug #1062: HAVE_FT_BITMAP_SIZE_Y_PPEM is not defined
- Untested patch provided to define patch
- Needs review by someone familiar with Freetype
Date: Thu Aug 12 22:39:01 2004
Subject: [Xorg] KDrive->bufio.h
In-Reply-To: <200408122141.05577.hiryu@audioseek.net>
References: <200408122141.05577.hiryu@audioseek.net>
On Thu, Aug 12, 2004 at 09:41:05PM -0700, Cameron wrote:
> I am unable to build kdrive due to a missing bufio.h, which doesn't appear to
> exist on my system. I am unable to locate file anywhere on my system and gcc
> certainly isn't able to:
[...]
> bufio.c:39:19: bufio.h: No such file or directory
Try:
find -name 'bufio.h.in'
And
ln -s bufio.h.in bufio.h
In the above path. The trick works for me.
cheers,
Jim Huang
Date: Thu Aug 12 23:50:09 2004
<20040813052709.GA31427@kem.org>
Message-ID: <E1BvVt1-0001hc-4b@evo.keithp.com>
Around 1 o'clock on Aug 13, Kevin E Martin wrote:
> * Bug #991: Composite exposes extra visuals
> - Keith Packard is working on a solution
> - He said he would check in a patch to disable the extra visuals in
> the connection block ASAP so that testing can proceed
The cure was worse than the disease.
I now recommend exposing the visual in the core protocol and teaching the
(very few) applications which stumble upon it what to do.
Applications which just accidentally use this visual for windows will
work correctly as long as no compositing manager is actually running, and
if they allocate colors through the X server, they will even work with a
compositing manager running as long as the X server hands out pixels with
the alpha bits set to one; I've hacked the dix/colormap code to do just
that without also modifying the visual structure (it uses nplanes == 32)
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040812/4b9a2031/attach
ment.pgp
From de_lupus at pandora.be Fri Aug 13 02:42:08 2004
Date: Fri Aug 13 00:28:13 2004
In-Reply-To: <a728f9f90408120548707af770@mail.gmail.com>
<a728f9f90408120548707af770@mail.gmail.com>
Can you give me an automated xorg.conf file then?
So I can see how it looks like.
e:
> > but what do I have to enable to have things configured auto?
> >
>
> just plug in the monitor and assuming the video and monitor support
> DDC and you have a working X config, it should just work.
>
> Alex
>
> >
> >
> > On Thu, 2004-08-12 at 12:34, Alex Deucher wrote:
> > > On Thu, 12 Aug 2004 10:41:38 +0000, Kristof Vansant <de_lupus@pandora.be>
wrote:
> > > > Isn't there a way to have PNP monitor support without having to manual
> > > > edit xorg.conf or edit xorg.conf by a external program like kudzu.
> > > > What is needed to have some decent monitor detection?
> > >
> > > just about all current xorg video drivers support DDC so most monitors
> > > should work automagically.
> > >
> > > Alex
> > >
> > > >
> > > > --
> > > > lupusBE (Kristof Vansant Belgium
> > > >
> > --
> > lupusBE (Kristof Vansant Belgium
> >
> >
--
From nanouck.dely at wanadoo.fr Fri Aug 13 03:03:03 2004
From: nanouck.dely at wanadoo.fr (Nicolas DELY)
Date: Fri Aug 13 03:33:39 2004
Subject: [Xorg] keyboard questions
Message-ID: <411C91D7.30903@wanadoo.fr>
Hi,
I'm French student and new on this list.
I would like to know where I must looking for keyboard drivers:
most recent keyboards have multimedia keys and leds, unfortunately /xev/
doesn't allow to find all keycodes. For example, some keys have scancode
(detect with /showkey -s/) and no keycode so I can bind keycode on keys
with /setkeycodes /but result codes in X are unknow.
So, is there a way to find results in advance?
Moreover keys haven't sometimes no scancode for example on my laptop
(omnibook xe4500) but kernel modules allow to attribute the missing
scancode.
So, I would like to know how does it work? Does anyone know? And then
where can I find docs on keyboard drivers?
(my keyboards are hp internet keyboard 5183 and the other is an oem one
distributed by ldlc.com)
Thanks
Nanouck
From nanouck.dely at wanadoo.fr Fri Aug 13 03:07:38 2004
From: nanouck.dely at wanadoo.fr (Nicolas DELY)
Date: Fri Aug 13 03:46:40 2004
Subject: [Xorg] keyboard questions
Message-ID: <411C92EA.5080203@wanadoo.fr>
Hi,
I'm French student and new on this list.
I would like to know where I must looking for keyboard drivers:
most recent keyboards have multimedia keys and leds, unfortunately /xev/
doesn't allow to find all keycodes. For example, some keys have scancode
(detect with /showkey -s/) and no keycode so I can bind keycode on keys
with /setkeycodes /but result codes in X are unknow.
So, is there a way to find results in advance?
Moreover keys haven't sometimes no scancode for example on my laptop
(omnibook xe4500) but kernel modules allow to attribute the missing
scancode.
So, I would like to know how does it work? Does anyone know? And then
where can I find docs on keyboard drivers?
(my keyboards are hp internet keyboard 5183 and the other is an oem one
distributed by ldlc.com)
Thanks
Nanouck
From vrihad at softhome.net Fri Aug 13 04:28:55 2004
From: vrihad at softhome.net (Vrihad Shoonya)
Date: Fri Aug 13 04:50:41 2004
Subject: [Xorg] Newly built Xserver fails to init font path element
Message-ID: <3914.192.168.0.30.1092396535.squirrel@dev.datamax.co.in>
I compiled and installed kdrive based Xserver following
the instructions given in the following document.
http://www.freedesktop.org/Software/XserverInstallGuide
Now when I try to run
/usr/kdrive/bin/Xfbdev :0 -fp /usr/X11R6/lib/X11/fonts/misc,
I get an error saying "Could not init font path element
/usr/X11R6/lib/X11/fonts/misc, remoing from list!"
Then the program exits with an error message of failure to
find font 'fixed'. The server does not run without
-fp option either.
I have installed the kdrive in a non-standard location
/usr/kdrive. Also the fonts I am trying to use are from
XFree86 project. Is there any font package specific for
x.org project? Or is there a bug in latest CVS code of
kdrive based Xserver?
I am using gcc 3.2.3 on Linux 2.4.18.
Thanks in advance.
vrihad
From alan at lxorguk.ukuu.org.uk Fri Aug 13 04:39:47 2004
Date: Fri Aug 13 05:42:04 2004
On Gwe, 2004-08-13 at 06:27, Kevin E Martin wrote:
> * Bug #1029: Hard failure if socket directories cannot be chowned to root
> - This solution breaks on systems that do not have setuid
> - xfs uses xtrans also and since it is not setuid root, it cannot
> chown to root and bails
> - Proposed solutions:
> 1. Create a helper program that is setuid root to create dir, or
> 2. Revert the change back to X11R6.7 version
#1 doesn't help on fundamentally non setuid using systems (or AFS)
#2 doesn't fix the problem
A combination of #1 and a .cf configured policy is needed. The suid
helper itself is pretty trivial
#define FIXED_PATH wherever
int main(int argc, char *argv[])
{
exit(chown(FIXED_PATH, 0, 0) ? errno: 0);
}
(Avoid things like error messages because then you get into all
the close(1); close(2) type tricks with older systems)
Alan
Date: Fri Aug 13 06:24:42 2004
On Gwe, 2004-08-13 at 12:39, Alan Cox wrote:
> A combination of #1 and a .cf configured policy is needed. The suid
> helper itself is pretty trivial
>
> #define FIXED_PATH wherever
>
> int main(int argc, char *argv[])
> {
> exit(chown(FIXED_PATH, 0, 0) ? errno: 0);
> }
>
Ok turns out that can be tricked in some environments. I think we have
to fail hard and print a message clearly stating what the problem is and
how to fix it. I don't think you can do it securely because you
have to deal with an attacker creating symlinks.
Alan
Date: Fri Aug 13 06:30:52 2004
<a728f9f90408120548707af770@mail.gmail.com>
Message-ID: <a728f9f904081306304acc0ae1@mail.gmail.com>
On Fri, 13 Aug 2004 09:42:08 +0000, Kristof Vansant <de_lupus@pandora.be> wrote:
> Can you give me an automated xorg.conf file then?
> So I can see how it looks like.
your current config file should probably work fine. you just need the
minimum sections required to actually start the server. if both your
monitor and video card support DDC, it will validate the modes you
want to use and chose the best refresh rate automatically.
>
> > On Thu, 12 Aug 2004 14:58:48 +0000, Kristof Vansant <de_lupus@pandora.be> wr
ote:
> > > but what do I have to enable to have things configured auto?
> > >
> >
> > just plug in the monitor and assuming the video and monitor support
> > DDC and you have a working X config, it should just work.
> >
> > Alex
> >
> > >
> > >
> > > On Thu, 2004-08-12 at 12:34, Alex Deucher wrote:
> > > > On Thu, 12 Aug 2004 10:41:38 +0000, Kristof Vansant <de_lupus@pandora.be
> wrote:
> > > > > Isn't there a way to have PNP monitor support without having to manual
> > > > > edit xorg.conf or edit xorg.conf by a external program like kudzu.
> > > > > What is needed to have some decent monitor detection?
> > > >
> > > > just about all current xorg video drivers support DDC so most monitors
> > > > should work automagically.
> > > >
> > > > Alex
> > > >
> > > > >
> > > > > --
> > > > > lupusBE (Kristof Vansant Belgium
> > > > >
> > > --
> > > lupusBE (Kristof Vansant Belgium
> > >
> > >
> --
>
>
Date: Fri Aug 13 07:01:23 2004
In-Reply-To: <E1BvVt1-0001hc-4b@evo.keithp.com>
References: <20040813052709.GA31427@kem.org> <E1BvVt1-0001hc-4b@evo.keithp.com>
On Thu, Aug 12, 2004 at 11:49:58PM -0700, Keith Packard wrote:
>
> Around 1 o'clock on Aug 13, Kevin E Martin wrote:
>
> > * Bug #991: Composite exposes extra visuals
> > - Keith Packard is working on a solution
> > - He said he would check in a patch to disable the extra visuals in
> > the connection block ASAP so that testing can proceed
>
> The cure was worse than the disease.
>
> I now recommend exposing the visual in the core protocol and teaching the
> (very few) applications which stumble upon it what to do.
>
> Applications which just accidentally use this visual for windows will
> work correctly as long as no compositing manager is actually running, and
> if they allocate colors through the X server, they will even work with a
> compositing manager running as long as the X server hands out pixels with
> the alpha bits set to one; I've hacked the dix/colormap code to do just
> that without also modifying the visual structure (it uses nplanes == 32)
Sorry about that, I forgot to update this bug list entry last night with
the info from the e-mail thread yesterday.
One comment, on the release wranglers call Wedensday we talked about
going with another solution along the same lines as GLX's FBConfigs.
GLX's original solution did pretty much the same thing that you are
doing -- exposing extra visuals and confusing applications. With
FBConfigs, GLX was able to store extra information about particular
visuals (in their case, depth buffers, stencil buffers etc.). You could
do the same with Composite by creating a new "extended visual struct"
with any new extended visual info that you require. Then, you could
teach Render (and any other supporting libraries) about the "extended
visual struct". This is particularly useful if you plan to extend the
capabilities further. If, however, you will not need any further
extensions to the visual structure, then perhaps this is overkill.
In any case, since the Composite extension is disabled by default with
the understanding that interfaces and functionality might change in the
future, I think that the solution you proposed is fine for the current
release.
Date: Fri Aug 13 10:13:44 2004
Subject: [Xorg] Code freeze extension
On today's release wranglers call, we decided to move the code freeze
deadline until 11AM EDT, Monday 16 Aug 2004. This will allow several of
us to finish fixing the remaining bugs.
After the code freeze, the first release candidate tag will be made for
people to test against. The volunteers who signed up to build release
packages should plan to make new packages available after tree is
tagged.
We also decided that, after Monday's code freeze, nothing is to be
checked into the tree without the approval of the release manager (me).
All release blocker bug fixes that you want to have considered for this
release will need to be entered into bugzilla (with associated patch).
Date: Fri Aug 13 10:35:28 2004
In-Reply-To: <411CCCA8.50001@dsbox.com>
<411CCCA8.50001@dsbox.com>
Message-ID: <a728f9f90408131035fd4c03f@mail.gmail.com>
On Fri, 13 Aug 2004 10:14:00 -0400, Robert S. Kerr <rskerr@dsbox.com> wrote:
>
>
> Alex Deucher wrote:
>
> >I just finished the preliminary merge. It seems to work ok in limited
> >testing. for those interested the patch is here:
> >
> >http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
> >
> >the code still needs the "develdri" #ifdefs added. I'm not sure
> >exactly where those need to go off hand. also the savage dri is still
> >only in mesa.
> >At this point this can probably wait until after the next release for merging
.
> >
> >Alex
> >
> >
> >
> >
> I've downloaded the xorg CVS and your patch and after much gnashing of
> teeth have managed to get DRI working.
> glxinfo indicates 'direct rendering: Yes'
>
> So far everything seems to be working okay except for Xv and perhaps XvMC.
Yeah, Xv seems to have some issues at the moment (so does console
switch). I haven't had time to sort it out more. Has anyone tried
the savage driver from xorg without my patch? I curious to see how/if
Egbert's streams changes affected Xv. I haven't had time to try it
myself.
Alex
>
> My setup:
> FC2, Athlon XP 2400, Kernel 2.6.5.
> ProSavage DDR 266 (32MB Shared Memory)
> Shuttle SK41G, 512MB Ram, 180GB drive
>
> Prior to DRI
> glxgears got ~130-140 FPS
> mplayer plays good video with no frame drops
>
> After DRI
> glxgears got ~190-200 FPS (oh yeah!)
> mplayer plays with no frame drops using Xv, however the video is
> distorted. (more below) xine and ogle show a similar distortion pattern
> as mplayer when using Xv, so I'm pretty sure it is an Xv issue.
>
> Still working on getting XvMC to work with anything. Right mplayer
> won't start with the XvMC renderer.
>
> I don't know if the Xv issue is Savage driver related or not, but I'll
> report it here in hopes you have some idea.
> With Xv, the video is displayed properly if the rendering window is
> small (less than 719x404). In that size or smaller, the video is
> displayed perfectly. I can move the window around, move it partially
> off screen, etc. and the video stays correctly oriented etc.
>
> If I size the window larger than 709x398, then the images are distorted
> in an interesting manner. The right half of the image is rendered
> properly, but the left half is not. In fact the left half of the image
> appears to have interlaced lines, half of which display the correct
> line, and the other half displaying the lines from the right side of the
> screen. The result is a ghosting effect where you can see both the
> right and left halves of the image on the left side of the screen.
> Further strangeness appears if part of the window is offscreen. If the
> right side of the window is off screen, then no obvious ill effects are
> apparent. If the left side of the window is off screen, however, the
> distorted area moves more torwards the left of the rendering area.
> Eventually it covers the whole remaining visible portion of the window,
> at that point, there are large dead areas where rendering doesn't happen.
>
> Hope that isn't too confusing a description. I'll post more if I figure
> anything out.
>
> Rob Kerr
>
>
>
> >-------------------------------------------------------
> >This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> >one more big change to announce. We are now OSTG- Open Source Technology
> >Group. Come see the changes on the new OSTG site. www.ostg.com
> >--
> >_______________________________________________
> >Dri-devel mailing list
> >Dri-devel@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
> >
> >
>
>
>
>
From a.p.zijlstra at chello.nl Fri Aug 13 10:53:16 2004
From: a.p.zijlstra at chello.nl (Peter Zijlstra)
Date: Fri Aug 13 10:54:47 2004
Message-ID: <1092419596.6627.5.camel@twins>
On Thu, 2004-08-12 at 18:00 -0500, Ryan wrote:
> Here's one that looks deceptively good.
>
> http://ruinaudio.com/Xorg-xcompmgr.png
Thnx,
I did the xcompmng thing in there, however is it supposed to be so dog
slow, and that on a dual athlon 1400 with a radeon 9000 ?
It redraws the screen in 3 secs. I can see the horz scanline move down.
Sure the shadows with xcompmng -c look nice, but one just cannot move a
single window anymore.
config file attached.
Kind regards,
Peter Zijlstra
-------------- next part --------------
Section "ServerLayout"
Identifier "XFree86 Configured"
Screen 0 "Screen0" 0 0
# Screen 1 "Screen1" LeftOf "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
RgbPath "/usr/Xorg/lib/X11/rgb"
ModulePath "/usr/Xorg/lib/modules,/usr/Xorg/lib/modules/dri"
FontPath "/usr/Xorg/lib/X11/fonts/100dpi:unscaled"
FontPath "/usr/Xorg/lib/X11/fonts/75dpi:unscaled"
FontPath "/usr/Xorg/lib/X11/fonts/CID"
FontPath "/usr/Xorg/lib/X11/fonts/TTF"
FontPath "/usr/Xorg/lib/X11/fonts/Type1"
FontPath "/usr/Xorg/lib/X11/fonts/cyrillic"
FontPath "/usr/Xorg/lib/X11/fonts/encodings"
FontPath "/usr/Xorg/lib/X11/fonts/local"
FontPath "/usr/Xorg/lib/X11/fonts/misc"
FontPath "/usr/Xorg/lib/X11/fonts/util"
EndSection
Section "Module"
Load "GLcore"
Load "dbe"
Load "dri"
Load "extmod"
Load "glx"
Load "record"
Load "bitmap"
Load "type1"
Load "speedo"
Load "freetype"
Load "v4l"
EndSection
Section "ServerFlags"
# Option "Xinerama" "true"
Option "standby time" "20"
Option "suspend time" "0"
Option "off time" "60"
EndSection
Identifier "Keyboard0"
Driver "kbd"
EndSection
Identifier "Mouse0"
Driver "mouse"
# Option "Device" "/dev/misc/psaux"
# Option "Protocol" "NetScrollPS/2"
Option "Device" "/dev/mouse"
Option "Buttons" "7"
Option "ZAxisMapping" "4 5 6 7"
Option "Resolution" "2000"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "CTX"
ModelName "3680"
Option "DPMS"
# DisplaySize 325 245
HorizSync 27.0-107
VertRefresh 50.0-160.0
ModeLine "1600x1200" 229.35 1600 1672 2032 2176 1200 1202 1214 1240 #85Hz
# ModeLine "1600x1200" 232.04 1600 1672 2032 2176 1200 1202 1214 1240 #86Hz
EndSection
Section "Monitor"
VendorName "LG"
ModelName "915FT+"
Option "DPMS"
HorizSync 30.0-107.0
ModeLine "2048x1536" 355.64 2048 2144 2584 2736 1536 1546 1558 1600 #81H
z
ModeLine "1920x1440" 299.31 1920 2000 2400 2560 1440 1442 1454 1480 #79H
z
ModeLine "1840x1380" 246.51 1840 1920 2320 2480 1380 1382 1394 1420 #70H
z
ModeLine "1800x1350" 298.46 1800 1880 2280 2440 1350 1352 1364 1390 #88H
z
EndSection
Section "Monitor"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
Option "DPMS"
# DisplaySize 400 300
HorizSync 27.0-130.0
# Modeline "2048x1536" 360.00 2048 2064 2544 2856 1536 1536 1557 1605 +hsy
nc +vsync # 78Hz
# ModeLine "2048x1536" 355.64 2048 2136 2576 2752 1536 1538 1550 1576 #82Hz
ModeLine "2048x1536" 355.64 2048 2144 2584 2736 1536 1546 1558 1600 #81Hz
ModeLine "1920x1440" 299.31 1920 2000 2400 2560 1440 1442 1454 1480 #79H
z
EndSection
Section "Device"
Option "AGPMode" "2"
Option "AGPFastWrite" "off"
Option "EnablePageFlip" "on"
# Option "MonitorLayout" "CRT,TMDS"
Identifier "Card1"
Driver "ati"
VendorName "Ati"
BoardName "Radeon 9000"
BusID "PCI:1:5:0"
Screen 1
EndSection
EndSection
Section "Device"
Option "AGPFastWrite" "off"
# Option "EnablePageFlip" "on"
# Option "MonitorLayout" "CRT,CRT"
# Option "IgnoreEDID" "on"
# Option "NoDCC" "on"
# Option "DCCMode" "on"
Option "MergedFB" "on"
# Option "MergedFBAuto" "on"
Option "CRT2Position" "LeftOf"
Option "MergedDPI" "75 75"
Option "CRT2HSync" "27-130"
Option "CRT2VRefresh" "50-160"
Option "MetaModes" "1600x1200-2048x1536 1600x1200-1600x1200"
Option "AsymetricPan" "off"
Identifier "Card0"
Driver "ati"
VendorName "Ati"
BoardName "Radeon 9000"
BusID "PCI:1:5:0"
Screen 0
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor2"
DefaultColorDepth 24
DefaultFbBpp 32
SubSection "Display"
Depth 16
Modes "2048x1536" "1920x1440" "1800x1350" "1600x1200" "128
0x1024" "1152x864"
Modes "1024x768" "800x600" "640x480"
EndSubSection
Depth 24
Modes "2048x1536" "1920x1440" "1800x1350" "1600x1200" "128
0x1024" "1152x864"
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "Screen"
Device "Card1"
Monitor "Monitor1"
DefaultColorDepth 24
DefaultFbBpp 32
Depth 16
Modes "2048x1536" "1920x1440" "1600x1200" "1280x1024" "115
2x864"
Modes "1024x768" "800x600" "640x480"
EndSubSection
Depth 24
Modes "2048x1536" "1920x1440" "1600x1200" "1280x1024" "115
2x864"
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "DRI"
Mode 0666
EndSection
From brian.paul at tungstengraphics.com Fri Aug 13 11:23:46 2004
From: brian.paul at tungstengraphics.com (Brian Paul)
Date: Fri Aug 13 11:20:50 2004
In-Reply-To: <20040813171337.GB7758@kem.org>
Message-ID: <411D0732.5070507@tungstengraphics.com>
Kevin E Martin wrote:
> On today's release wranglers call, we decided to move the code freeze
> deadline until 11AM EDT, Monday 16 Aug 2004. This will allow several of
> us to finish fixing the remaining bugs.
>
> After the code freeze, the first release candidate tag will be made for
> people to test against. The volunteers who signed up to build release
> packages should plan to make new packages available after tree is
> tagged.
>
> We also decided that, after Monday's code freeze, nothing is to be
> checked into the tree without the approval of the release manager (me).
> All release blocker bug fixes that you want to have considered for this
> release will need to be entered into bugzilla (with associated patch).
I've been kind of out of touch with DRI / X development lately, but it
looks like the current Mesa CVS trunk and the DRI tree's DRM modules
will be going into this release. Is that correct?
The Mesa CVS trunk doesn't constitute a normal Mesa release yet. I
was planning on eventually wrapping up the trunk as the 6.1
(development) release. The last Mesa stable release was 6.0.1 and bug
fixes relative to it are on the mesa_6_0_branch branch in CVS. I
don't think any of the DRI driver developers have been putting
anything into that branch though.
That said, I _think_ the Mesa CVS trunk is fairly stable code at this
point. Perhaps I should make the 6.1 release ASAP, just so things are
somewhat synchronized. Comments?
-Brian
Date: Fri Aug 13 12:27:18 2004
In-Reply-To: <1092419596.6627.5.camel@twins>
<1092419596.6627.5.camel@twins>
No, it shouldn't be dog slow.
Without seeing your log file, it is hard to know what is
going on.
- Jim
On Fri, 2004-08-13 at 13:53, Peter Zijlstra wrote:
> On Thu, 2004-08-12 at 18:00 -0500, Ryan wrote:
> > Here's one that looks deceptively good.
> >
> > http://ruinaudio.com/Xorg-xcompmgr.png
>
> Thnx,
>
> I did the xcompmng thing in there, however is it supposed to be so dog
> slow, and that on a dual athlon 1400 with a radeon 9000 ?
>
> It redraws the screen in 3 secs. I can see the horz scanline move down.
> Sure the shadows with xcompmng -c look nice, but one just cannot move a
> single window anymore.
>
> config file attached.
>
> Kind regards,
>
> Peter Zijlstra
>
> ______________________________________________________________________
> _______________________________________________
> xorg mailing list
From a.p.zijlstra at chello.nl Fri Aug 13 13:29:25 2004
Date: Fri Aug 13 13:29:35 2004
<1092419596.6627.5.camel@twins>
On Fri, 2004-08-13 at 15:26 -0400, Jim Gettys wrote:
> No, it shouldn't be dog slow.
>
Thats a relief.
> Without seeing your log file, it is hard to know what is
> going on.
Sure, here goes. Thanks for the effort.
Peter Zijlstra
>
> On Fri, 2004-08-13 at 13:53, Peter Zijlstra wrote:
> > On Thu, 2004-08-12 at 18:00 -0500, Ryan wrote:
> > > Here's one that looks deceptively good.
> > >
> > > http://ruinaudio.com/Xorg-xcompmgr.png
> >
> > Thnx,
> >
> > I did the xcompmng thing in there, however is it supposed to be so dog
> > slow, and that on a dual athlon 1400 with a radeon 9000 ?
> >
> > It redraws the screen in 3 secs. I can see the horz scanline move down.
> > Sure the shadows with xcompmng -c look nice, but one just cannot move a
> > single window anymore.
> >
> > config file attached.
> >
> > Kind regards,
> >
> > Peter Zijlstra
> >
> > ______________________________________________________________________
> > _______________________________________________
> > xorg mailing list
> > xorg@freedesktop.org
> > http://freedesktop.org/mailman/listinfo/xorg
>
--
Peter Zijlstra <a.p.zijlstra@chello.nl>
-------------- next part --------------
Name: Xorg.4.log.gz
Type: application/x-gzip
Size: 11379 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040813/5575473c/Xorg.4
.log.bin
From mcnichol at austin.ibm.com Fri Aug 13 13:04:12 2004
Date: Fri Aug 13 14:17:38 2004
Subject: [Xorg] Problem building fontconfig on AIX.
Message-ID: <200408132004.PAA11826@xanth.austin.ibm.com>
When running make World on AIX I get this error:
making all in lib/fontconfig...
Target "all" is up to date.
rm -f fontconfig-def.cpp
MAJ=èxpr "" : "$[^\.]*$\..*"`; MIN=èxpr "" : "[^\.]*\.$[^\.]*$\.*
.*"` || true; TEEN=èxpr "" : "[^\.]*\.[^\.]*\.*$.*$"` || true; CUR=LT_CURRENT
=èxpr $MAJ + $MIN`; REV=LT_REVISION=$TEEN; sh ./config-subst $CUR $REV < fontco
nfig.def.in > fontconfig-def.cpp
make: The error code from the last command is 1.
The problem seems to be that the variable SOFONTCONFIGREV in the Makefile is und
efined.
Where is this value supposed to come from?
Dan
Date: Fri Aug 13 14:35:40 2004
In-Reply-To: Your message of "Fri, 13 Aug 2004 15:04:12 CDT."
<200408132004.PAA11826@xanth.austin.ibm.com>
Message-ID: <E1Bvjhw-0005ke-DD@evo.keithp.com>
Around 15 o'clock on Aug 13, mcnichol@austin.ibm.com wrote:
> making all in lib/fontconfig...
> Target "all" is up to date.
Fontconfig is imported into the X.org tree and has to be manuall converted
from autotools to imake each time. I suspect this conversion is broken on
AIX. Would you give the original fontconfig package a spin and use
#define HasFontconfig YES in your host.def?
It may be that we can simply require fontconfig to be pre-installed on AIX
systems (not ideal, but it would be nice to know what our options are).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040813/4ab827fa/attach
ment.pgp
From Markus.Kuhn at cl.cam.ac.uk Fri Aug 13 15:04:14 2004
Date: Fri Aug 13 15:04:20 2004
Subject: [Xorg] Installing as non-root user
<E1Bvjhw-0005ke-DD@evo.keithp.com>
Message-ID: <E1Bvk9m-00060Z-00@mta1.cl.cam.ac.uk>
Is there a simple/neat way (e.g., setting a small number of environment
variables) to "make install" X11R6.7 from the cvs tree as a non-root user into
my home directory (say in ~/local/X11R6/ instead of /usr/X11R6/), to do
development work and testing on the client-side of X11R6 without changing
anything outside my home directory?
xc/BUILD only says
If you want to install on a filesystem other than /usr, make a
symbolic link to /usr/X11R6 before installing.
which is of no help to someone who works on a centrally administered
host and has not the root access needed to replace /usr/X11R6 with a
symbolic link.
A brief description of how to do that would be a most valueable addition
to xc/BUILD. [On many other source packages, one simply has to execute
"./configure -prefix=$HOME/local" today, to install without root access.]
Markus
--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Date: Fri Aug 13 15:04:25 2004
Message-ID: <200408132204.RAA29584@xanth.austin.ibm.com>
I was afraid of that.
Actually I have an RPM of Fontconfig 2.2.2 available. I had put off using
it bacause it used Freetype2 2.1.7. But I believe that should be ok to use
now since I think the Freetype2 problem was fixed.
Thanks
Dan
> From keithp@keithp.com Fri Aug 13 16:35:39 2004
>
>
> Around 15 o'clock on Aug 13, mcnichol@austin.ibm.com wrote:
>
> > making all in lib/fontconfig...
> > Target "all" is up to date.
>
> Fontconfig is imported into the X.org tree and has to be manuall converted
> from autotools to imake each time. I suspect this conversion is broken on
> AIX. Would you give the original fontconfig package a spin and use
> #define HasFontconfig YES in your host.def?
>
> It may be that we can simply require fontconfig to be pre-installed on AIX
> systems (not ideal, but it would be nice to know what our options are).
>
> -keith
>
>
>
Date: Fri Aug 13 15:13:16 2004
In-Reply-To: <E1Bvk9m-00060Z-00@mta1.cl.cam.ac.uk>
References: <E1Bvk9m-00060Z-00@mta1.cl.cam.ac.uk>
Message-ID: <411D3CF9.5040204@Sun.COM>
When we build for making Solaris packages, we use this in host.def
to install to a staging area in the top of the build tree:
/* Install into package building area */
PWD:sh=pwd
#ifdef i386Architecture
DESTDIR=$(PWD)/$(TOP)/../proto-i386-svr4
#else
DESTDIR=$(PWD)/$(TOP)/../proto-sun4-svr4
#endif
The :sh= syntax is specific to the Sun version of make I think though - there's
probably a gmake equivalent, and if you just want to hardcode a directory, such
as /home/markus instead, you should just be able to ignore the PWD and set
DESTDIR directly.
You're right that this should be documented somewhere in the build instructions.
--
Markus Kuhn wrote:
> Is there a simple/neat way (e.g., setting a small number of environment
> variables) to "make install" X11R6.7 from the cvs tree as a non-root user into
> my home directory (say in ~/local/X11R6/ instead of /usr/X11R6/), to do
> development work and testing on the client-side of X11R6 without changing
> anything outside my home directory?
>
> xc/BUILD only says
>
> If you want to install on a filesystem other than /usr, make a
> symbolic link to /usr/X11R6 before installing.
>
> which is of no help to someone who works on a centrally administered
> host and has not the root access needed to replace /usr/X11R6 with a
> symbolic link.
>
> A brief description of how to do that would be a most valueable addition
> to xc/BUILD. [On many other source packages, one simply has to execute
> "./configure -prefix=$HOME/local" today, to install without root access.]
>
> Markus
>
From eta at lclark.edu Fri Aug 13 15:24:47 2004
Date: Fri Aug 13 15:24:52 2004
<1092419596.6627.5.camel@twins>
On Fri, 2004-08-13 at 12:26, Jim Gettys wrote:
Well, it shouldn't, if you have an acceleration architecture that's had
much work done, or been designed, to support Render with it. XAA
doesn't fall under that category. XAA doesn't accelerate untransformed
non-repeating source copies with the source in framebuffer (well,
actually *anything* with source in framebuffer), which is what you'll be
doing frequently with xcompmgr, and I believe with automatic updates as
well. We could fix this easily by adding code to XAA's Composite
function to check for that case and use the normal 2D acceleration, but
we don't yet. If we had got things up and running faster than we did, I
would have tried to finish up the bit of code I have to do this and push
it in, but there have been plenty of other things to work on.
As it is, a normal window update, with the window in offscreen pixmap
cache will involve normal acceleration into the backing pixmap in
framebuffer. Damage reports that, and xcompmgr copies in software to
its backbuffer (since it's this unaccelerated operation). Since the
backbuffer is probably in framebuffer as well, you then have to copy in
software from framebuffer to frontbuffer. Ouch. You actually will
likely get better performance after you use it for a while and XAA's
offscreen memory management results in a window or backbuffer pixmap
being kicked out of framebuffer for the rest of its life as new pixmaps
come in (except, of course, if those new pixmaps are also windows, in
which case you get the same pain in a new location).
My comments on XAA are as I understand things from reading the code as
best I could, and anecdotal evidence. I'd be happy to find out that the
situation is better, but I highly doubt it.
My plan is to do a lot of work on KAA this fall in the area of offscreen
memory management and accelerating Render trapezoids, and to work on
integrating what results from that into X.Org for the next release if
possible, while retaining XAA for non-updated drivers.
--
From ajax at nwnk.net Fri Aug 13 15:22:18 2004
Date: Fri Aug 13 15:29:15 2004
In-Reply-To: <E1Bvk9m-00060Z-00@mta1.cl.cam.ac.uk>
Hash: SHA1
On Friday 13 August 2004 18:04, Markus Kuhn wrote:
> variables) to "make install" X11R6.7 from the cvs tree as a non-root user
> into my home directory (say in ~/local/X11R6/ instead of /usr/X11R6/), to
> do development work and testing on the client-side of X11R6 without
> changing anything outside my home directory?
In host.def:
#define ProjectRoot /home/foo/X11R6
#define NothingOutsideProjectRoot YES
make World and make install like normal. If you want to run the server, chown
it to root and chmod it 4711.
Add /home/foo/X11R6/lib to LD_LIBRARY_PATH and /home/foo/X11R6/bin to PATH to
use the newly-installed libraries and programs.
- - ajax
iD8DBQFBHT8jW4otUKDs0NMRAoBjAKDpX/bf92U2MiROLAaeyNXI72WqowCgqPZa
mKFh69dVbmJZyAbvJTqjjSI=
=fqW+
From s864 at ii.uib.no Fri Aug 13 15:25:50 2004
From: s864 at ii.uib.no (Ronny V. Vindenes)
Date: Fri Aug 13 15:42:39 2004
<1092419596.6627.5.camel@twins>
Message-ID: <1092435950.21500.7.camel@tentacle125.gozu.lan>
fre, 13,.08.2004 kl. 15.26 -0400, skrev Jim Gettys:
I see the same thing here with athlon64 3200+ and ati 9000, but ONLY
with some gtk themes. If I use plain themes like Simple, it's sluggish
but tolerable, however if I use themes like my own Glacier it's
completely unusable with more than one or two windows and there's
rendering errors all over the place (i.e. widgets and/or whole windows
only draw the background color or pixmap).
--
Ronny V. Vindenes <s864@ii.uib.no>
From Markus.Kuhn at cl.cam.ac.uk Fri Aug 13 15:45:01 2004
Date: Fri Aug 13 15:45:08 2004
<411D3CF9.5040204@Sun.COM>
Message-ID: <E1BvknG-0006Xr-00@mta1.cl.cam.ac.uk>
Alan Coopersmith wrote on 2004-08-13 22:13 UTC:
> you should just be able to ignore the PWD and set
> DESTDIR directly.
Thanks. Installing with
$ DESTDIR=~/local make install
and then testing clients and libraries with
$ LD_LIBRARY_PATH=~/local/usr/X11R6/lib/ ~/local/usr/X11R6/bin/xev
seems to have much of the desired effect. However,
$ LD_LIBRARY_PATH=/home/mgk25/w.xorg/install/usr/X11R6/lib/ \
strace /home/mgk25/w.xorg/install/usr/X11R6/bin/xev 2>&1 | grep open
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory
)
open("/home/mgk25/w.xorg/install/usr/X11R6/lib/i686/sse2/libX11.so.6", O_RDONL
Y) = -1 ENOENT (No such file or directory)
open("/home/mgk25/w.xorg/install/usr/X11R6/lib/i686/libX11.so.6", O_RDONLY) =
-1 ENOENT (No such file or directory)
[...]
open("/usr/X11R6/lib/X11/locale/compose.dir", O_RDONLY) = 5
open("/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 5
open("/usr/X11R6/lib/X11/XKeysymDB", O_RDONLY) = 6
shows that the binaries still know very much that they were meant to
refer to config files under /usr/X11R6/. So I guess, one will also have
to set PROJECTROOT and perhaps a number of other environment/make
variables (INCROOT, USRLIBDIR, MANPATH, VARDIR, VARLIBDIR, ...?) to really
*fully* detach a test installation from anything in /usr/X11R6/. May be,
the /usr/X11R6/ (or root) could be factored out of the definition of
these other variables slightly better in xc/xmakefile.
> You're right that this should be documented somewhere in the build instruction
s.
That would be wonderful.
Markus
--
Date: Fri Aug 13 15:45:43 2004
In-Reply-To: <411D0732.5070507@tungstengraphics.com>
<411D0732.5070507@tungstengraphics.com>
On Fri, 2004-08-13 at 11:23, Brian Paul wrote:
> Kevin E Martin wrote:
> > On today's release wranglers call, we decided to move the code freeze
> > deadline until 11AM EDT, Monday 16 Aug 2004. This will allow several of
> > us to finish fixing the remaining bugs.
> >
> > After the code freeze, the first release candidate tag will be made for
> > people to test against. The volunteers who signed up to build release
> > packages should plan to make new packages available after tree is
> > tagged.
> >
> > We also decided that, after Monday's code freeze, nothing is to be
> > checked into the tree without the approval of the release manager (me).
> > All release blocker bug fixes that you want to have considered for this
> > release will need to be entered into bugzilla (with associated patch).
>
> I've been kind of out of touch with DRI / X development lately, but it
> looks like the current Mesa CVS trunk and the DRI tree's DRM modules
> will be going into this release. Is that correct?
>
> The Mesa CVS trunk doesn't constitute a normal Mesa release yet. I
> was planning on eventually wrapping up the trunk as the 6.1
> (development) release. The last Mesa stable release was 6.0.1 and bug
> fixes relative to it are on the mesa_6_0_branch branch in CVS. I
> don't think any of the DRI driver developers have been putting
> anything into that branch though.
>
> That said, I _think_ the Mesa CVS trunk is fairly stable code at this
> point. Perhaps I should make the 6.1 release ASAP, just so things are
> somewhat synchronized. Comments?
At this point, given that the X.Org tree is still monolithic, our Mesa
usage is somewhat independent of Mesa releases in my view. I chose to
integrate the development branch because of the great advances made in
the DRI drivers in general (though we have some issues to resolve still,
as bugzilla shows), though I was concerned about using something that
wasn't blessed as a release.
I would like to continue using the current codebase, though we should
probably make it clear in glxinfo (for example) that this is a
development branch we're using. That is, unless a release were to
happen from the head branch the next couple of days.
--
Date: Fri Aug 13 15:49:39 2004
In-Reply-To: <E1BvknG-0006Xr-00@mta1.cl.cam.ac.uk>
References: <E1BvknG-0006Xr-00@mta1.cl.cam.ac.uk>
Message-ID: <411D457F.9030203@Sun.COM>
Right - DESTDIR just redirects the installation, but it still expects
to end up in ProjectRoot.
-alan-
Markus Kuhn wrote:
> Alan Coopersmith wrote on 2004-08-13 22:13 UTC:
>
>>you should just be able to ignore the PWD and set
>>DESTDIR directly.
>
>
> Thanks. Installing with
>
> $ DESTDIR=~/local make install
>
> and then testing clients and libraries with
>
> $ LD_LIBRARY_PATH=~/local/usr/X11R6/lib/ ~/local/usr/X11R6/bin/xev
>
> seems to have much of the desired effect. However,
>
> $ LD_LIBRARY_PATH=/home/mgk25/w.xorg/install/usr/X11R6/lib/ \
> strace /home/mgk25/w.xorg/install/usr/X11R6/bin/xev 2>&1 | grep open
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directo
ry)
> open("/home/mgk25/w.xorg/install/usr/X11R6/lib/i686/sse2/libX11.so.6", O_RDO
NLY) = -1 ENOENT (No such file or directory)
> open("/home/mgk25/w.xorg/install/usr/X11R6/lib/i686/libX11.so.6", O_RDONLY)
= -1 ENOENT (No such file or directory)
> [...]
> open("/usr/X11R6/lib/X11/locale/compose.dir", O_RDONLY) = 5
> open("/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 5
> open("/usr/X11R6/lib/X11/XKeysymDB", O_RDONLY) = 6
>
> shows that the binaries still know very much that they were meant to
> refer to config files under /usr/X11R6/. So I guess, one will also have
> to set PROJECTROOT and perhaps a number of other environment/make
> variables (INCROOT, USRLIBDIR, MANPATH, VARDIR, VARLIBDIR, ...?) to really
> *fully* detach a test installation from anything in /usr/X11R6/. May be,
> the /usr/X11R6/ (or root) could be factored out of the definition of
> these other variables slightly better in xc/xmakefile.
>
>
>>You're right that this should be documented somewhere in the build instruction
s.
>
>
> That would be wonderful.
>
> Markus
>
--
From brian.paul at tungstengraphics.com Fri Aug 13 16:02:13 2004
Date: Fri Aug 13 15:59:13 2004
Subject: [Mesa3d-dev] Re: [Xorg] Code freeze extension
<1092437137.1072.110.camel@leguin>
Message-ID: <411D4875.5050901@tungstengraphics.com>
Eric Anholt wrote:
> On Fri, 2004-08-13 at 11:23, Brian Paul wrote:
>
>>Kevin E Martin wrote:
>>
>>>On today's release wranglers call, we decided to move the code freeze
>>>deadline until 11AM EDT, Monday 16 Aug 2004. This will allow several of
>>>us to finish fixing the remaining bugs.
>>>
>>>After the code freeze, the first release candidate tag will be made for
>>>people to test against. The volunteers who signed up to build release
>>>packages should plan to make new packages available after tree is
>>>tagged.
>>>
>>>We also decided that, after Monday's code freeze, nothing is to be
>>>checked into the tree without the approval of the release manager (me).
>>>All release blocker bug fixes that you want to have considered for this
>>>release will need to be entered into bugzilla (with associated patch).
>>
>>I've been kind of out of touch with DRI / X development lately, but it
>>looks like the current Mesa CVS trunk and the DRI tree's DRM modules
>>will be going into this release. Is that correct?
>>
>>The Mesa CVS trunk doesn't constitute a normal Mesa release yet. I
>>was planning on eventually wrapping up the trunk as the 6.1
>>(development) release. The last Mesa stable release was 6.0.1 and bug
>>fixes relative to it are on the mesa_6_0_branch branch in CVS. I
>>don't think any of the DRI driver developers have been putting
>>anything into that branch though.
>>
>>That said, I _think_ the Mesa CVS trunk is fairly stable code at this
>>point. Perhaps I should make the 6.1 release ASAP, just so things are
>>somewhat synchronized. Comments?
>
>
> At this point, given that the X.Org tree is still monolithic, our Mesa
> usage is somewhat independent of Mesa releases in my view. I chose to
> integrate the development branch because of the great advances made in
> the DRI drivers in general (though we have some issues to resolve still,
> as bugzilla shows), though I was concerned about using something that
> wasn't blessed as a release.
>
> I would like to continue using the current codebase, though we should
> probably make it clear in glxinfo (for example) that this is a
> development branch we're using. That is, unless a release were to
> happen from the head branch the next couple of days.
Well, I could probably make the Mesa 6.1 release this weekend (since I
was planning on working anyway). I've got some memory leak fixes (see
bug 1002030) that I haven't checked into the trunk yet (but are
checked into the mesa_6_0_branch branch). I asked Kevin about
checking them in but haven't heard back yet.
Does anyone object to taking the trunk code we have today and making
the 6.1 release? I'm not aware of any loose ends in it at this time.
-Brian
Date: Fri Aug 13 16:31:58 2004
In-Reply-To: Your message of "Fri, 13 Aug 2004 23:04:14 BST."
<E1Bvk9m-00060Z-00@mta1.cl.cam.ac.uk>
Message-ID: <E1BvlWH-0005oQ-Qi@evo.keithp.com>
Around 23 o'clock on Aug 13, Markus Kuhn wrote:
> variables) to "make install" X11R6.7 from the cvs tree as a non-root user into
> my home directory (say in ~/local/X11R6/ instead of /usr/X11R6/), to do
> development work and testing on the client-side of X11R6 without changing
> anything outside my home directory?
In my config/cf/host.def file, I have:
#define ProjectRoot /home/keithp/X11/Xorg
#define NothingOutsideProjectRoot YES
This *should* work, although xprint has some nagging problems (which only
encouraged me to also add #define BuildXprint NO...)
Then use LD_LIBRARY_PATH=/home/keithp/X11/Xorg/lib and apps run fine.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040813/1a043e88/attach
ment-0001.pgp
Date: Fri Aug 13 16:35:12 2004
In-Reply-To: <E1BvlWH-0005oQ-Qi@evo.keithp.com>
<E1BvlWH-0005oQ-Qi@evo.keithp.com>
On Fri, Aug 13, 2004 at 04:31:33PM -0700, Keith Packard wrote:
>
> Around 23 o'clock on Aug 13, Markus Kuhn wrote:
>
> > Is there a simple/neat way (e.g., setting a small number of environment
> > variables) to "make install" X11R6.7 from the cvs tree as a non-root user in
to
> > my home directory (say in ~/local/X11R6/ instead of /usr/X11R6/), to do
> > development work and testing on the client-side of X11R6 without changing
> > anything outside my home directory?
>
> In my config/cf/host.def file, I have:
>
> #define ProjectRoot /home/keithp/X11/Xorg
> #define NothingOutsideProjectRoot YES
>
> This *should* work, although xprint has some nagging problems (which only
> encouraged me to also add #define BuildXprint NO...)
Thankfully, those install problems have now been fixed in CVS.
> Then use LD_LIBRARY_PATH=/home/keithp/X11/Xorg/lib and apps run fine.
That's what I do as well.
From ryan.gallagher at comcast.net Fri Aug 13 19:27:41 2004
Date: Fri Aug 13 19:27:07 2004
In-Reply-To: <1092435950.21500.7.camel@tentacle125.gozu.lan>
<1092419596.6627.5.camel@twins>
<1092435950.21500.7.camel@tentacle125.gozu.lan>
Hi,
Although the original screen shot is "legit" not doctored in any way, I
labeled it "deceptively good" because when running xcompmgr xorg is
utterly useless. :-) Widgets, window contents, text, etc, don't draw
correctly, performance is... well the word "performance" isn't really
applicable.
No offense meant to those busting their backs here, you rawk, I just
didn't want to leave a bunch of people heart-broken asking; "why doesn't
my x look like his x".
To further elucidate I'm running;
P4 2.4ghz
ati radeon 9000 (mobile) 64mb
648mb system ram
X Protocol Version 11, Revision 0, Release 6.7.99.2 (Friday 13th cvs)
Btw, thanks to all the developers.
-ry
On Sat, 2004-08-14 at 00:25 +0200, Ronny V. Vindenes wrote:
> fre, 13,.08.2004 kl. 15.26 -0400, skrev Jim Gettys:
> > No, it shouldn't be dog slow.
>
> I see the same thing here with athlon64 3200+ and ati 9000, but ONLY
> with some gtk themes. If I use plain themes like Simple, it's sluggish
> but tolerable, however if I use themes like my own Glacier it's
> completely unusable with more than one or two windows and there's
> rendering errors all over the place (i.e. widgets and/or whole windows
> only draw the background color or pixmap).
>
Date: Fri Aug 13 19:37:08 2004
<1092419596.6627.5.camel@twins>
Could you disable Xinerma temporarily on your system and
see if things behave better? As Eric pointed out, we don't
have the hooks to "do the right thing" decently with multiscreen
systems.
- Jim
On Fri, 2004-08-13 at 22:27, Ryan wrote:
> Hi,
>
> Although the original screen shot is "legit" not doctored in any way, I
> labeled it "deceptively good" because when running xcompmgr xorg is
> utterly useless. :-) Widgets, window contents, text, etc, don't draw
> correctly, performance is... well the word "performance" isn't really
> applicable.
>
> No offense meant to those busting their backs here, you rawk, I just
> didn't want to leave a bunch of people heart-broken asking; "why doesn't
> my x look like his x".
>
> To further elucidate I'm running;
>
> P4 2.4ghz
> ati radeon 9000 (mobile) 64mb
> 648mb system ram
> X Protocol Version 11, Revision 0, Release 6.7.99.2 (Friday 13th cvs)
>
> Btw, thanks to all the developers.
>
> -ry
>
> On Sat, 2004-08-14 at 00:25 +0200, Ronny V. Vindenes wrote:
> > fre, 13,.08.2004 kl. 15.26 -0400, skrev Jim Gettys:
> > > No, it shouldn't be dog slow.
> >
> > I see the same thing here with athlon64 3200+ and ati 9000, but ONLY
> > with some gtk themes. If I use plain themes like Simple, it's sluggish
> > but tolerable, however if I use themes like my own Glacier it's
> > completely unusable with more than one or two windows and there's
> > rendering errors all over the place (i.e. widgets and/or whole windows
> > only draw the background color or pixmap).
> >
>
> _______________________________________________
> xorg mailing list
From ryan.gallagher at comcast.net Fri Aug 13 19:41:18 2004
Date: Fri Aug 13 19:40:42 2004
<1092419596.6627.5.camel@twins>
hmm... conflicting initials...
I'm not running Xinerama though my xorg.conf looks quite different from
Ronny's, see attached.
-ryanpg
On Fri, 2004-08-13 at 22:36 -0400, Jim Gettys wrote:
> Could you disable Xinerma temporarily on your system and
> see if things behave better? As Eric pointed out, we don't
> have the hooks to "do the right thing" decently with multiscreen
> systems.
> - Jim
>
> On Fri, 2004-08-13 at 22:27, Ryan wrote:
> > Hi,
> >
> > Although the original screen shot is "legit" not doctored in any way, I
> > labeled it "deceptively good" because when running xcompmgr xorg is
> > utterly useless. :-) Widgets, window contents, text, etc, don't draw
> > correctly, performance is... well the word "performance" isn't really
> > applicable.
> >
> > No offense meant to those busting their backs here, you rawk, I just
> > didn't want to leave a bunch of people heart-broken asking; "why doesn't
> > my x look like his x".
> >
> > To further elucidate I'm running;
> >
> > P4 2.4ghz
> > ati radeon 9000 (mobile) 64mb
> > 648mb system ram
> > X Protocol Version 11, Revision 0, Release 6.7.99.2 (Friday 13th cvs)
> >
> > Btw, thanks to all the developers.
> >
> > -ry
> >
> > On Sat, 2004-08-14 at 00:25 +0200, Ronny V. Vindenes wrote:
> > > fre, 13,.08.2004 kl. 15.26 -0400, skrev Jim Gettys:
> > > > No, it shouldn't be dog slow.
> > >
> > > I see the same thing here with athlon64 3200+ and ati 9000, but ONLY
> > > with some gtk themes. If I use plain themes like Simple, it's sluggish
> > > but tolerable, however if I use themes like my own Glacier it's
> > > completely unusable with more than one or two windows and there's
> > > rendering errors all over the place (i.e. widgets and/or whole windows
> > > only draw the background color or pixmap).
> > >
> >
> > _______________________________________________
>
-------------- next part --------------
Section "Files"
RgbPath "/opt/Xorg-6.8.0/lib/X11/rgb"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/misc/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/TTF/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/Type1/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/CID/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/75dpi/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/100dpi/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/local/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/Speedo/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/TrueType/"
FontPath "/opt/Xorg-6.8.0/lib/X11/fonts/freefont/"
# ModulePath "/opt/Xorg-6.8.0/lib/modules"
EndSection
Section "Module"
Load "dbe" # Double buffer extension
SubSection "extmod"
Option "omit xfree86-dga" # don't initialise the DGA extension
EndSubSection
Load "type1"
Load "speedo"
Load "freetype"
# Load "xtt"
Load "glx"
Load "dri"
EndSection
EndSection
Section "ServerFlags"
# Option "NoTrapSignals"
# Option "DontVTSwitch"
# Option "DontZap"
# Option "Dont Zoom"
# Option "DisableVidModeExtension"
# Option "AllowNonLocalXvidtune"
# Option "DisableModInDev"
# Option "AllowNonLocalModInDev"
EndSection
Driver "kbd"
Option "AutoRepeat" "500 30"
Option "XkbModel" "pc101"
Option "XkbLayout" "us"
EndSection
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "PS/2"
EndSection
Section "Monitor"
Identifier "My Monitor"
HorizSync 31.5 - 48.5
VertRefresh 50-70
Option "dpms"
EndSection
Section "Device"
Identifier "** ATI Radeon (generic) [radeon]"
Driver "radeon"
#VideoRam 65536
Option "RenderAccel" "On"
Option "AGPFastWrite" "On"
Option "EnablePageFlip" "On"
Option "BackingStore" "On"
EndSection
Section "Screen"
Identifier "Screen 1"
Device "** ATI Radeon (generic) [radeon]"
Monitor "My Monitor"
DefaultDepth 24
Subsection "Display"
Depth 8
Modes "1024x768"
ViewPort 0 0
EndSubsection
Depth 16
Modes "1024x768"
ViewPort 0 0
EndSubsection
Depth 24
Modes "1024x768"
ViewPort 0 0
EndSubsection
EndSection
# The Identifier line must be present
Identifier "Simple Layout"
# Each Screen line specifies a Screen section name, and optionally
# the relative position of other screens. The four names after
# primary screen name are the screens to the top, bottom, left and right
# of the primary screen. In this example, screen 2 is located to the
# right of screen 1.
Screen "Screen 1"
# Each InputDevice line specifies an InputDevice section name and
# optionally some options to specify the way the device is to be
# used. Those options include "CorePointer", "CoreKeyboard" and
# "SendCoreEvents".
EndSection
Section "DRI"
Mode 0666
EndSection
Date: Fri Aug 13 22:31:35 2004
night.
listed below.
Fixed yesterday: 10
Added yesterday: 6
-----------------------------
- I have been unable to reproduce this with current CVS
- Patch applied; leaving open to see if better solution is found
- Keith Packard has checked in his solution and documented the problem
with Flash
- A patch to Xlib to hide all depth 32 visuals in XOpenDisplay has
also been proposed
- Main blocker problem has been solved but there is still another
problem which will be investigated later
* Bug #1044: Server crash when resizing window while running xcompmgr
- Crash reproduced
- Investigation needed
* Bug #1057: GLX looks for DRI drivers in wrong dir on AMD64
- Proposed fix is being tested and will be checked in after
confirmation that it works
- Decided to revert to previous behavior
- Patch supplied, but needs review
* Bug #1065: Test and enable Render accel on R100
- Tests succeeded, but may not have been testing required code paths
- More specific test info is needed to exercise the part of the code
that was previously known to cause problems
* Bug #1070: Old keyboard driver needs to be enabled on certain platforms
- Patch provided to enable deprecated keyboard driver on those
platforms that have not implemented support for new kbd driver
* Bug #1072: Auto load old keyboard driver if kbd driver fails to load
- Patch is needed to fallback to old deprecated keyboard driver when
loading of new kbd driver fails
Date: Fri Aug 13 22:42:51 2004
In-Reply-To: <20040814053131.GC21571@kem.org>
References: <20040814053131.GC21571@kem.org>
On Fri, 2004-08-13 at 22:31, Kevin E Martin wrote:
> * Bug #1065: Test and enable Render accel on R100
> - Tests succeeded, but may not have been testing required code paths
> - More specific test info is needed to exercise the part of the code
> that was previously known to cause problems
Sorry for not getting back to you on this one. The specific case that
I've heard concerns about with R100 is running some quake3 while doing
text things, but there were some doubts about that report. (ls -lR ~
has been effective for me as the "doing text things" in the past). I'm
not expecting hangs on r100, though that would certainly be interesting,
but watch for visual glitches. A textured game like chromium or
tuxracer should also suffice.
--
From s864 at ii.uib.no Sat Aug 14 02:14:11 2004
Date: Sat Aug 14 02:14:21 2004
<1092419596.6627.5.camel@twins>
fre, 13,.08.2004 kl. 21.41 -0500, skrev Ryan:
> hmm... conflicting initials...
>
> I'm not running Xinerama though my xorg.conf looks quite different from
> Ronny's, see attached.
>
I'm not running xinerama either, that was Peter Zijlstra.
Here's my xorg.conf and I've also put up some screenshots[?] with and
without xcompmgr running, notice how parts of the gnome panel blanks out
- I see this at random places and times, like in evolution one of the
drop menus appear blank while the rest are correct.
[?] http://www.lstud.ii.uib.no/~s864/screenshots/
--
-------------- next part --------------
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
EndSection
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
ModulePath "/usr/X11R6/lib64/modules"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
FontPath "/usr/X11R6/lib/X11/fonts/TTF/"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
FontPath "/usr/X11R6/lib/X11/fonts/CID/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
EndSection
Section "Module"
Load "vnc"
Load "extmod"
Load "glx"
Load "dri"
Load "dbe"
Load "record"
Load "xtrap"
Load "freetype"
Load "speedo"
Load "type1"
#Load "freetype"
EndSection
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "no"
EndSection
Identifier "Mouse0"
Driver "mouse"
EndSection
Section "Monitor"
#DisplaySize 340 270 # mm
#HorizSync 30.0 - 81.0
#HorizSync 14387.0 - 0.0
#VertRefresh 56.0 - 0.0
VendorName "SAM"
ModelName "SyncMaster"
Option "DPMS"
EndSection
Section "Device"
### Available Driver options are:-
### Values: : integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "Dac6Bit" # [<bool>]
#Option "Dac8Bit" # [<bool>]
#Option "BusType" # [<str>]
#Option "CPPIOMode" # [<bool>]
#Option "CPusecTimeout" # 
#Option "AGPFastWrite" # [<bool>]
Option "AGPSize" "64" # 
Option "GARTSize" "64" # 
#Option "RingSize" # 
#Option "BufferSize" # 
Option "EnableDepthMoves" "true" # [<bool>]
#Option "NoBackBuffer" # [<bool>]
#Option "PanelOff" # [<bool>]
#Option "DDCMode" # [<bool>]
#Option "MonitorLayout" # [<str>]
#Option "IgnoreEDID" # [<bool>]
#Option "UseFBDev" # [<bool>]
#Option "VideoKey" # 
#Option "MergedFB" # [<bool>]
#Option "CRT2HSync" # [<str>]
#Option "CRT2VRefresh" # [<str>]
#Option "CRT2Position" # [<str>]
#Option "MetaModes" # [<str>]
#Option "MergedDPI" # [<str>]
#Option "NoMergedXinerama" # [<bool>]
#Option "MergedXineramaCRT2IsScreen0" # [<bool>]
#Option "DisplayPriority" # [<str>]
#Option "PanelSize" # [<str>]
Option "RenderAccel" "true"
Identifier "Card0"
Driver "radeon"
VendorName "ATI Technologies Inc"
BoardName "Radeon R250 If [Radeon 9000]"
Option "AGPMode" "4" # 
Option "EnablePageFlip" "true" # [<bool>]
BusID "PCI:1:0:0"
EndSection
Section "Screen"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
Viewport 0 0
Depth 1
EndSubSection
Viewport 0 0
Depth 4
EndSubSection
Viewport 0 0
Depth 8
EndSubSection
Viewport 0 0
Depth 15
EndSubSection
Viewport 0 0
Depth 16
EndSubSection
Viewport 0 0
Depth 24
EndSubSection
EndSection
Section "DRI"
Mode 0666
EndSection
Option "XEVIE" "Enable"
EndSection
Date: Sat Aug 14 04:17:07 2004
References: <1092323016.3250.107.camel@localhost.localdomain> <1092351642.3103
.0.camel@localhost.localdomain> <1092419596.6627.5.camel@twins> <1092425214.3491
.104.camel@localhost.localdomain> <1092435950.21500.7.camel@tentacle125.go
zu.lan> <1092450461.8147.10.camel@localhost.localdomain> <1092451003.3418
.45.camel@localhost.localdomain> <1092451278.8147.12.camel@localhost.loca
ldomain>
Message-ID: <411DF4D2.6010605@winischhofer.net>
Ronny V. Vindenes wrote:
> fre, 13,.08.2004 kl. 21.41 -0500, skrev Ryan:
>
>>hmm... conflicting initials...
>>
>>I'm not running Xinerama though my xorg.conf looks quite different from
>>Ronny's, see attached.
>>
>
>
> I'm not running xinerama either, that was Peter Zijlstra.
>
> Here's my xorg.conf and I've also put up some screenshots[?] with and
> without xcompmgr running, notice how parts of the gnome panel blanks out
> - I see this at random places and times, like in evolution one of the
> drop menus appear blank while the rest are correct.
Lucky you. KDE's kicker crashes X (sig 11) reliably over here when
xcompmgr is running... (X.org CVS as of yesterday). Window borders are
not correctly redrawn, and many other KDE programs (such as KSnapshot)
send me out to the console as well (sig 11).
Thomas
--
Thomas Winischhofer
Vienna/Austria
From de_lupus at pandora.be Sat Aug 14 06:40:10 2004
Date: Sat Aug 14 04:26:09 2004
Subject: [Xorg] can't xorg detect on bootup which gfx card is installed?
can't xorg detect on bootup which gfx card is installed?
so saying in the xorg.conf which driver is needed is not needed anymore.
Or include a programme in xorg that can detect this.
So all distro's have the same program for this.
--
From diegocg at teleline.es Sat Aug 14 05:01:50 2004
From: diegocg at teleline.es (Diego Calleja =?ISO-8859-15?Q?Garc=EDa?=)
Date: Sat Aug 14 05:13:01 2004
Message-ID: <20040814140150.3733ac93.diegocg@teleline.es>
El Sat, 14 Aug 2004 13:40:10 +0000 Kristof Vansant <de_lupus@pandora.be> escribi
?:
> can't xorg detect on bootup which gfx card is installed?
> so saying in the xorg.conf which driver is needed is not needed anymore.
> Or include a programme in xorg that can detect this.
> So all distro's have the same program for this.
Try "Xorg -configure" as root.
Date: Sat Aug 14 05:48:10 2004
In-Reply-To: <20040814140150.3733ac93.diegocg@teleline.es>
<20040814140150.3733ac93.diegocg@teleline.es>
why not do detection as normal user and ask for root password when new
hardware is found?
On Sat, 2004-08-14 at 12:01, Diego Calleja Garc?a wrote:
> El Sat, 14 Aug 2004 13:40:10 +0000 Kristof Vansant <de_lupus@pandora.be> escri
bi?:
>
> > can't xorg detect on bootup which gfx card is installed?
> > so saying in the xorg.conf which driver is needed is not needed anymore.
> > Or include a programme in xorg that can detect this.
> > So all distro's have the same program for this.
>
>
> Try "Xorg -configure" as root.
--
Date: Sat Aug 14 06:15:53 2004
Subject: [Xorg] why is Option "ZAxisMapping" "4 5" needed for my scrollmouse
to work
Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
Can't there be some detection for this or just enabled by default?
--
Date: Sat Aug 14 06:18:00 2004
Subject: [Xorg] AllocateOffscreenLinear
Message-ID: <411E112A.5020201@winischhofer.net>
Both the radeon and the mga driver allocate offscreen memory for RENDER
acceleration using xf86AllocateOffscreenLinear(). However, the "size"
argument for this call is calculated differently:
The mga driver's RENDER acceleration calculates the "size" argument like
this (simplified):
size = width * height
if (pScrn->bitsPerPixel == 16) size <<= 1;
The radeon driver does this like this:
size = width * PICT_FORMAT_BPP(texFormat) * height
Both the mga and the radeon drivers' video code allocates offscreen
video memory calculating "size" like this:
size = (width * height) / (pScrn->bitsPerPixel >> 3)
So, what IS the unit of "size" for xf86AllocateOffscreenLinear()?
"pixel" (=bpp-dependent) or "byte"?
If it's "pixel", the radeon driver's RENDER acceleration is broken in
this regard.
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Sat Aug 14 07:26:34 2004
Subject: [Xorg] AllocateOffscreenLinear
In-Reply-To: <411E112A.5020201@winischhofer.net>
References: <411E112A.5020201@winischhofer.net>
Message-ID: <411E211C.2020500@winischhofer.net>
>
> Both the radeon and the mga driver allocate offscreen memory for RENDER
> acceleration using xf86AllocateOffscreenLinear(). However, the "size"
> argument for this call is calculated differently:
>
> The mga driver's RENDER acceleration calculates the "size" argument like
> this (simplified):
>
> size = width * height
> if (pScrn->bitsPerPixel == 16) size <<= 1;
>
> The radeon driver does this like this:
>
> size = width * PICT_FORMAT_BPP(texFormat) * height
>
> Both the mga and the radeon drivers' video code allocates offscreen
> video memory calculating "size" like this:
>
> size = (width * height) / (pScrn->bitsPerPixel >> 3)
>
> So, what IS the unit of "size" for xf86AllocateOffscreenLinear()?
> "pixel" (=bpp-dependent) or "byte"?
>
> If it's "pixel", the radeon driver's RENDER acceleration is broken in
> this regard.
Answering to my own posting: Size is in PIXELS. This means that the
radeon driver's RENDER acceleration does not allocate the correct amount
of memory as it only bases its calculation on the source bitmap's format
but not the current screen layout's depth. That should probably be
something in the line of:
dst_pitch = (width * tex_bytepp + 31) & ~31;
size = dst_pitch * height;
+ sbpp = pScrn->bitsPerPixel >> 3;
- if (!AllocateLinear(pScrn, size))
+ if (!AllocateLinear(pScrn, (size + sbpp - 1) / sbpp))
return FALSE;
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Sat Aug 14 07:52:44 2004
Subject: [Xorg] Depth 8 - sig 11/4
Message-ID: <411E274C.20904@winischhofer.net>
Starting X.org (CVS as of yesterday) with DefaultDepth 8 leads to a sig
11 followed by a sig 4 here.
Composite is enabled.
Can anyone confirm this?
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Sat Aug 14 07:58:48 2004
Subject: [Xorg] Depth 8 - sig 11/4
In-Reply-To: <411E274C.20904@winischhofer.net>
References: <411E274C.20904@winischhofer.net>
Message-ID: <411E28C5.20202@winischhofer.net>
>
> Starting X.org (CVS as of yesterday) with DefaultDepth 8 leads to a sig
> 11 followed by a sig 4 here.
... when logging out.
>
> Composite is enabled.
>
> Can anyone confirm this?
>
> Thomas
>
--
Thomas Winischhofer
Vienna/Austria
From Jim.Gettys at hp.com Sat Aug 14 09:04:22 2004
Date: Sat Aug 14 09:04:47 2004
Subject: [Xorg] why is Option "ZAxisMapping" "4 5" needed for my
scrollmouse to work
Good question...
I've wondered this myself.
Is there any reason this can't be the default behavior,
and only have to mess around if you don't want scroll behavior?
- Jim
On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
> Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
> Can't there be some detection for this or just enabled by default?
From krh at bitplanet.net Sat Aug 14 09:14:57 2004
Date: Sat Aug 14 09:17:13 2004
Subject: [Xorg] why is Option "ZAxisMapping" "4 5" needed for
my scrollmouse to work
Message-ID: <411E3A81.1020805@bitplanet.net>
Jim Gettys wrote:
> Good question...
>
> I've wondered this myself.
>
> Is there any reason this can't be the default behavior,
> and only have to mess around if you don't want scroll behavior?
> - Jim
None that I know of.
Kristian
> On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
>
>>Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
>>Can't there be some detection for this or just enabled by default?
Date: Sat Aug 14 09:42:54 2004
On Sad, 2004-08-14 at 15:36, Kristof Vansant wrote:
> why not do detection as normal user and ask for root password when new
> hardware is found?
For some parts of card detection you need to be root to bash I/O ports
and investigate the hardware. Vendors generally do display configuration
during boot up using other tools so the end user never has to think
about that issue.
Alan
From keithp at keithp.com Sat Aug 14 09:52:56 2004
Date: Sat Aug 14 09:53:10 2004
action...
Message-ID: <E1Bw1m4-0006MX-Ub@evo.keithp.com>
Around 11 o'clock on Aug 14, "Ronny V. Vindenes" wrote:
> notice how parts of the gnome panel blanks out
> - I see this at random places and times
I fixed a bug that did this when using Composite last night.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
ment.pgp
From morphie at unravel-music.nl Sat Aug 14 09:45:38 2004
From: morphie at unravel-music.nl (Dennie Bastiaan)
Date: Sat Aug 14 10:12:36 2004
Subject: [Xorg] xcompmgr aborts immediately
Message-ID: <200408141845.38097.morphie@unravel-music.nl>
I have problems with the xcompmgr. I updated my X.org installation from CVS
today (so I am running 6.7.99.2) and I also updated xcompmgr. When I run
xcompmgr the following happens.
The screen refreshes (very slowly, even though XAA and DRI are enabled), the
eye-candy works, but some fonts go blank and after it is refreshed it aborts
like this:
dennie@neo:/opt/Xorg-6.7.99.1/bin$ xcompmgr -c
error 9 request 158 minor 1 serial 2618
Aborted
Where the serial is a random number.
Here's a shot of what happens:
http://www.si.hhs.nl/~20033874/screens/xorg-xcompmgr.png
I am running Debian Unstable with linux 2.6.7. In Xorg.0.log it also states
that the Composite extension is enabled.
Does anyone have any ideas on what could be the problem?
- Dennie
Date: Sat Aug 14 10:28:27 2004
References: <20040814053131.GC21571@kem.org> <1092462164.906.10.camel@leguin>
Message-ID: <a728f9f9040814102840dce15@mail.gmail.com>
On Fri, 13 Aug 2004 22:42:45 -0700, Eric Anholt <eta@lclark.edu> wrote:
> On Fri, 2004-08-13 at 22:31, Kevin E Martin wrote:
> > * Bug #1065: Test and enable Render accel on R100
> > - Tests succeeded, but may not have been testing required code paths
> > - More specific test info is needed to exercise the part of the code
> > that was previously known to cause problems
>
> Sorry for not getting back to you on this one. The specific case that
> I've heard concerns about with R100 is running some quake3 while doing
> text things, but there were some doubts about that report. (ls -lR ~
> has been effective for me as the "doing text things" in the past). I'm
> not expecting hangs on r100, though that would certainly be interesting,
> but watch for visual glitches. A textured game like chromium or
> tuxracer should also suffice.
Also it looks like we are allocating memory wrong for render. See
Thomas' email.
Alex
>
> --
> Eric Anholt eta@lclark.edu
> http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
>
>
From ftigeot at wolfpond.org Sat Aug 14 10:04:07 2004
From: ftigeot at wolfpond.org (Francois Tigeot)
Date: Sat Aug 14 10:35:27 2004
Subject: [Xorg] IP addresses in font path
Message-ID: <20040814170407.GA11388@aoi.wolfpond.org>
I'm trying to use a font server by way of its IP address, and the X server
seems to interpret it as an host name.
This is a part of my /etc/X11/xorg.conf:
Section "Files"
FontPath "tcp/192.168.2.101"
EndSection
I get the following error messages on the console (recopied by hand, may
not be accurate):
_FontTransOpen: Unable to parse address tcp/192.168.2.101
Could not init font path element, removing from list!
Is this a normal behaviour ?
And fwiw, the reason I want to use an IP address directly is that the dhcp
option "font-servers" is a list of IP addresses, not host names...
--
Francois Tigeot
From s864 at ii.uib.no Sat Aug 14 11:10:09 2004
Date: Sat Aug 14 11:10:19 2004
In-Reply-To: <E1Bw1m4-0006MX-Ub@evo.keithp.com>
References: <E1Bw1m4-0006MX-Ub@evo.keithp.com>
l?r, 14,.08.2004 kl. 09.52 -0700, skrev Keith Packard:
> Around 11 o'clock on Aug 14, "Ronny V. Vindenes" wrote:
>
> > notice how parts of the gnome panel blanks out
> > - I see this at random places and times
>
> I fixed a bug that did this when using Composite last night.
>
I still see it with cvs from today
--
Date: Sat Aug 14 11:14:53 2004
<20040814170407.GA11388@aoi.wolfpond.org>
Message-ID: <E1Bw33D-0006TZ-8D@evo.keithp.com>
Around 19 o'clock on Aug 14, Francois Tigeot wrote:
> FontPath "tcp/192.168.2.101"
Doesn't the path have to contain the port number too?
tcp/192.168.2.101:7100
(or whatever port your font server listens on).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040814/35ded9b2/attach
ment.pgp
Date: Sat Aug 14 11:21:50 2004
In-Reply-To: <200408141845.38097.morphie@unravel-music.nl>
References: <200408141845.38097.morphie@unravel-music.nl>
Message-ID: <20040814202147.70f42fc2.diegocg@teleline.es>
El Sat, 14 Aug 2004 18:45:38 +0200 Dennie Bastiaan <morphie@unravel-music.nl> es
cribi?:
> I am running Debian Unstable with linux 2.6.7. In Xorg.0.log it also states
> that the Composite extension is enabled.
I'm using current 2.6 and debian unstable and I happen to have a
similar problem; in my case I don't see an abort but a core dump,
and it crashes just after starting it.
I wonder if this problem is related with our setups (debian unstable + kernel
2.6) or one of the other bugs reported (mine is at
http://freedesktop.org/bugzilla/show_bug.cgi?id=1074)
From ftigeot at wolfpond.org Sat Aug 14 11:31:38 2004
Date: Sat Aug 14 11:31:43 2004
In-Reply-To: <E1Bw33D-0006TZ-8D@evo.keithp.com>
References: <20040814170407.GA11388@aoi.wolfpond.org>
<E1Bw33D-0006TZ-8D@evo.keithp.com>
On Sat, Aug 14, 2004 at 11:14:42AM -0700, Keith Packard wrote:
>
> Around 19 o'clock on Aug 14, Francois Tigeot wrote:
>
> > FontPath "tcp/192.168.2.101"
>
> Doesn't the path have to contain the port number too?
>
> tcp/192.168.2.101:7100
>
> (or whatever port your font server listens on).
You're right. For some reason, I believed the port part wasn't necessary
when reading xorg.conf(5).
I now have a fully working X-terminal :)
Sorry about that.
--
Francois Tigeot
From ryan.gallagher at comcast.net Sat Aug 14 11:34:08 2004
Date: Sat Aug 14 11:38:34 2004
On Sat, 2004-08-14 at 20:10 +0200, Ronny V. Vindenes wrote:
> l?r, 14,.08.2004 kl. 09.52 -0700, skrev Keith Packard:
> > Around 11 o'clock on Aug 14, "Ronny V. Vindenes" wrote:
> >
> > > notice how parts of the gnome panel blanks out
> > > - I see this at random places and times
> >
> > I fixed a bug that did this when using Composite last night.
> >
>
> I still see it with cvs from today
>
Not me, things are drawing really nicely, metacity, gnome and gnome-
panel and any gtk apps I've run do anyway. Some other toolkits still
don't draw right though. Running the program Audacity (fltk audio
editor) reveals some glitches in menu items.
The only profound visual issue for me is broken scrolling in evolution
firefox (scrolling in gedit and gnome-terminal is fine). Composite is
still prohibitively slow. Interestingly running skippy-xd (expose clone
using composite et. al.) is also dog slow. This confirms the issue to
be in xaa and composite not xcompmgr itself?
-ry
Date: Sat Aug 14 13:39:06 2004
action...
In-Reply-To: Your message of "Sat, 14 Aug 2004 13:34:08 CDT."
Message-ID: <E1Bw5Ie-0006Wx-1V@evo.keithp.com>
Around 13 o'clock on Aug 14, Ryan wrote:
> The only profound visual issue for me is broken scrolling in evolution
> firefox (scrolling in gedit and gnome-terminal is fine)
That should be fixed as of about 20 minutes ago.
> Interestingly running skippy-xd (expose clone
> using composite et. al.) is also dog slow. This confirms the issue to
> be in xaa and composite not xcompmgr itself?
if skippy-xd is shrinking windows, it will remain dog-slow for this
release. Accelerating transformations ain't gonna happen...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040814/e5682c29/attach
ment.pgp
Date: Sat Aug 14 15:21:11 2004
In-Reply-To: <20040814202147.70f42fc2.diegocg@teleline.es>
<20040814202147.70f42fc2.diegocg@teleline.es>
Message-ID: <20040815002110.1b2863c8.diegocg@teleline.es>
El Sat, 14 Aug 2004 20:21:47 +0200 Diego Calleja Garc?a <diegocg@teleline.es> es
cribi?:
> El Sat, 14 Aug 2004 18:45:38 +0200 Dennie Bastiaan <morphie@unravel-music.nl>
escribi?:
>
> > I am running Debian Unstable with linux 2.6.7. In Xorg.0.log it also states
> > that the Composite extension is enabled.
>
> I'm using current 2.6 and debian unstable and I happen to have a
> similar problem; in my case I don't see an abort but a core dump,
> and it crashes just after starting it.
>
> I wonder if this problem is related with our setups (debian unstable + kernel
> 2.6) or one of the other bugs reported (mine is at
> http://freedesktop.org/bugzilla/show_bug.cgi?id=1074)
Just wanted to notice that xcompmgr has stopped crashing. (see the bug)
Have you tried the latest cvs?
Date: Sat Aug 14 15:34:49 2004
scrollmouse to work
Message-ID: <411E938B.8030608@sun.com>
I've also wondered that - so much that for the builds I do for Sun
for our own internal testing, I set it by default. (Unfortunately,
it's just in the Sun mouse support code right now - to do it for
real would be finding the right place in the os-independent mouse
code, so my patch won't help there.)
-alan-
Jim Gettys wrote:
> Good question...
>
> I've wondered this myself.
>
> Is there any reason this can't be the default behavior,
> and only have to mess around if you don't want scroll behavior?
> - Jim
>
> On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
>
>>Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
>>Can't there be some detection for this or just enabled by default?
>
>
> _______________________________________________
> xorg mailing list
--
Date: Sat Aug 14 15:44:23 2004
<1092419596.6627.5.camel@twins>
Message-ID: <20040815004108.35e82811.diegocg@teleline.es>
El Fri, 13 Aug 2004 22:36:44 -0400 Jim Gettys <Jim.Gettys@hp.com> escribi?:
A screenshot showing xcompmgr working and the gnome resolution switcher
http://www.terra.es/personal/diegocg/xorg-composite.png
From rene at rocklinux-consulting.de Sat Aug 14 16:27:52 2004
From: rene at rocklinux-consulting.de (=?ISO-8859-1?Q?Ren=E9_Rebe?=)
Date: Sat Aug 14 17:06:15 2004
Subject: [Xorg] X.org radeon hangs on startup (PowerPC/iBook2)
Message-ID: <411E9FF8.30004@rocklinux-consulting.de>
Hi all,
I just tried cvs:head on my iBook2 (Radeon Mobility M7 LW [Radeon
Mobility 7500]) and had to notice that it already hangs during startup:
This is a pre-release version of the The X.Org Foundation X11.
Portions of this release are based on XFree86 4.4RC2 and selected
files from XFree86 4.4RC3. It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the The X.Org Foundation "monolithic tree" CVS
repository hosted at http://www.freedesktop.org/Software/xorg/.99
Release Date: 12 August 2004
X Protocol Version 11, Revision 0, Release 6.7.99.2
Build Operating System: Linux 2.6.8 ppc [ELF]
Current Operating System: Linux localhost 2.6.8 #1 Sat Aug 14 13:49:21
CEST 2004 ppc
Build Date: 14 August 2004
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 14 20:14:21 2004
(==) Using config file: "/etc/X11/XF86Config"
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen1" (0)
(**) | |-->Monitor "Monitor1"
(**) | |-->Device "Card1"
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard1"
(**) Option "AutoRepeat" "250 30"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "macintosh"
(**) XKB: model: "macintosh"
(**) Option "XkbLayout" "de_ibook"
(**) XKB: layout: "de_ibook"
(==) Keyboard: CustomKeycode disabled
(WW) The directory "/usr/X11R6/lib/X11/fonts/PEX/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/latin2/" does not exist.
(WW) The directory "/usr/X11R6/lib/X11/fonts/sharefont" does not exist.
(**) FontPath set to
"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unsca
led,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/li
b/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/cyrillic/,/usr/X11R6/lib/X11/fonts/e
ncodings/,/usr/X11R6/lib/X11/fonts/freefont/,/usr/X11R6/lib/X11/fonts/local/,/us
r/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TrueType,/usr/share/ghostsc
ript/fonts/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(II) Open APM successful
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.2
X.Org Video Driver: 0.7
X.Org XInput driver : 0.4
X.Org Server Extension : 0.2
X.Org Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
compiled for 6.7.99.2, module version = 1.0.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
ABI class: X.Org Video Driver, version 0.7
(--) using VT number 7
(WW) xf86OpenConsole: Could not save ownership of VT
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:0b:0: chip 106b,0027 card 0000,0000 rev 00 class 06,00,00
hdr 00
(II) PCI: 00:10:0: chip 1002,4c57 card 1002,4c57 rev 00 class 03,00,00
hdr 00
hdr 00
(II) PCI: 01:17:0: chip 106b,0025 card 0000,0000 rev 00 class ff,00,00
hdr 00
(II) PCI: 01:18:0: chip 106b,0026 card 0000,0000 rev 00 class 0c,03,10
hdr 00
(II) PCI: 01:19:0: chip 106b,0026 card 0000,0000 rev 00 class 0c,03,10
hdr 00
hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:11:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1 0 0x00000000 - 0x00ffffff (0x1000000) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0x00ffffff (0x1000000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0x00ffffff (0x1000000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(--) PCI:*(0:16:0) ATI Technologies Inc Radeon Mobility M7 LW [Radeon
Mobility 7500] rev 0, Mem @ 0x98000000/27, 0x90000000/16, I/O @
0x0400/8, BIOS @ 0xf1000000/17
(II) Addressable bus resource ranges are
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x00ffffff (0x1000000) IX[B]
(II) OS-reported resource ranges:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]
[2] -1 0 0x00ffffff - 0x00ffffff (0x1) IX[B]
[3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
(II) Active PCI resource ranges:
[0] -1 0 0x80080000 - 0x80080fff (0x1000) MX[B]
[1] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B]
[2] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B]
[3] -1 0 0xf1000000 - 0xf101ffff (0x20000) MX[B](B)
[4] -1 0 0x90000000 - 0x9000ffff (0x10000) MX[B](B)
[5] -1 0 0x98000000 - 0x9fffffff (0x8000000) MX[B](B)
[6] -1 0 0x00000400 - 0x000004ff (0x100) IX[B](B)
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0 0x80080000 - 0x80080fff (0x1000) MX[B]
[1] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B]
[2] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B]
[3] -1 0 0xf1000000 - 0xf101ffff (0x20000) MX[B](B)
[4] -1 0 0x90000000 - 0x9000ffff (0x10000) MX[B](B)
[5] -1 0 0x98000000 - 0x9fffffff (0x8000000) MX[B](B)
[6] -1 0 0x00000400 - 0x000004ff (0x100) IX[B](B)
(II) OS-reported resource ranges after removing overlaps with PCI:
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]
[3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
(II) All system resource ranges:
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]
[2] -1 0 0x80080000 - 0x80080fff (0x1000) MX[B]
[3] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B]
[4] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B]
[5] -1 0 0xf1000000 - 0xf101ffff (0x20000) MX[B](B)
[6] -1 0 0x90000000 - 0x9000ffff (0x10000) MX[B](B)
[7] -1 0 0x98000000 - 0x9fffffff (0x8000000) MX[B](B)
[9] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[10] -1 0 0x00000400 - 0x000004ff (0x100) IX[B](B)
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="X.Org Foundation"
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "ddc"
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="X.Org Foundation"
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="X.Org Foundation"
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="X.Org Foundation"
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
(II) Loading font FreeType
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
(II) Loading extension GLX
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
(II) Loading extension XFree86-DRI
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="X.Org Foundation"
Module class: X.Org Video Driver
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.4
(II) ATI: ATI driver (version 6.5.6) for chipset: ati
(II) R128: Driver for ATI Rage 128 chipsets:
ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP),
ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP),
ATI Rage 128 Pro GL PA (PCI/AGP), ATI Rage 128 Pro GL PB (PCI/AGP),
ATI Rage 128 Pro GL PC (PCI/AGP), ATI Rage 128 Pro GL PD (PCI),
ATI Rage 128 Pro GL PE (PCI/AGP), ATI Rage 128 Pro GL PF (AGP),
ATI Rage 128 Pro VR PG (PCI/AGP), ATI Rage 128 Pro VR PH (PCI/AGP),
ATI Rage 128 Pro VR PI (PCI/AGP), ATI Rage 128 Pro VR PJ (PCI/AGP),
ATI Rage 128 Pro VR PK (PCI/AGP), ATI Rage 128 Pro VR PL (PCI/AGP),
ATI Rage 128 Pro VR PM (PCI/AGP), ATI Rage 128 Pro VR PN (PCI/AGP),
ATI Rage 128 Pro VR PO (PCI/AGP), ATI Rage 128 Pro VR PP (PCI),
ATI Rage 128 Pro VR PQ (PCI/AGP), ATI Rage 128 Pro VR PR (PCI),
ATI Rage 128 Pro VR PS (PCI/AGP), ATI Rage 128 Pro VR PT (PCI/AGP),
ATI Rage 128 Pro VR PU (PCI/AGP), ATI Rage 128 Pro VR PV (PCI/AGP),
ATI Rage 128 Pro VR PW (PCI/AGP), ATI Rage 128 Pro VR PX (PCI/AGP),
ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP),
ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI),
ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (PCI/AGP),
ATI Rage 128 4X SF (PCI/AGP), ATI Rage 128 4X SG (PCI/AGP),
ATI Rage 128 4X SH (PCI/AGP), ATI Rage 128 4X SK (PCI/AGP),
ATI Rage 128 4X SL (PCI/AGP), ATI Rage 128 4X SM (AGP),
ATI Rage 128 4X SN (PCI/AGP), ATI Rage 128 Pro ULTRA TF (AGP),
ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP),
ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?),
ATI Rage 128 Pro ULTRA TU (AGP?)
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI),
ATI Radeon Mobility M7 LW (AGP),
ATI Mobility FireGL 7800 M7 LX (AGP),
ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP),
ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336,
ATI Radeon IGP330/340/350 (A4) 4137,
ATI Radeon IGP330M/340M/350M (U2) 4337,
ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437,
ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP),
ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP),
ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI),
ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI),
ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP),
ATI Radeon Mobility 9000 (M9) Lf (AGP),
ATI Radeon Mobility 9000 (M9) Lg (AGP),
ATI Radeon 9100 IGP (A5) 5834,
ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon 9100 PRO IGP 7834,
ATI Radeon Mobility 9200 IGP 7835, ATI Radeon 9200PRO 5960 (AGP),
ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP),
ATI Radeon 9200SE 5964 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C61 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP),
ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP),
ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP),
ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP),
ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP),
ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP),
ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP),
ATI FireGL RV360 AV (AGP),
ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP),
ATI Radeon Mobility 9600 (M10) NQ (AGP),
ATI Radeon Mobility 9600 (M11) NR (AGP),
ATI Radeon Mobility 9600 (M10) NS (AGP),
ATI FireGL Mobility T2 (M10) NT (AGP),
ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon 9800SE AH (AGP),
ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP),
ATI FireGL X2 AK (AGP), ATI Radeon 9800PRO NH (AGP),
ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP),
ATI Radeon 9800XT NJ (AGP), ATI Radeon X600 (RV380) 3E50 (PCIE),
ATI FireGL V3200 (RV380) 3E54 (PCIE),
ATI Radeon Mobility X600 (M24) 3150 (PCIE),
ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE),
ATI Radeon X600 (RV370) 5B62 (PCIE),
ATI FireGL V3100 (RV370) 5B64 (PCIE),
ATI FireGL D1100 (RV370) 5B65 (PCIE),
ATI Radeon Mobility M300 (M22) 5460 (PCIE),
ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R420) JH (AGP),
ATI Radeon X800PRO (R420) JI (AGP),
ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP),
ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP),
ATI Radeon Mobility 9800 (M18) JN (AGP),
ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X800 (R423) UH (PCIE),
ATI Radeon X800PRO (R423) UI (PCIE),
ATI Radeon X800LE (R423) UJ (PCIE),
ATI Radeon X800SE (R423) UK (PCIE),
ATI FireGL V7200 (R423) UQ (PCIE), ATI FireGL V5100 (R423) UR (PCIE),
ATI FireGL V7100 (R423) UT (PCIE),
ATI Radeon X800XT (R423) 5D57 (PCIE)
(II) Primary Device is: PCI 00:10:0
(II) ATI: Candidate "Device" section "Card1".
(--) Assigning device section with no busID to primary device
(--) Chipset ATI Radeon Mobility M7 LW (AGP) found
(II) resource ranges after xf86ClaimFixedResources() call:
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]
[2] -1 0 0x80080000 - 0x80080fff (0x1000) MX[B]
[3] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B]
[4] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B]
[5] -1 0 0xf1000000 - 0xf101ffff (0x20000) MX[B](B)
[6] -1 0 0x90000000 - 0x9000ffff (0x10000) MX[B](B)
[7] -1 0 0x98000000 - 0x9fffffff (0x8000000) MX[B](B)
[9] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[10] -1 0 0x00000400 - 0x000004ff (0x100) IX[B](B)
(II) Loading sub module "radeon"
(II) LoadModule: "radeon"
(II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o
(II) Module radeon: vendor="X.Org Foundation"
(II) resource ranges after probing:
[1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B]
[2] -1 0 0x80080000 - 0x80080fff (0x1000) MX[B]
[3] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B]
[4] -1 0 0x80000000 - 0x8007ffff (0x80000) MX[B]
[5] -1 0 0xf1000000 - 0xf101ffff (0x20000) MX[B](B)
[6] -1 0 0x90000000 - 0x9000ffff (0x10000) MX[B](B)
[7] -1 0 0x98000000 - 0x9fffffff (0x8000000) MX[B](B)
[8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[12] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[13] -1 0 0x00000400 - 0x000004ff (0x100) IX[B](B)
[14] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[15] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(II) RADEON(0): MMIO registers at 0x90000000
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="X.Org Foundation"
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset is
0x0000
(II) RADEON(0): PCI bus 0 card 16 func 0
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(--) RADEON(0): Chipset: "ATI Radeon Mobility M7 LW (AGP)" (ChipID = 0x4c57)
(--) RADEON(0): Linear framebuffer at 0x98000000
(--) RADEON(0): BIOS at 0xf1000000
(--) RADEON(0): VideoRAM: 32768 kByte (64 bit DDR SDRAM)
(II) RADEON(0): AGP card detected
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Loading /usr/X11R6/lib/modules/libi2c.a
(II) Module i2c: vendor="X.Org Foundation"
(II) RADEON(0): I2C bus "DDC" initialized.
(WW) RADEON(0): Video BIOS not detected in PCI space!
(WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space!
(WW) RADEON(0): Unrecognized BIOS signature, BIOS data will not be used
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 2, Detected Type: 2
(II) RADEON(0): DDC Type: 3, Detected Type: 0
(II) RADEON(0): EDID data from the display on port 1 ----------------------
(II) RADEON(0): Manufacturer: APP Model: 9c1a Serial#: 0
(II) RADEON(0): Year: 2001 Week: 31
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max H-Image Size [cm]: horiz.: 29 vert.: 21
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): No DPMS capabilities specified; RGB/Color Display
(II) RADEON(0): redX: 0.580 redY: 0.339 greenX: 0.327 greenY: 0.533
(II) RADEON(0): blueX: 0.157 blueY: 0.143 whiteX: 0.320 whiteY: 0.330
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 65.0 MHz Image Size: 285 x 214 mm
(II) RADEON(0): h_active: 1024 h_sync: 1048 h_sync_end 1184
h_blank_end 1344 h_border: 0
(II) RADEON(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking:
806 v_border: 0
(II) RADEON(0): LTN141XF
(II) RADEON(0): LTN141XF
(II) RADEON(0): Monitor name: Color LCD
(II) RADEON(0):
(II) RADEON(0): Primary:
Monitor -- LVDS
Connector -- DVI-D
DAC Type -- TVDAC/ExtDAC
TMDS Type -- Internal
DDC Type -- DVI_DDC
(II) RADEON(0): Secondary:
Monitor -- NONE
Connector -- VGA
DAC Type -- Primary
TMDS Type -- External
DDC Type -- VGA_DDC
(WW) RADEON(0): Video BIOS not detected, using default clock settings!
(II) RADEON(0): PLL parameters: rf=2700 rd=12 min=12500 max=35000;
xclk=10300
(WW) RADEON(0): Panel size 1024x768 is derived, this may not be correct.
If not, use PanelSize option to overwrite this setting
(WW) RADEON(0): No valid timing info from BIOS.
And here it hangs. If I find too much time in the next days I trace it
myself ...
Sincerely yours,
Ren? Rebe
--
Ren? Rebe - Europe/Germany/Berlin
rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de
From krh at bitplanet.net Sat Aug 14 17:05:09 2004
Date: Sat Aug 14 17:07:37 2004
In-Reply-To: <411E938B.8030608@sun.com>
References: <1092497395.28452.14.camel@lupus.lupusje.org> <1092499462.3420
.84.camel@localhost.localdomain>
<411E938B.8030608@sun.com>
Message-ID: <411EA8B5.906@bitplanet.net>
> I've also wondered that - so much that for the builds I do for Sun
> for our own internal testing, I set it by default. (Unfortunately,
> it's just in the Sun mouse support code right now - to do it for
> real would be finding the right place in the os-independent mouse
> code, so my patch won't help there.)
It's pretty trivial, we could even consider putting it in 6.8.0:
Index: mouse.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c,v
diff -u -p -r1.3 mouse.c
--- mouse.c 24 Jul 2004 17:35:39 -0000 1.3
+++ mouse.c 15 Aug 2004 00:06:00 -0000
@@ -527,7 +527,7 @@ MouseCommonOptions(InputInfoPtr pInfo)
}
}

- s = xf86SetStrOption(pInfo->options, "ZAxisMapping", NULL);
+ s = xf86SetStrOption(pInfo->options, "ZAxisMapping", "4 5");
if (s) {
int b1 = 0, b2 = 0, b3 = 0, b4 = 0;
char *msg = NULL;
> Jim Gettys wrote:
>
>> Good question...
>>
>> I've wondered this myself.
>>
>> Is there any reason this can't be the default behavior,
>> and only have to mess around if you don't want scroll behavior?
>> - Jim
>>
>> On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
>>
>>> Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
>>> Can't there be some detection for this or just enabled by default?
>>
>>
>>
>> _______________________________________________
>> xorg mailing list
>> xorg@freedesktop.org
>> http://freedesktop.org/mailman/listinfo/xorg
>
>
>
Date: Sat Aug 14 17:15:04 2004
In-Reply-To: <411EA8B5.906@bitplanet.net>
<411E938B.8030608@sun.com> <411EA8B5.906@bitplanet.net>
Well, that looks easy.
Unless someone knows why it would be a bad idea, maybe we
should consider it.
- Jim
On Sat, 2004-08-14 at 20:05, Kristian H?gsberg wrote:
> Alan Coopersmith wrote:
> > I've also wondered that - so much that for the builds I do for Sun
> > for our own internal testing, I set it by default. (Unfortunately,
> > it's just in the Sun mouse support code right now - to do it for
> > real would be finding the right place in the os-independent mouse
> > code, so my patch won't help there.)
>
> It's pretty trivial, we could even consider putting it in 6.8.0:
>
> Index: mouse.c
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 mouse.c
> --- mouse.c 24 Jul 2004 17:35:39 -0000 1.3
> +++ mouse.c 15 Aug 2004 00:06:00 -0000
> @@ -527,7 +527,7 @@ MouseCommonOptions(InputInfoPtr pInfo)
> }
> }
>
>
> - s = xf86SetStrOption(pInfo->options, "ZAxisMapping", NULL);
> + s = xf86SetStrOption(pInfo->options, "ZAxisMapping", "4 5");
> if (s) {
> int b1 = 0, b2 = 0, b3 = 0, b4 = 0;
> char *msg = NULL;
>
>
> > Jim Gettys wrote:
> >
> >> Good question...
> >>
> >> I've wondered this myself.
> >>
> >> Is there any reason this can't be the default behavior,
> >> and only have to mess around if you don't want scroll behavior?
> >> - Jim
> >>
> >> On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
> >>
> >>> Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
> >>> Can't there be some detection for this or just enabled by default?
> >>
> >>
> >>
> >> _______________________________________________
> >> xorg mailing list
> >> xorg@freedesktop.org
> >> http://freedesktop.org/mailman/listinfo/xorg
> >
> >
> >
Date: Sat Aug 14 21:07:28 2004
Subject: [Xorg] CVS as of Keith's commit 04/08/14 20:34:18
Message-ID: <411EE178.4030000@winischhofer.net>
Well, now Composite + xcompmgr works quite well. No KDE crashes so far.
Two issues though:
1) *Without* xcompmgr (but composite enabled), window moving is pretty
slow now. As soon as I start xcompmgr, everything is almost as fast as
normal. Even with shadows, it behaves pretty well.
2) KDE's pseudo-transparency (for konsole, for example) and
pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
Nice work, guys!
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Sat Aug 14 21:31:41 2004
In-Reply-To: <411EE178.4030000@winischhofer.net>
References: <411EE178.4030000@winischhofer.net>
Message-ID: <411EE701.5060508@winischhofer.net>
>
> Well, now Composite + xcompmgr works quite well. No KDE crashes so far.
>
> Two issues though:
>
> 1) *Without* xcompmgr (but composite enabled), window moving is pretty
> slow now. As soon as I start xcompmgr, everything is almost as fast as
> normal. Even with shadows, it behaves pretty well.
>
> 2) KDE's pseudo-transparency (for konsole, for example) and
> pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
3) Window resizing (with xcompmgr) is slow and leaves garbage in window.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From kem at freedesktop.org Sat Aug 14 22:49:17 2004
Date: Sat Aug 14 22:49:24 2004
night.
listed below.
Fixed yesterday: 3
Added yesterday: 0
-----------------------------
- Patch supplied and tested
- Testing is underway
- Patch supplied to allow new kbd driver to be:
1. Installed and loaded with its own name (kbd)
2. Installed and loaded with the same name as the older keyboard
driver, but only if UseDeprecatedKeyboardDriver is NO
Date: Sat Aug 14 23:58:40 2004
Subject: [Xorg] Re: CVS as of Keith's commit 04/08/14 20:34:18
<411EE178.4030000@winischhofer.net>
Message-ID: <E1BwEyC-0000Fw-LE@evo.keithp.com>
Around 6 o'clock on Aug 15, Thomas Winischhofer wrote:
> 1) *Without* xcompmgr (but composite enabled), window moving is pretty
> slow now. As soon as I start xcompmgr, everything is almost as fast as
> normal. Even with shadows, it behaves pretty well.
Hmm. That "shouldn't" happen. I'll debug that when I've got a moment.
> 2) KDE's pseudo-transparency (for konsole, for example) and
> pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
If xcompmgr is not running, the X server should behave precisely as it
used to. Any regressions are bugs.
> Nice work, guys!
Thanks! We aim to please (and we will work to fix these quickly).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040814/6d7f3ae5/attach
ment.pgp
From thomas.klein at lanterne.org Sun Aug 15 01:28:35 2004
From: thomas.klein at lanterne.org (thomas klein)
Date: Sun Aug 15 01:29:52 2004
Subject: [Xorg] composite / kde
Message-ID: <200408151028.35987.thomas.klein@lanterne.org>
hi guys
I'm using kdrive (Xmach64)
xcompmgr from yesterday (the *great* one;)
when opening kde control center then clicking around (apparence, color
scheme)... The display "freeze". Hard to explain, the display isn't
updated, but I can click on my docked shell which runs xcompmgr and
ctrl-c it...
here's the output :
I'm running debian unstable, kde 3.3.0, kernel 2.6.8
thanks a lot for your work guys !
thomas.
From andrew at pimlott.net Sun Aug 15 01:55:00 2004
From: andrew at pimlott.net (Andrew Pimlott)
Date: Sun Aug 15 02:00:07 2004
Subject: [Xorg] [PATCH] allow EmulateWheel to generate normal clicks too
Message-ID: <20040815085500.GC2706@pimlott.net>
I just got hooked on the EmulateWheel feature, for which I use
EmulateWheelButton 2. But I also like having a third button, and I
believe it's possible to have the best of both: If I press button 2 and
release it without moving the mouse, it's a button 2 press; otherwise,
it's an emulated wheel.
This doesn't work for everyone. It requires you to press and release a
button without moving the mouse, which may be hard with a normal mouse,
but easy with a trackball or trackpoint. And it requires you not to
press button 2 to scroll, then change your mind and release without
moving the mouse. But I have found I never do this anyway, so the
behavior I've implemented works great.
I have put this behavior under the option EmulateWheelClickToo, which
defaults to off.
The patch is fairly straightforward, except someone should check my
addition to the man page, because I just aped what I saw.
Andrew
--- hw/xfree86/os-support/xf86OSmouse.h.orig 2004-08-15 00:24:15.000000000 -0
700
+++ hw/xfree86/os-support/xf86OSmouse.h 2004-08-15 01:02:04.000000000 -0700
@@ -150,6 +150,8 @@
Bool emulateWheel;
int wheelInertia;
int wheelButtonMask;
+ Bool wheelButtonClick;
+ Bool wheelButtonMoved;
int negativeX; /* Button values. Unlike the Z
and */
int positiveX; /* W equivalents, these are butt
on */
int negativeY; /* values rather than button mas
ks. */
--- hw/xfree86/input/mouse/mouse.c.orig 2004-08-15 00:07:41.000000000 -0700
+++ hw/xfree86/input/mouse/mouse.c 2004-08-15 01:15:47.000000000 -0700
@@ -185,6 +185,7 @@
OPTION_RESOLUTION,
OPTION_EMULATE_WHEEL,
OPTION_EMU_WHEEL_BUTTON,
+ OPTION_EMU_WHEEL_CLICK,
OPTION_EMU_WHEEL_INERTIA,
OPTION_X_AXIS_MAPPING,
OPTION_Y_AXIS_MAPPING,
@@ -222,6 +223,7 @@
{ OPTION_RESOLUTION, "Resolution", OPTV_INTEGER, {0}, FALSE },
{ OPTION_EMULATE_WHEEL, "EmulateWheel", OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_EMU_WHEEL_BUTTON, "EmulateWheelButton", OPTV_INTEGER, {0}, FALSE }
,
+ { OPTION_EMU_WHEEL_CLICK, "EmulateWheelClickToo", OPTV_BOOLEAN, {0}, FALSE
},
{ OPTION_EMU_WHEEL_INERTIA, "EmulateWheelInertia", OPTV_INTEGER, {0}
, FALSE },
{ OPTION_X_AXIS_MAPPING, "XAxisMapping", OPTV_STRING, {0}, FALSE },
{ OPTION_Y_AXIS_MAPPING, "YAxisMapping", OPTV_STRING, {0}, FALSE },
@@ -619,6 +621,9 @@
}
pMse->wheelButtonMask = 1 << (wheelButton - 1);

+ pMse->wheelButtonClick = xf86SetBoolOption(pInfo->options,
+ "EmulateWheelClickToo", FALSE);
+
pMse->wheelInertia = xf86SetIntOption(pInfo->options,
"EmulateWheelInertia", 10);
if (pMse->wheelInertia <= 0) {
@@ -689,8 +694,9 @@
pInfo->name, pMse->negativeY, pMse->positiveY);
}
xf86Msg(X_CONFIG, "%s: EmulateWheel, EmulateWheelButton: %d, "
- "EmulateWheelInertia: %d\n",
- pInfo->name, wheelButton, pMse->wheelInertia);
+ "EmulateWheelClickToo: %d, EmulateWheelInertia: %d\n",
+ pInfo->name, wheelButton, pMse->wheelInertia,
+ pMse->wheelButtonClick);
}
if (origButtons != pMse->buttons)
from = X_CONFIG;
@@ -1992,6 +1998,8 @@

/* Intercept wheel emulation. */
if (pMse->emulateWheel && (buttons & pMse->wheelButtonMask)) {
+ pMse->wheelButtonMoved = pMse->wheelButtonMoved || dx || dy;
+
/* Y axis movement */
if (pMse->negativeY != MSE_NOAXISMAP) {
pMse->wheelYDistance += dy;
@@ -2044,10 +2052,9 @@
}
}

- /* Absorb the mouse movement and the wheel button press. */
+ /* Absorb the mouse movement. */
dx = 0;
dy = 0;
- buttons &= ~pMse->wheelButtonMask;
}

if (dx || dy)
@@ -2060,6 +2067,31 @@
else
change = buttons ^ reverseBits(reverseMap, pMse->lastButtons);

+ /* We generally swallow wheelButtonMask events, except when a wheel
+ * button is released, and we haven't moved the mouse since a wheel
+ * button was pressed, and EmulateWheelClickToo is set. */
+
+ if (pMse->emulateWheel && change & pMse->wheelButtonMask) {
+ int wheelChange = change & pMse->wheelButtonMask;
+
+ while (wheelChange) {
+ id = ffs(wheelChange);
+ wheelChange &= ~(1 << (id - 1));
+ if (pMse->wheelButtonClick &&
+ ! (buttons & (1 << (id - 1))) && /* released */
+ ! pMse->wheelButtonMoved) {
+ xf86PostButtonEvent(pInfo->dev, 0, id, 1, 0, 0);
+ }
+ }
+
+ if (! (buttons & pMse->wheelButtonMask))
+ pMse->wheelButtonMoved = 0;
+
+ buttons &= ~pMse->wheelButtonMask;
+ change &= ~pMse->wheelButtonMask;
+ }
+
/*
* adjust buttons state for drag locks!
* if there is drag locks
--- hw/xfree86/input/mouse/mouse.man.orig 2004-08-15 01:04:07.000000000 -0
700
+++ hw/xfree86/input/mouse/mouse.man 2004-08-15 01:16:00.000000000 -0700
@@ -112,6 +112,12 @@
.B YAxisMapping
settings. Default: 4.
.TP 7
+.BI "Option \*qEmulateWheelClickToo\*q \*q" boolean \*q
+Causes
+.B EmulateWheelButton
+to generate normal clicks when the mouse isn't moved between press and
+release. Default: off
+.TP 7
.BI "Option \*qEmulateWheelInertia\*q \*q" integer \*q
Specifies how far (in pixels) the pointer must move to generate button
press/release events in wheel emulation mode. Default: 50.
From a.p.zijlstra at chello.nl Sun Aug 15 03:07:42 2004
Date: Sun Aug 15 03:08:34 2004
In-Reply-To: <411EE701.5060508@winischhofer.net>
On Sun, 2004-08-15 at 06:30 +0200, Thomas Winischhofer wrote:
> Thomas Winischhofer wrote:
> >
> > Well, now Composite + xcompmgr works quite well. No KDE crashes so far.
> >
> > Two issues though:
> >
> > 1) *Without* xcompmgr (but composite enabled), window moving is pretty
> > slow now. As soon as I start xcompmgr, everything is almost as fast as
> > normal. Even with shadows, it behaves pretty well.
> >
I can second it, great work!!
xcompmng works pretty good now. However like Thomas said without
xcompmng running things are a bit slower than usual.
> > 2) KDE's pseudo-transparency (for konsole, for example) and
> > pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
>
> 3) Window resizing (with xcompmgr) is slow and leaves garbage in window.
>
Don't have this though.
> Thomas
>
>
--
From de_lupus at pandora.be Sun Aug 15 05:27:39 2004
Date: Sun Aug 15 03:13:34 2004
I don't want it to be vendor specific :p I want it to be vanilla
On Sat, 2004-08-14 at 15:40, Alan Cox wrote:
> On Sad, 2004-08-14 at 15:36, Kristof Vansant wrote:
> > why not do detection as normal user and ask for root password when new
> > hardware is found?
>
> For some parts of card detection you need to be root to bash I/O ports
> and investigate the hardware. Vendors generally do display configuration
> during boot up using other tools so the end user never has to think
> about that issue.
>
> Alan
--
Date: Sun Aug 15 03:22:37 2004
I just hate it that every distro has is own specific database with
hardware info.
I would like to see a shared tool for this (used by all distro's)
On Sat, 2004-08-14 at 15:40, Alan Cox wrote:
> On Sad, 2004-08-14 at 15:36, Kristof Vansant wrote:
> > why not do detection as normal user and ask for root password when new
> > hardware is found?
>
> For some parts of card detection you need to be root to bash I/O ports
> and investigate the hardware. Vendors generally do display configuration
> during boot up using other tools so the end user never has to think
> about that issue.
>
> Alan
--
Date: Sun Aug 15 03:28:48 2004
Subject: [Xorg] composite / kde
In-Reply-To: <200408151028.35987.thomas.klein@lanterne.org>
References: <200408151028.35987.thomas.klein@lanterne.org>
On Sunday 15 August 2004 10:28, thomas klein wrote:
> hi guys
>
> I'm using kdrive (Xmach64)
>
> xcompmgr from yesterday (the *great* one;)
>
> when opening kde control center then clicking around (apparence,
> color scheme)... The display "freeze". Hard to explain, the display
> isn't updated, but I can click on my docked shell which runs
> xcompmgr and ctrl-c it...
>
> here's the output :
>
> error 9 request 141 minor 1 serial 440639
>
>
> I'm running debian unstable, kde 3.3.0, kernel 2.6.8
>
This appends randomly, not only with kcontrol, playing with kde3.3
makes sometime the display to be "freezed", it doesn't update
anymore.
t.
From jlm01001 at student.mdh.se Sun Aug 15 03:48:10 2004
From: jlm01001 at student.mdh.se (=?ISO-8859-1?Q?J=F6rgen?= Lidholm)
Date: Sun Aug 15 04:08:20 2004
On Sun, 2004-08-15 at 02:14, Jim Gettys wrote:
> Well, that looks easy.
>
> Unless someone knows why it would be a bad idea, maybe we
> should consider it.
> - Jim
I have a Intellimouse Explorer 2.0 which has actually 9 buttons.
Or 7 plus two non-working mousewheel-tilt-buttons.
I think that I have to remap my buttons so that the wheel is set
to button 6 7 and my side buttons to 4 5 to get them to work.
At least that is how I've configured it...
/Jorgen
> On Sat, 2004-08-14 at 20:05, Kristian H?gsberg wrote:
> > Alan Coopersmith wrote:
> > > I've also wondered that - so much that for the builds I do for Sun
> > > for our own internal testing, I set it by default. (Unfortunately,
> > > it's just in the Sun mouse support code right now - to do it for
> > > real would be finding the right place in the os-independent mouse
> > > code, so my patch won't help there.)
> >
> > It's pretty trivial, we could even consider putting it in 6.8.0:
> >
> > Index: mouse.c
> > ===================================================================
> > RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 mouse.c
> > --- mouse.c 24 Jul 2004 17:35:39 -0000 1.3
> > +++ mouse.c 15 Aug 2004 00:06:00 -0000
> > @@ -527,7 +527,7 @@ MouseCommonOptions(InputInfoPtr pInfo)
> > }
> > }
> >
> >
> > - s = xf86SetStrOption(pInfo->options, "ZAxisMapping", NULL);
> > + s = xf86SetStrOption(pInfo->options, "ZAxisMapping", "4 5");
> > if (s) {
> > int b1 = 0, b2 = 0, b3 = 0, b4 = 0;
> > char *msg = NULL;
> >
> >
> > > Jim Gettys wrote:
> > >
> > >> Good question...
> > >>
> > >> I've wondered this myself.
> > >>
> > >> Is there any reason this can't be the default behavior,
> > >> and only have to mess around if you don't want scroll behavior?
> > >> - Jim
> > >>
> > >> On Sat, 2004-08-14 at 11:29, Kristof Vansant wrote:
> > >>
> > >>> Why is Option "ZAxisMapping" "4 5" needed for my scrollmouse to work.
> > >>> Can't there be some detection for this or just enabled by default?
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> xorg mailing list
> > >> xorg@freedesktop.org
> > >> http://freedesktop.org/mailman/listinfo/xorg
> > >
> > >
> > >
>
> _______________________________________________
> xorg mailing list
>
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/2475c471/attach
ment.pgp
From thomas at winischhofer.net Sun Aug 15 05:08:20 2004
Date: Sun Aug 15 05:09:20 2004
In-Reply-To: <1092564462.26982.1.camel@twins>
<1092564462.26982.1.camel@twins>
Message-ID: <411F5234.3070005@winischhofer.net>
Peter Zijlstra wrote:
> On Sun, 2004-08-15 at 06:30 +0200, Thomas Winischhofer wrote:
>
>>Thomas Winischhofer wrote:
>>
>>>Well, now Composite + xcompmgr works quite well. No KDE crashes so far.
>>>
>>>Two issues though:
>>>
>>>1) *Without* xcompmgr (but composite enabled), window moving is pretty
>>>slow now. As soon as I start xcompmgr, everything is almost as fast as
>>>normal. Even with shadows, it behaves pretty well.
>>>
>
> I can second it, great work!!
> xcompmng works pretty good now. However like Thomas said without
> xcompmng running things are a bit slower than usual.
>
>
>>>2) KDE's pseudo-transparency (for konsole, for example) and
>>>pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
>>
>>3) Window resizing (with xcompmgr) is slow and leaves garbage in window.
>>
>
> Don't have this though.
See
http://www.winischhofer.net/snapshot0001.png (with composite, but
without xcompmgr) and
http://www.winischhofer.net/snapshot0002.png (composite disabled).
1. KDE's Menu shadows seem to consist of another windows pixmap(s)
2. Konsole background is somewhat "wrapped".
http://www.winischhofer.net/snapshot0003.png (xcompmgr). Looks good,
except for the background issue
http://www.winischhofer.net/snapshot0004.png (xcompmgr -c). Menu shadows
get "double" alpha blending treatment as it seems. I assume that is is
imminent if the shadow is done twice.
http://www.winischhofer.net/snapshot0005.png (xcompmgr -c) - result of
resizing a window. That does not happen all the time; I managed to
resize it without garbage sometimes. In the example, I simply made the
window bigger (and did this pretty fast).
4) With composite, without xcompmgr: KDE's Load feedback type "bounding
icon" is broken, too. The bouncing icon is somewhat distorted. Couldn't
make a screenshot of this though.
5) "xcompmgr -f" doesn't work so well either. Menus come up without
contents, just its shadow.
>
>
>>Thomas
>>
>>
Still Thomas.
--
Thomas Winischhofer
Vienna/Austria
From morphie at unravel-music.nl Sun Aug 15 05:54:26 2004
Date: Sun Aug 15 05:53:12 2004
In-Reply-To: <20040815002110.1b2863c8.diegocg@teleline.es>
<20040814202147.70f42fc2.diegocg@teleline.es>
<20040815002110.1b2863c8.diegocg@teleline.es>
On Sunday 15 August 2004 00:21, Diego Calleja Garc?a wrote:
> Just wanted to notice that xcompmgr has stopped crashing. (see the bug)
> Have you tried the latest cvs?
Here it runs now. (latest CVS xc and xcompmgr)
But xcompmgr freezes the screen after 10 seconds now. I'm looking for what the
problem could be. :)
From morphie at unravel-music.nl Sun Aug 15 06:02:56 2004
Date: Sun Aug 15 06:01:43 2004
In-Reply-To: <E1BwEyC-0000Fw-LE@evo.keithp.com>
References: <E1BwEyC-0000Fw-LE@evo.keithp.com>
On Sunday 15 August 2004 08:58, Keith Packard wrote:
> Around 6 o'clock on Aug 15, Thomas Winischhofer wrote:
> > 1) *Without* xcompmgr (but composite enabled), window moving is pretty
> > slow now. As soon as I start xcompmgr, everything is almost as fast as
> > normal. Even with shadows, it behaves pretty well.
>
> Hmm. That "shouldn't" happen. I'll debug that when I've got a moment.
Here Composite behaves the same. With composite enabled and xcompmgr not
running, moving windows is slow.
Only I have another problem also, although I don't know what it causes,
because everyone else don't seem to have that problem.
xcompmgr runs, the eye-candy is on, but the screen freezes. I can move the
mouse, and I can click on icons and the program is starting, but the screen
won't refresh anymore so I don't see any changes anymore.
(I am using today's CVS of xc and xcompmgr)
>
> > 2) KDE's pseudo-transparency (for konsole, for example) and
> > pseudo-menu-shadow is broken - but this is assumingly a KDE issue.
>
> If xcompmgr is not running, the X server should behave precisely as it
> used to. Any regressions are bugs.
>
> > Nice work, guys!
>
> Thanks! We aim to please (and we will work to fix these quickly).
I'm actually very(!) pleased with the progress made. Not only the last few
days/weeks, but the complete X-Development. :-)
- Dennie
From alan at lxorguk.ukuu.org.uk Sun Aug 15 05:10:03 2004
Date: Sun Aug 15 06:12:19 2004
On Sul, 2004-08-15 at 13:36, Kristof Vansant wrote:
> I just hate it that every distro has is own specific database with
> hardware info. I would like to see a shared tool for this (used by all distro'
s)
X doesn't currently provide an easy to extract hardware database,
in addition to which it requires extra poking to identify some cards.
For the kernel it works because each ELF binary object contains a
locatable pointer to a table in the module itself. That allows you to
build the database even with upgrades and added drivers. Xorg doesn't do
that although if you want to volunteer to add such functionality to the
standardised binary format used by Xorg I'm sure people would be
delighted
From krh at bitplanet.net Sun Aug 15 07:41:27 2004
Date: Sun Aug 15 07:43:46 2004
Subject: [Xorg] why is Option "ZAxisMapping" "4 5" needed
for my scrollmouse to work
.84.camel@localhost.localdomain> <411E938B.8030608@sun.com>
<411EA8B5.906@bitplanet.net> <1092528877.3394.111.camel@localhost.loc
aldomain>
<1092566890.3432.4.camel@localhost>
Message-ID: <411F7617.1030303@bitplanet.net>
J?rgen Lidholm wrote:
> On Sun, 2004-08-15 at 02:14, Jim Gettys wrote:
>
>>Well, that looks easy.
>>
>>Unless someone knows why it would be a bad idea, maybe we
>>should consider it.
>> - Jim
>
>
> I have a Intellimouse Explorer 2.0 which has actually 9 buttons.
> Or 7 plus two non-working mousewheel-tilt-buttons.
>
> I think that I have to remap my buttons so that the wheel is set
> to button 6 7 and my side buttons to 4 5 to get them to work.
>
> At least that is how I've configured it...
The suggested patch just sets the default values, it doesn't prevent you
from using the option to set the ZAxisMapping as you've done. I'm
curious though, if you remap the scroll wheel to buttons 6 and 7 does it
work with gtk and qt applications, mozilla, etc?
From saturn_vk at abv.bg Sun Aug 15 08:51:25 2004
From: saturn_vk at abv.bg (Viktor Kojouharov)
Date: Sun Aug 15 09:17:24 2004
Message-ID: <752609116.1092585085176.JavaMail.nobody@app1.ni.bg>
>On Sunday 15 August 2004 00:21, Diego Calleja Garc?a wrote:
>> Just wanted to notice that xcompmgr has stopped crashing. (see the bug)
>> Have you tried the latest cvs?
>
>Here it runs now. (latest CVS xc and xcompmgr)
>But xcompmgr freezes the screen after 10 seconds now. I'm looking for what the

>problem could be. :)
>_______________________________________________
>xorg mailing list
using either, or both nvidia & mga drivers (with xinerama and without, or separa
tely), upon starting xcompmgr it locks up the whole computer almost immediately.
this with the latest cvs of xc and xcompmgr.
-----------------------------------------------------------------
http://www.elmaz.com/ - ????????????!
From s864 at ii.uib.no Sun Aug 15 09:18:15 2004
Date: Sun Aug 15 09:18:24 2004
l?r, 14,.08.2004 kl. 13.34 -0500, skrev Ryan:
> On Sat, 2004-08-14 at 20:10 +0200, Ronny V. Vindenes wrote:
> > l?r, 14,.08.2004 kl. 09.52 -0700, skrev Keith Packard:
> > > Around 11 o'clock on Aug 14, "Ronny V. Vindenes" wrote:
> > >
> > > > notice how parts of the gnome panel blanks out
> > > > - I see this at random places and times
> > >
> > > I fixed a bug that did this when using Composite last night.
> > >
> >
> > I still see it with cvs from today
> >
>
> Not me, things are drawing really nicely, metacity, gnome and gnome-
> panel and any gtk apps I've run do anyway. Some other toolkits still
> don't draw right though. Running the program Audacity (fltk audio
> editor) reveals some glitches in menu items.
>
> The only profound visual issue for me is broken scrolling in evolution
> firefox (scrolling in gedit and gnome-terminal is fine). Composite is
> still prohibitively slow. Interestingly running skippy-xd (expose clone
> using composite et. al.) is also dog slow. This confirms the issue to
> be in xaa and composite not xcompmgr itself?
With cvs today (the 15th), everything I've tested is drawing correctly.
Performance with xcompmgr running is pretty good, BUT without xcompmgr
running it's really poor - scrolling in gnome-terminal is so slow it's
completely unusable and moving windows around is all "skip-n-jump".
xcompmgr also crashes with these two errors every now and then:
[rvv@tentacle125 xcompmgr]$ ./xcompmgr -c
Aborted
[rvv@tentacle125 xcompmgr]$ ./xcompmgr -c
Aborted
--
From nbensa at gmx.net Sun Aug 15 09:04:32 2004
From: nbensa at gmx.net (Norberto Bensa)
Date: Sun Aug 15 09:37:55 2004
=?utf-8?q?my=09scrollmouse_to?= work
<1092566890.3432.4.camel@localhost>
Message-ID: <200408151304.32329.nbensa@gmx.net>
J?rgen Lidholm wrote:
> On Sun, 2004-08-15 at 02:14, Jim Gettys wrote:
> > Unless someone knows why it would be a bad idea, maybe we
> > should consider it.
>
> I have a Intellimouse Explorer 2.0 which has actually 9 buttons.
> Or 7 plus two non-working mousewheel-tilt-buttons.
>
> I think that I have to remap my buttons so that the wheel is set
> to button 6 7 and my side buttons to 4 5 to get them to work.
Ah ha! Yes. My Intellimouse Explorer also has that configuration:
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "ExplorerPS/2"
Option "Emulate3Buttons" "Off"
EndSection
This one is five buttons. Left, right, and middle click. Two buttons on the
side for back, forward. And the wheel.
Regards,
Norberto
From elfarto at elfarto.com Sun Aug 15 09:23:26 2004
From: elfarto at elfarto.com (Stephen Dawkins)
Date: Sun Aug 15 09:43:38 2004
Subject: [Xorg] SIGSEGV in miWideDash
Message-ID: <411F8DFE.5090105@elfarto.com>
Hi
With Xorg 6.7.0 and todays CVS build, I am receiving a SIGSEGV in
miwideline.c line 2194, which is:
miLineArc (pDrawable, pGC, pixel, spanData,
&firstFace, (LineFacePtr) NULL,
(double)0.0, (double)0.0, TRUE);
I can reproduce the SIGSEGV by running a gnome-terminal, the opening up
the properties window for the current profile and moving the mouse over
it (the properties window).
I can also reproduce other SIGSEGV's by running various gnome programs,
but I have yet to check if they are in the same place as the above error.
Does anyone have a clue why this is happening?
Regards
Stephen
-------------- next part --------------
Name: Xorg.0.log
Type: text/x-log
Size: 26163 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/8647a89f/Xorg.0
-0001.bin
From ramon.rey at hispalinux.es Sun Aug 15 10:05:04 2004
From: ramon.rey at hispalinux.es (=?ISO-8859-1?Q?Ram=F3n_Rey_Vicente?=)
Date: Sun Aug 15 10:11:53 2004
Subject: [Xorg] Where have all the direct rendering gone?
Message-ID: <411F97C0.90602@hispalinux.es>
Skipped content of type multipart/mixed-------------- next part --------------
Name: signature.asc
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/a13fdc28/signat
ure.pgp
From ramon.rey at hispalinux.es Sun Aug 15 10:22:12 2004
From: ramon.rey at hispalinux.es (=?ISO-8859-1?Q?Ram=F3n_Rey_Vicente?=)
Date: Sun Aug 15 10:22:16 2004
In-Reply-To: <411F97C0.90602@hispalinux.es>
References: <411F97C0.90602@hispalinux.es>
Message-ID: <411F9BC4.3070703@hispalinux.es>
Hash: SHA1
Ram?n Rey Vicente wrote:
| Hello.
|
| Running Xorg 6.7.99.2 from Fedora Rawhide (6.7.99.2-5) with no composite
| enabled, there is no problmes, but Direct Rendering with may r128 is not
| working :-/
Ups :-(
s/may/my
s/problmes/problems
- --
Ram?n Rey Vicente <ramon dot rey at hispalinux dot es>
jabber ID <rreylinux at jabber dot org>
GPGid 9F28E377 - 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377
===================================================================
http://cinema-paradiso.blogspot.com/
===================================================================
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBH5vDw4Wp058o43cRAlvrAJ9m0CnXd2S/k/mqXQxyY7g387hkHACcDoqi
E4+8nSAxCwbXdIqO1IlSdAc=
=X7z9
Date: Sun Aug 15 10:32:26 2004
Can't HALD, /proc or /sysfs give the necessary info?
On Sun, 2004-08-15 at 12:10, Alan Cox wrote:
> On Sul, 2004-08-15 at 13:36, Kristof Vansant wrote:
> > I just hate it that every distro has is own specific database with
> > hardware info. I would like to see a shared tool for this (used by all distr
o's)
>
> X doesn't currently provide an easy to extract hardware database,
> in addition to which it requires extra poking to identify some cards.
>
> For the kernel it works because each ELF binary object contains a
> locatable pointer to a table in the module itself. That allows you to
> build the database even with upgrades and added drivers. Xorg doesn't do
> that although if you want to volunteer to add such functionality to the
> standardised binary format used by Xorg I'm sure people would be
> delighted
--
From Jim.Gettys at hp.com Sun Aug 15 11:10:49 2004
Date: Sun Aug 15 11:11:19 2004
In-Reply-To: <20040815085500.GC2706@pimlott.net>
References: <20040815085500.GC2706@pimlott.net>
Andrew,
It is too late to consider this for the upcoming release.
But please put this in the bugzilla so we won't lose it.
- Jim
On Sun, 2004-08-15 at 04:55, Andrew Pimlott wrote:
> I just got hooked on the EmulateWheel feature, for which I use
> EmulateWheelButton 2. But I also like having a third button, and I
> believe it's possible to have the best of both: If I press button 2 and
> release it without moving the mouse, it's a button 2 press; otherwise,
> it's an emulated wheel.
>
> This doesn't work for everyone. It requires you to press and release a
> button without moving the mouse, which may be hard with a normal mouse,
> but easy with a trackball or trackpoint. And it requires you not to
> press button 2 to scroll, then change your mind and release without
> moving the mouse. But I have found I never do this anyway, so the
> behavior I've implemented works great.
>
> I have put this behavior under the option EmulateWheelClickToo, which
> defaults to off.
>
> The patch is fairly straightforward, except someone should check my
> addition to the man page, because I just aped what I saw.
>
> Andrew
>
>
> --- hw/xfree86/os-support/xf86OSmouse.h.orig 2004-08-15 00:24:15.000000000 -0
700
> +++ hw/xfree86/os-support/xf86OSmouse.h 2004-08-15 01:02:04.000000000 -0
700
> @@ -150,6 +150,8 @@
> Bool emulateWheel;
> int wheelInertia;
> int wheelButtonMask;
> + Bool wheelButtonClick;
> + Bool wheelButtonMoved;
> int negativeX; /* Button values. Unlike the Z
and */
> int positiveX; /* W equivalents, these are butt
on */
> int negativeY; /* values rather than button mas
ks. */
> --- hw/xfree86/input/mouse/mouse.c.orig 2004-08-15 00:07:41.000000000 -0
700
> +++ hw/xfree86/input/mouse/mouse.c 2004-08-15 01:15:47.000000000 -0700
> @@ -185,6 +185,7 @@
> OPTION_RESOLUTION,
> OPTION_EMULATE_WHEEL,
> OPTION_EMU_WHEEL_BUTTON,
> + OPTION_EMU_WHEEL_CLICK,
> OPTION_EMU_WHEEL_INERTIA,
> OPTION_X_AXIS_MAPPING,
> OPTION_Y_AXIS_MAPPING,
> @@ -222,6 +223,7 @@
> { OPTION_RESOLUTION, "Resolution", OPTV_INTEGER, {0}, FALSE },
> { OPTION_EMULATE_WHEEL, "EmulateWheel", OPTV_BOOLEAN, {0}, FALSE },
> { OPTION_EMU_WHEEL_BUTTON, "EmulateWheelButton", OPTV_INTEGER, {0},
FALSE },
> + { OPTION_EMU_WHEEL_CLICK, "EmulateWheelClickToo", OPTV_BOOLEAN, {0
}, FALSE },
> { OPTION_EMU_WHEEL_INERTIA, "EmulateWheelInertia", OPTV_INTEGER, {0}
, FALSE },
> { OPTION_X_AXIS_MAPPING, "XAxisMapping", OPTV_STRING, {0}, FALSE },
> { OPTION_Y_AXIS_MAPPING, "YAxisMapping", OPTV_STRING, {0}, FALSE },
> @@ -619,6 +621,9 @@
> }
> pMse->wheelButtonMask = 1 << (wheelButton - 1);
>
> + pMse->wheelButtonClick = xf86SetBoolOption(pInfo->options,
> + "EmulateWheelClickToo", FALSE);
> +
> pMse->wheelInertia = xf86SetIntOption(pInfo->options,
> "EmulateWheelInertia", 10);
> if (pMse->wheelInertia <= 0) {
> @@ -689,8 +694,9 @@
> pInfo->name, pMse->negativeY, pMse->positiveY);
> }
> xf86Msg(X_CONFIG, "%s: EmulateWheel, EmulateWheelButton: %d, "
> - "EmulateWheelInertia: %d\n",
> - pInfo->name, wheelButton, pMse->wheelInertia);
> + "EmulateWheelClickToo: %d, EmulateWheelInertia: %d\n",
> + pInfo->name, wheelButton, pMse->wheelInertia,
> + pMse->wheelButtonClick);
> }
> if (origButtons != pMse->buttons)
> from = X_CONFIG;
> @@ -1992,6 +1998,8 @@
>
> /* Intercept wheel emulation. */
> if (pMse->emulateWheel && (buttons & pMse->wheelButtonMask)) {
> + pMse->wheelButtonMoved = pMse->wheelButtonMoved || dx || dy;
> +
> /* Y axis movement */
> if (pMse->negativeY != MSE_NOAXISMAP) {
> pMse->wheelYDistance += dy;
> @@ -2044,10 +2052,9 @@
> }
> }
>
> - /* Absorb the mouse movement and the wheel button press. */
> + /* Absorb the mouse movement. */
> dx = 0;
> dy = 0;
> - buttons &= ~pMse->wheelButtonMask;
> }
>
> if (dx || dy)
> @@ -2060,6 +2067,31 @@
> else
> change = buttons ^ reverseBits(reverseMap, pMse->lastButtons);
>
> + /* We generally swallow wheelButtonMask events, except when a wheel
> + * button is released, and we haven't moved the mouse since a wheel
> + * button was pressed, and EmulateWheelClickToo is set. */
> +
> + if (pMse->emulateWheel && change & pMse->wheelButtonMask) {
> + int wheelChange = change & pMse->wheelButtonMask;
> +
> + while (wheelChange) {
> + id = ffs(wheelChange);
> + wheelChange &= ~(1 << (id - 1));
> + if (pMse->wheelButtonClick &&
> + ! (buttons & (1 << (id - 1))) && /* released */
> + ! pMse->wheelButtonMoved) {
> + xf86PostButtonEvent(pInfo->dev, 0, id, 1, 0, 0);
> + }
> + }
> +
> + if (! (buttons & pMse->wheelButtonMask))
> + pMse->wheelButtonMoved = 0;
> +
> + buttons &= ~pMse->wheelButtonMask;
> + change &= ~pMse->wheelButtonMask;
> + }
> +
> /*
> * adjust buttons state for drag locks!
> * if there is drag locks
> --- hw/xfree86/input/mouse/mouse.man.orig 2004-08-15 01:04:07.000000000 -0
700
> +++ hw/xfree86/input/mouse/mouse.man 2004-08-15 01:16:00.000000000 -0700
> @@ -112,6 +112,12 @@
> .B YAxisMapping
> settings. Default: 4.
> .TP 7
> +.BI "Option \*qEmulateWheelClickToo\*q \*q" boolean \*q
> +Causes
> +.B EmulateWheelButton
> +to generate normal clicks when the mouse isn't moved between press and
> +release. Default: off
> +.TP 7
> .BI "Option \*qEmulateWheelInertia\*q \*q" integer \*q
> Specifies how far (in pixels) the pointer must move to generate button
> press/release events in wheel emulation mode. Default: 50.
>
>
> _______________________________________________
> xorg mailing list
Date: Sun Aug 15 11:20:02 2004
action...
Message-ID: <E1BwPbW-0000a9-Bf@evo.keithp.com>
> With cvs today (the 15th), everything I've tested is drawing correctly.
> Performance with xcompmgr running is pretty good, BUT without xcompmgr
> running it's really poor - scrolling in gnome-terminal is so slow it's
> completely unusable and moving windows around is all "skip-n-jump".
I cannot reproduce this kind of performance problem. I'm going to need
some help to fix it. What video card? CPU? I did find a minor
performance issue with window manipulation using x11perf:
$ x11perf -move
With composite extension enabled, no xcompmgr:
80000 reps @ 0.1137 msec ( 8790.0/sec): Move window (4 kids)
With composite extension disabled:
I'm building the server -pg to find out where this problem lies. But,
first I'm fsck'ing all my disks again (having crashed about 50 times
yesterday helping Eric Anholt work out an R200 DRI bug).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/dbcecc0c/attach
ment.pgp
Date: Sun Aug 15 11:29:51 2004
<411F97C0.90602@hispalinux.es>
Message-ID: <E1BwPlC-0000au-Vb@evo.keithp.com>
Around 19 o'clock on Aug 15, =?ISO-8859-1?Q?Ram=F3n_Rey_Vicente?= wrote:
> Running Xorg 6.7.99.2 from Fedora Rawhide (6.7.99.2-5) with no composite
> enabled, there is no problmes, but Direct Rendering with may r128 is not
> working :-/
I'll bet it needs a new version of the DRM kernel module.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/aa810e86/attach
ment.pgp
Date: Sun Aug 15 11:30:40 2004
Subject: [Xorg] Solicitation of screen shots of new facilities in action..
.
In-Reply-To: <E1BwPbW-0000a9-Bf@evo.keithp.com>
References: <E1BwPbW-0000a9-Bf@evo.keithp.com>
Message-ID: <411FAB7E.8040900@winischhofer.net>
>
>
>>With cvs today (the 15th), everything I've tested is drawing correctly.
>>Performance with xcompmgr running is pretty good, BUT without xcompmgr
>>running it's really poor - scrolling in gnome-terminal is so slow it's
>>completely unusable and moving windows around is all "skip-n-jump".
>
>
> I cannot reproduce this kind of performance problem. I'm going to need
> some help to fix it. What video card? CPU? I did find a minor
> performance issue with window manipulation using x11perf:
>
> $ x11perf -move
2Ghz Celeron, SiS M650 (shared memory):
>
> With composite extension enabled, no xcompmgr:
>
> 80000 reps @ 0.1137 msec ( 8790.0/sec): Move window (4 kids)
80000 reps @ 0.1104 msec (9060.0/sec): Move window (4 kids)
> With composite extension disabled:
>
Seems that with composite enabled, the CPU copies the data instead of
the engine.
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Sun Aug 15 11:40:01 2004
action...
<411FAB7E.8040900@winischhofer.net>
Message-ID: <E1BwPuo-0000bn-Ib@evo.keithp.com>
> Seems that with composite enabled, the CPU copies the data instead of
> the engine.
ah. I have a theory about that. Let me try something here...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/c2e3642b/attach
ment-0001.pgp
From a.p.zijlstra at chello.nl Sun Aug 15 11:40:18 2004
Date: Sun Aug 15 11:41:12 2004
.
In-Reply-To: <411FAB7E.8040900@winischhofer.net>
On Sun, 2004-08-15 at 20:29 +0200, Thomas Winischhofer wrote:
> Keith Packard wrote:
> > Around 18 o'clock on Aug 15, "Ronny V. Vindenes" wrote:
> >
> >
> >>With cvs today (the 15th), everything I've tested is drawing correctly.
> >>Performance with xcompmgr running is pretty good, BUT without xcompmgr
> >>running it's really poor - scrolling in gnome-terminal is so slow it's
> >>completely unusable and moving windows around is all "skip-n-jump".
> >
> >
> > I cannot reproduce this kind of performance problem. I'm going to need
> > some help to fix it. What video card? CPU? I did find a minor
> > performance issue with window manipulation using x11perf:
> >
> > $ x11perf -move
>
> 2Ghz Celeron, SiS M650 (shared memory):
Dual Thunderbird 1400 MHz, Radeon 9000 128MB
>
> >
> > With composite extension enabled, no xcompmgr:
> >
> > 80000 reps @ 0.1137 msec ( 8790.0/sec): Move window (4 kids)
>
> 80000 reps @ 0.1104 msec (9060.0/sec): Move window (4 kids)
>
> > With composite extension disabled:
> >
> > 240000 reps @ 0.0210 msec ( 47700.0/sec): Move window (4 kids)
>
> 120000 reps @ 0.0497 msec (20100.0/sec): Move window (4 kids)
>
--
Date: Sun Aug 15 11:51:44 2004
In-Reply-To: <E1BwPbW-0000a9-Bf@evo.keithp.com>
s?n, 15,.08.2004 kl. 11.19 -0700, skrev Keith Packard:
>
> > With cvs today (the 15th), everything I've tested is drawing correctly.
> > Performance with xcompmgr running is pretty good, BUT without xcompmgr
> > running it's really poor - scrolling in gnome-terminal is so slow it's
> > completely unusable and moving windows around is all "skip-n-jump".
>
> I cannot reproduce this kind of performance problem. I'm going to need
> some help to fix it. What video card? CPU? I did find a minor
> performance issue with window manipulation using x11perf:
>
ATI 9000 AGP, Athlon64 3200+ (64bit kernel & userspace)
> $ x11perf -move
>
> With composite extension enabled, no xcompmgr:
>
>
> With composite extension disabled:
>
>
composite enabled - no xcompmgr
600000 trep @ 0.0553 msec ( 18100.0/sec): Move window (4 kids)
composite enabled - xcompmgr running
composite disabled
With composite disabled performance is back to normal.
--
Date: Sun Aug 15 11:55:47 2004
Message-ID: <a728f9f90408151155486e0426@mail.gmail.com>
On Sun, 15 Aug 2004 04:55:00 -0400, Andrew Pimlott <andrew@pimlott.net> wrote:
> I just got hooked on the EmulateWheel feature, for which I use
> EmulateWheelButton 2. But I also like having a third button, and I
> believe it's possible to have the best of both: If I press button 2 and
> release it without moving the mouse, it's a button 2 press; otherwise,
> it's an emulated wheel.
>
> This doesn't work for everyone. It requires you to press and release a
> button without moving the mouse, which may be hard with a normal mouse,
> but easy with a trackball or trackpoint. And it requires you not to
> press button 2 to scroll, then change your mind and release without
> moving the mouse. But I have found I never do this anyway, so the
> behavior I've implemented works great.
>
> I have put this behavior under the option EmulateWheelClickToo, which
> defaults to off.
>
there's a similar patch in bugzilla:
you can add yours there. We can look at adding it to the next release.
> The patch is fairly straightforward, except someone should check my
> addition to the man page, because I just aped what I saw.
>
> Andrew
>
> --- hw/xfree86/os-support/xf86OSmouse.h.orig 2004-08-15 00:24:15.000000000
-0700
> @@ -150,6 +150,8 @@
> int wheelInertia;
> + Bool wheelButtonMoved;
> int negativeX; /* Button values. Unlike the
Z and */
> int positiveX; /* W equivalents, these are bu
tton */
> int negativeY; /* values rather than button m
asks. */
> @@ -185,6 +185,7 @@
> @@ -222,6 +223,7 @@
> { OPTION_EMU_WHEEL_BUTTON, "EmulateWheelButton", OPTV_INTEGER, {0}, FALSE
},
> + { OPTION_EMU_WHEEL_CLICK, "EmulateWheelClickToo", OPTV_BOOLEAN, {0}, FAL
SE },
> { OPTION_EMU_WHEEL_INERTIA, "EmulateWheelInertia", OPTV_INTEGER, {
0}, FALSE },
> @@ -619,6 +621,9 @@
> }
>
> +
> @@ -689,8 +694,9 @@
> }
> + "EmulateWheelClickToo: %d, EmulateWheelInertia: %d\n
",
> }
> from = X_CONFIG;
> @@ -1992,6 +1998,8 @@
>
> + pMse->wheelButtonMoved = pMse->wheelButtonMoved || dx || dy;
> +
> @@ -2044,10 +2052,9 @@
> }
> }
>
> dx = 0;
> dy = 0;
> }
>
> if (dx || dy)
> @@ -2060,6 +2067,31 @@
> else
>
> +
> +
> + wheelChange &= ~(1 << (id - 1));
> + ! pMse->wheelButtonMoved) {
> + }
> + }
> +
> +
> + }
> +
> /*
> --- hw/xfree86/input/mouse/mouse.man.orig 2004-08-15 01:04:07.000000000
-0700
> @@ -112,6 +112,12 @@
> .B YAxisMapping
> .TP 7
> +Causes
> +.TP 7
>
> _______________________________________________
> xorg mailing list
>
From alan at lxorguk.ukuu.org.uk Sun Aug 15 10:59:14 2004
Date: Sun Aug 15 12:01:39 2004
On Sul, 2004-08-15 at 20:46, Kristof Vansant wrote:
> Can't HALD, /proc or /sysfs give the necessary info?
No but feel free to write code for that to do so.
Date: Sun Aug 15 12:08:07 2004
action...
Message-ID: <E1BwQM6-0000cI-6k@evo.keithp.com>
> Seems that with composite enabled, the CPU copies the data instead of
> the engine.
Thanks! I think I found the problem. Can you give CVS a whirl?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/44968e87/attach
ment.pgp
Date: Sun Aug 15 12:26:39 2004
root@lupus:/home/lupus# lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti
500] (rev a3)
so the driver is nv, I don't understand what the problem is.
On Sun, 2004-08-15 at 17:59, Alan Cox wrote:
> On Sul, 2004-08-15 at 20:46, Kristof Vansant wrote:
> > Can't HALD, /proc or /sysfs give the necessary info?
>
> No but feel free to write code for that to do so.
--
Date: Sun Aug 15 12:30:28 2004
In-Reply-To: <E1BwQM6-0000cI-6k@evo.keithp.com>
References: <E1BwQM6-0000cI-6k@evo.keithp.com>
s?n, 15,.08.2004 kl. 12.07 -0700, skrev Keith Packard:
> Around 20 o'clock on Aug 15, Thomas Winischhofer wrote:
>
> > Seems that with composite enabled, the CPU copies the data instead of
> > the engine.
>
> Thanks! I think I found the problem. Can you give CVS a whirl?
>
That fixed it for me
--
Date: Sun Aug 15 12:36:42 2004
s?n, 15,.08.2004 kl. 21.30 +0200, skrev Ronny V. Vindenes:
> s?n, 15,.08.2004 kl. 12.07 -0700, skrev Keith Packard:
> > Around 20 o'clock on Aug 15, Thomas Winischhofer wrote:
> >
> > > Seems that with composite enabled, the CPU copies the data instead of
> > > the engine.
> >
> > Thanks! I think I found the problem. Can you give CVS a whirl?
> >
>
> That fixed it for me
>
But it seems to have introduced or triggered a new bug - with xcompmgr
running now I get screen corruption mostly in the left hand top corner.
--
Date: Sun Aug 15 12:45:36 2004
Hash: SHA1
On Sunday 15 August 2004 17:40, Kristof Vansant wrote:
> root@lupus:/home/lupus# lspci | grep VGA
> 01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti
> 500] (rev a3)
>
> so the driver is nv, I don't understand what the problem is.
Please stop top-posting.
The problem is that we have no way to bind a PCI ID to a driver before the
driver is loaded. We don't have a database anywhere saying "this chip id
means i need this driver". Clearly you as a human can look at the pretty PCI
name and know, but the server isn't that smart yet. What we'd want to do is
put that list in the driver itself, so when we first dlopen the driver we can
ask it what PCI IDs it supports.
And in fact we have all the necessary information in the drivers already -
since they all have to check for supported chips somehow - it's just a matter
of factoring that out into a common data structure and teaching the server to
read that at module open time.
The problem here would be stupid buses like ISA, but I'm perfectly willing to
tell people insane enough to use ISA video cards that they need to explicitly
specify their driver or else be stuck with vga(4) or vesa(4). I think pretty
much every other bus type (maybe excluding VLB) is capable of sane
self-identification.
- - ajax
iD8DBQFBH71RW4otUKDs0NMRAi+zAKDMeftYx9E1yrFnPMKpcgKrLHMryQCaA7Qc
jDP3L4hNVTSUfXV5fiN2ENU=
=M8k3
From andrew at pimlott.net Sun Aug 15 13:06:15 2004
Date: Sun Aug 15 13:06:21 2004
In-Reply-To: <a728f9f90408151155486e0426@mail.gmail.com>
<a728f9f90408151155486e0426@mail.gmail.com>
Message-ID: <20040815200615.GB4574@pimlott.net>
On Sun, Aug 15, 2004 at 02:55:45PM -0400, Alex Deucher wrote:
> On Sun, 15 Aug 2004 04:55:00 -0400, Andrew Pimlott <andrew@pimlott.net> wrote:
> > I just got hooked on the EmulateWheel feature, for which I use
> > EmulateWheelButton 2. But I also like having a third button, and I
> > believe it's possible to have the best of both: If I press button 2 and
> > release it without moving the mouse, it's a button 2 press; otherwise,
> > it's an emulated wheel.
>
> there's a similar patch in bugzilla:
> http://freedesktop.org/bugzilla/show_bug.cgi?id=323
Cool, dueling patches! They have the same goal, but there is a
difference in approaches. Mathias uses a timeout to decide when a click
was intended. I use the lack of motion. His has the advantage that it
can be used reliably with normal mice, where it is hard to keep from
moving while clicking. It has the disadvantage that if one does a very
brief emulated scroll (I sometimes just want to move a line or two), one
might also get an unwanted click. Mathias, I wonder if you have ever
had this problem in practice?
One way to get both advantages might be to have a threshold of pixels
moved while the button was down, below which we create a click. This
could be combined with a timeout: click if the button is released in
time, and the mouse hasn't moved very far. Personally, I find timeouts
somewhat unintuitive, so I would rather just judge by motion. But maybe
this doesn't work for everyone.
Perhaps users of EmulateWheel might think about the options for this
feature between now and when it can be merged. I am willing to refine
the code based on any consensus rearched.
Andrew
From diegocg at teleline.es Sun Aug 15 13:09:11 2004
From: diegocg at teleline.es (Diego Calleja)
Date: Sun Aug 15 13:13:28 2004
Message-ID: <20040815220911.2c2011a4.diegocg@teleline.es>
El Sun, 15 Aug 2004 21:36:27 +0200 "Ronny V. Vindenes" <s864@ii.uib.no> escribi?
:
> > That fixed it for me
> >
>
> But it seems to have introduced or triggered a new bug - with xcompmgr
> running now I get screen corruption mostly in the left hand top corner.
Me too.
Here's a screenshot: http://www.terra.es/personal/diegocg/compositebug.jpg
Date: Sun Aug 15 13:26:57 2004
action...
Message-ID: <E1BwRaT-0000fA-Jm@evo.keithp.com>
> But it seems to have introduced or triggered a new bug - with xcompmgr
> running now I get screen corruption mostly in the left hand top corner.
Yup. I'm working on it.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040815/75df6564/attach
ment.pgp
From sjoerd at luon.net Sun Aug 15 13:54:17 2004
From: sjoerd at luon.net (Sjoerd Simons)
Date: Sun Aug 15 14:02:19 2004
Subject: [Xorg] X.org radeon hangs on startup (PowerPC/iBook2)
In-Reply-To: <411E9FF8.30004@rocklinux-consulting.de>
References: <411E9FF8.30004@rocklinux-consulting.de>
Message-ID: <20040815205416.GA6271@spring.luon.net>
On Sat, Aug 14, 2004 at 02:27:52PM +0000, Ren? Rebe wrote:
> Hi all,
>
> I just tried cvs:head on my iBook2 (Radeon Mobility M7 LW [Radeon
> Mobility 7500]) and had to notice that it already hangs during startup:
I've noticed this some time ago on my powerbook (Radeon 9600) too and reported
a bug with patch[0]. No reaction on it yet though.
Unfortunately while the patch prevents the X server from hanging, it doesn't
make Xorg work me. Need to report a bug about that sometime.
Sjoerd
0: http://freedesktop.org/bugzilla/show_bug.cgi?id=1007
--
"We don't care. We don't have to. We're the Phone Company."
Date: Sun Aug 15 14:50:09 2004
.
In-Reply-To: <E1BwRaT-0000fA-Jm@evo.keithp.com>
References: <E1BwRaT-0000fA-Jm@evo.keithp.com>
Message-ID: <411FDA67.40805@winischhofer.net>
>
>
>>But it seems to have introduced or triggered a new bug - with xcompmgr
>>running now I get screen corruption mostly in the left hand top corner.
>
>
> Yup. I'm working on it.
Seems to be fixed with your latest commit (04/08/15 14:13:11).
Numbers are all back to normal, no screen corruption (except the KDE
issues I reported earlier).
Window shadows are pretty fast. However, switching windows to
transparent (transset) makes this window really slow again. But I guess
this is due to the composition not being accelerated (RENDER hooks not
being called anytime).
Anyway, good work for a day ;)
Thomas
--
Thomas Winischhofer
Vienna/Austria
From louisg00 at bellsouth.net Sun Aug 15 09:41:26 2004
From: louisg00 at bellsouth.net (Louis Garcia)
Date: Sun Aug 15 14:50:48 2004
Subject: [Xorg] Is this the last of the monolithic builds?
Message-ID: <1092588086.2688.8.camel@tiger>
Would this be the last monolithic builds of the xserver as of X11R6.8?
--Thanks
From qbast at go2.pl Sun Aug 15 14:59:31 2004
From: qbast at go2.pl (Jakub Stachowski)
Date: Sun Aug 15 14:59:34 2004
<200408151545.23616.ajax@nwnk.net>
Message-ID: <200408152359.31805.qbast@go2.pl>
Dnia niedziela, 15 sierpnia 2004 21:45, Adam Jackson napisa?:
> On Sunday 15 August 2004 17:40, Kristof Vansant wrote:
> > root@lupus:/home/lupus# lspci | grep VGA
> > 01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti
> > 500] (rev a3)
> >
> > so the driver is nv, I don't understand what the problem is.
>
> Please stop top-posting.
>
> The problem is that we have no way to bind a PCI ID to a driver before the
> driver is loaded. We don't have a database anywhere saying "this chip id
> means i need this driver". Clearly you as a human can look at the pretty
> PCI name and know, but the server isn't that smart yet. What we'd want to
> do is put that list in the driver itself, so when we first dlopen the
> driver we can ask it what PCI IDs it supports.
>
So only PCI bus is important?
> And in fact we have all the necessary information in the drivers already -
> since they all have to check for supported chips somehow - it's just a
> matter of factoring that out into a common data structure and teaching the
> server to read that at module open time.
It could be function - so for example fbdev could check if framebuffer device
is available and report that it supports all devices (if fbdev available) or
none (if not).
>
> The problem here would be stupid buses like ISA, but I'm perfectly willing
> to tell people insane enough to use ISA video cards that they need to
> explicitly specify their driver or else be stuck with vga(4) or vesa(4). I
> think pretty much every other bus type (maybe excluding VLB) is capable of
> sane self-identification.
Some kind of 'priority' field would be useful - so only if specific (for given
card) driver is unavailable, server will fall back to less preferred,
catch-all drivers as vga, vesa or fbdev.
>
> - ajax
> _______________________________________________
> xorg mailing list
From Alan.Coopersmith at Sun.COM Sun Aug 15 15:21:39 2004
Date: Sun Aug 15 15:25:21 2004
Subject: [Xorg] Is this the last of the monolithic builds?
In-Reply-To: <1092588086.2688.8.camel@tiger>
References: <1092588086.2688.8.camel@tiger>
Message-ID: <411FE1F3.9040605@sun.com>
Louis Garcia wrote:
> Would this be the last monolithic builds of the xserver as of X11R6.8?
Good question - I think the best we can say right now is "probably."
(Ignoring bug fix releases in the 6.8.x series which may happen.)
There's a lot of desire to move to the modular tree, but a lot of work
to do to make that happen. The 6.8 release came about from having a
number of new things ready to go and a desire to have a release put
together so distributors could get them into their releases with
code freezes coming up soon - since the modular release isn't ready yet,
that meant another monolithic release. Should we again get into that
situation before the modular tree is ready, it's conceivable we could
do another one.
(There's also a lot of unease about a complete cutover, since it's really
two huge changes, going to a new build system (autotools instead of
imake) and going to a new style of managing the tree (individual modules
instead of one huge monolith). Cutting over successfully will require a
lot of coordination, planning, and work to make everything go smoothly.
Those who want to see this change are strongly encouraged to help in any
way they can, even if it's just testing builds or updating docs on how
to build.)
--
Date: Sun Aug 15 15:33:52 2004
In-Reply-To: <200408152359.31805.qbast@go2.pl>
<200408151545.23616.ajax@nwnk.net>
<200408152359.31805.qbast@go2.pl>
Hash: SHA1
On Sunday 15 August 2004 17:59, Jakub Stachowski wrote:
> Dnia niedziela, 15 sierpnia 2004 21:45, Adam Jackson napisa?:
> > The problem is that we have no way to bind a PCI ID to a driver before
> > the driver is loaded. We don't have a database anywhere saying "this
> > chip id means i need this driver". Clearly you as a human can look at
> > the pretty PCI name and know, but the server isn't that smart yet. What
> > we'd want to do is put that list in the driver itself, so when we first
> > dlopen the driver we can ask it what PCI IDs it supports.
>
> So only PCI bus is important?
PCI encompasses AGP, PCI-X, and PCI Express as well. You can also do sane
device probing on Nubus, Sbus, MCA, in fact just about any bus besides ISA.
> > And in fact we have all the necessary information in the drivers already
> > - since they all have to check for supported chips somehow - it's just a
> > matter of factoring that out into a common data structure and teaching
> > the server to read that at module open time.
>
> It could be function - so for example fbdev could check if framebuffer
> device is available and report that it supports all devices (if fbdev
> available) or none (if not).
I think it makes more sense to consider kernel framebuffer devices as a bus
type, and leave detection to the OS interface.
> > The problem here would be stupid buses like ISA, but I'm perfectly
> > willing to tell people insane enough to use ISA video cards that they
> > need to explicitly specify their driver or else be stuck with vga(4) or
> > vesa(4). I think pretty much every other bus type (maybe excluding VLB)
> > is capable of sane self-identification.
>
> Some kind of 'priority' field would be useful - so only if specific (for
> given card) driver is unavailable, server will fall back to less
> preferred, catch-all drivers as vga, vesa or fbdev.
This makes sense, particularly in the ISA case where we aren't really able to
probe for the device.
- - ajax
iD8DBQFBH+TJW4otUKDs0NMRAsTZAKDooC97L/ay7kW0b7YrttqtIa8HuwCgryqz
X0ASgq2qFR2VfTGlvXR6Ih8=
=DrBH
Date: Sun Aug 15 16:12:48 2004
Some of the points listed here are relevant to autocard detection. I'll
repost this in case some of you missed it. A few of the items on the
list are already coded and being tested.
X on GL will not need hard detection. The GL layer will do it for X.
The GL layer relies on DRM which uses the standard kernel scheme for
matching hardware with drivers.
...................................................................
After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal and there is still disagreement about the exact path to
get there.
This is a first pass for lkml people. I will incorporate comments and
repost for the final pass. I'm sure everyone will let me know if I've
misinterpreted some of the design points.
First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). In
Linux these are currently implemented with the same code. There may be
advantages to splitting the implementation in a future design.
1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
track the boot video device and expose the contents of C000:0 for that
special case. See the lkml thread: Exposing ROM's though sysfs, there
are already proposed patches.
2) VGA control - there needs to be a device for coordinating this. It
would ensure that only a single VGA device gets enabled at a time. It
would also adjust PCI bus routing as needed. It needs commands for
disabling all VGA devices and then enabling a selected one. This device
may need to coordinate with VGA console. You have to use this device
even if you aren't using VGA console since it ensures that only a
single VGA device gets enabled.
Alan Cox: what about hardware that supports multiple vga routers? do we
care?
JS: no design work has been done for this device, what would be it's
major/minor? would this be better done in sysfs?
3) Secondary card reset - Handled by an initial hotplug event. We need
a volunteer to write clean vm86 and emu86 apps for running the ROM
initialization. Resetting needs #1 and #2 to work since resetting a
card will enable it's VGA mode. I have an implementation of this but it
needs a lot of clean up.
4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.
5) Multihead cards will expose one device file per head. Many IOCTLs
exposed by these devices will be common. Some, like mode setting, will
be per head.
6) Mode setting before early user space - this was decided to be a
platform specific problem. With minor adjustment the kernel can be made
to boot without printing anything except errors before early user space
starts. Platform specific code will need to handle these error messages
if any. This includes INT10, Openfirmware, mainframe serial consoles,
VGA mode. Suppressing informatory printing before early user space
starts allows a clean boot straight into graphics mode.
7) Mode setting from normal user space - devices will have a standard
IOCTL accepting a mode string like fbdev currently uses. This IOCTL
will lock the device and optionally trigger a hotplug mode event. Mode
setting for some fixed devices is simple enough to avoid the hotplug
event. In the hotplug event the mode line will be decoded, DDC queried,
etc. Some classes of devices (for example Intel 810,830,915) have to
have their mode set using vm86 and the video BIOS. Others might use a
small C app to query DDC and then use a device specific IOCTL to set
the mode registers. Early boot and normal user space will use the same
hotplug apps so they need to be as small as possible (good luck IA64
and emu86).
8) Merged fbmode - per head mode lists will include merged fb modes if
the other heads aren't in use. Setting a merged fb mode will lock out
the other head devices. It was decided that this was a better design
than having a control device.
9) printk - setting the mode will also record the fb location, size,
stride. Combining this info with the current fbconsole code will allow
printk/oops to print in all modes.
10) a new system console UI is proposed. SysReq blanks the current
screen and replaces it with the system console. System console will
also support runing kdbg. Hit SysReq again and whatever you were doing
is restored. This operation does not change the video mode.
11) OOPs will cause an immediate screen clear and painting of the
system console including the OOPs data. It is not needed to change the
video mode. Further drawing to the screen will be blocked until SysReq
returns to normal operation if possible.
Alan Cox: No consensus on the screen clear bit - there are actually
reasons to argue against it.
JS: Maybe save the contents at OOPs time and hotkey back to it? This
assumes the system is stable enough to do the copy and access the
keyboard. Another idea: start painting the OOPs from the top without
clearing, hope useful userspace data is at the bottom?
Nicolas Mailhot: Don't forget about power management, unblank the
screen and don't let it blank again since you may not get it back.
Graphics mode lets more OOPs info fit.
12) interrupt time printk - certain hardware implements
non-interruptible operations. Most modern hardware does not do this.
For older hardware these non-interruptible operations will need to be
wrapped by the device driver. The complete data needed to finish the
operation will be provided in the IOCTL. Doing this enables an
interrupt time printk to call into the driver, make sure the hardware
is free by completing the pending operation, and then write to the
framebuffer. No older hardware currently implements this protection;
without this protection there is potential for locking the machine.
13) all of the features being discussed are implemented by a single
device driver plus a supporting set of library drivers. Multitasking of
multiple controlling device drivers for a single piece of hardware is
not allowed.
14) A new framebuffer memory manager is needed for mesa GL support. Ian
is working on it. The memory manager will be part of the support
library driver code.
15) Over time user space console will be moved to a model where VT's
are implemented in user space. This allows user space console access to
fully accelerated drawing libraries. This might allow removal of all of
the tty/vc layer code avoiding the need to fix it for SMP.
Alexander E. Patrakov: One more minor problem. We need to ensure
somehow that the "killall5" program from the sysvinit package will not
kill our userspace console daemon at shutdown.
16) accelerated, kernel based console drivers are not easily written in
this model. The only in kernel operations are simple ones like
CR/scroll, clear, print text. It is possible to call existing DRM entry
points from a kernel thread, but the code needed is complex. Note that
only things like printk use this console so is there a real need for
acceleration?
17) A user space console implementation also makes supporting multiple
users on multiple heads/card easier. The kernel will not need to be
modified for multi-user VT support. User mode console allows pretty
text and Asian scripts.
18) A coordinated system for grouping console devices needs to be
designed. This will be bad if each distro does it differently. One
proposal is to use udev to create: /console/1/mouse,
/console/1/keyboard, /console/1/usb_hub, /console/2/mouse,
/console/3/keyboard, /console/4/usb_hub, etc.
Alan Cox: Another is to use namespace mounts
19) SAK - secure attention key. We forgot to talk about this so we need
a design.
Alan Cox: Falls straight out of having the kernel + helper mode setting
20) A PAM login would assign ownership of the console group devices to
the logged in user. A mechanism needs to be designed for assigning
ownership of secondary heads for the merged fb case. X should run as
the logged in user and not require root if the hardware allows.
21) It was also discussed the X should stop implementing OS level
features and instead use the features of the underlying OS. If the
underlying OS is lacking support the support would be implemented in a
library external to X. Examples of moving from X to OS support include:
PCI bus, input, console groupings, etc.
22) A goal this design is to discourage user space video driver
implementations when a kernel one exists. An example of this would be
X's radeon XAA driver. X would instead use the DRM driver via mesa.
23) The old schemes are not going to be removed. If your ancient 2D
card only has an fbdev and XAA driver it will still work. We're not
going to remove old drivers if new ones don't exist. But don't expect
the composting X server to turn your clunker 2D card in to a Radeon
X800.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com
From mfrey at pepper.com Sun Aug 15 17:34:39 2004
From: mfrey at pepper.com (Michael Frey)
Date: Sun Aug 15 17:51:51 2004
Subject: [Xorg] Current CVS version....
Message-ID: <0F1DCBFD-EF1C-11D8-8216-003065B218E0@pepper.com>
From which repository should we be testing from?
I noticed that the xorg cvs tree does not contain kdrive, but the
xserver cvs does not contain the latest composite stuff. Do I pull the
xorg tree then build Xfbdev separate?
Thanks,
Michael
From elanthis at awesomeplay.com Sun Aug 15 17:56:22 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Sun Aug 15 17:56:29 2004
8.0.camel@localhost.localdomain> <1092606043.4735.0.camel@lupus.lupusje.o
rg>
<200408151545.23616.ajax@nwnk.net>
Message-ID: <41200636.5070808@awesomeplay.com>
Adam Jackson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Sunday 15 August 2004 17:40, Kristof Vansant wrote:
>
>
>>root@lupus:/home/lupus# lspci | grep VGA
>>01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti
>>500] (rev a3)
>>
>>so the driver is nv, I don't understand what the problem is.
>>
>>
>
>Please stop top-posting.
>
>The problem is that we have no way to bind a PCI ID to a driver before the
>driver is loaded. We don't have a database anywhere saying "this chip id
>means i need this driver". Clearly you as a human can look at the pretty PCI
>name and know, but the server isn't that smart yet. What we'd want to do is
>put that list in the driver itself, so when we first dlopen the driver we can
>ask it what PCI IDs it supports.
>
>
For what it's worth, I find that solution to be a step backwards. That
means you have to rebuild the entire driver to get a new device working
that the driver is already capable of supporting. A lot of driver
updates to support "new devices" are nothing more than adding IDs to an
array.
Makes a lot more sense to me to keep all the driver/device mappings in
an external set of files, and just have the driver manager (the X
server) figure out which device to load. Plus, as these are external
files, they become a lot easier to use by projects/software other than
the X server itself. Avoid duplication with things like kudzu and
discover databases.
From fxjrlists at yahoo.com.br Sun Aug 15 18:35:59 2004
Date: Sun Aug 15 18:31:23 2004
Subject: [Xorg] where is the i810 driver in cvs?
Message-ID: <41200F7F.3000209@yahoo.com.br>
Hi all,
I'd like to see what are the changes in the i810 driver. As told in
previous messages, it was advised to check the cvs logs. But I can't
find where is the i810 driver sources.
Could you help me?
Thanks in advance.
Regards,
Date: Sun Aug 15 19:03:28 2004
In-Reply-To: <41200636.5070808@awesomeplay.com>
--- Sean Middleditch <elanthis@awesomeplay.com> wrote:
> Adam Jackson wrote:
> >The problem is that we have no way to bind a PCI ID to a driver
> before the
> >driver is loaded. We don't have a database anywhere saying "this
> chip id
> >means i need this driver". Clearly you as a human can look at the
> pretty PCI
> >name and know, but the server isn't that smart yet. What we'd want
> to do is
> >put that list in the driver itself, so when we first dlopen the
> driver we can
> >ask it what PCI IDs it supports.
> >
> >
>
> For what it's worth, I find that solution to be a step backwards.
> That
> means you have to rebuild the entire driver to get a new device
> working
> that the driver is already capable of supporting. A lot of driver
> updates to support "new devices" are nothing more than adding IDs to
> an
> array.
>
> Makes a lot more sense to me to keep all the driver/device mappings
> in
> an external set of files, and just have the driver manager (the X
> server) figure out which device to load. Plus, as these are external
>
> files, they become a lot easier to use by projects/software other
> than
> the X server itself. Avoid duplication with things like kudzu and
> discover databases.
The kernel already provides a mechanism for assigning a new PCI ID to
an existing driver - echo it to /sys/bus/pci/driver/new_id. Kernel
device drivers also contain the list of PCI IDs they support in a
format that a kernel probe can read. All of these problems are solved
once we switch to kernel based drivers. The real problem is X
implementing another device driver system in user space.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
From jserv at linux2.cc.ntu.edu.tw Sun Aug 15 20:44:00 2004
Date: Sun Aug 15 20:44:03 2004
In-Reply-To: <20040813031225.GA17117@linux2.cc.ntu.edu.tw>
<20040813031225.GA17117@linux2.cc.ntu.edu.tw>
On Fri, Aug 13, 2004 at 11:12:25AM +0800, jserv@linux2.cc.ntu.edu.tw wrote:
> I am glad to share my screenshots, and please take a look over:
Newer screenshots about xc-cvs, GNOME, and Chinese environment:
http://stu.csie.ncnu.edu.tw/~kanru.96/gnome1.png
And
http://stu.csie.ncnu.edu.tw/~kanru.96/gnome2.png
Also, we provide Chinese mini How-To for testing cvs version of
Xorg:
http://stu.csie.ncnu.edu.tw/~kanru.96/xorg-mini-howto.html
Thanks for great work!
cheers,
Jim Huang
Date: Sun Aug 15 21:57:17 2004
In-Reply-To: <41200F7F.3000209@yahoo.com.br>
References: <41200F7F.3000209@yahoo.com.br>
Message-ID: <a728f9f9040815215775024a1b@mail.gmail.com>
On Sun, 15 Aug 2004 22:35:59 -0300, Francisco Figueiredo Jr.
>
> Hi all,
>
> I'd like to see what are the changes in the i810 driver. As told in
> previous messages, it was advised to check the cvs logs. But I can't
> find where is the i810 driver sources.
>
> Could you help me?
xorg web cvs access:
http://freedesktop.org/cgi-bin/viewcvs.cgi/?root=xorg
overall changelog:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/ChangeLog?rev=1.285&root=xorg&view
=log
intel chipset DDX changes:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driver
s/i810/?root=xorg
3D drivers:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/extras/Mesa/src/mesa/drivers/dri/?
root=xorg
>
>
> Regards,
>
From kem at freedesktop.org Sun Aug 15 23:02:49 2004
Date: Sun Aug 15 23:02:54 2004
night.
listed below.
Fixed yesterday: 0
Added yesterday: 0
-----------------------------
- Patch supplied and tested
- Testing is underway
- Patch supplied to allow new kbd driver to be:
1. Installed and loaded with its own name (kbd)
2. Installed and loaded with the same name as the older keyboard
driver, but only if UseDeprecatedKeyboardDriver is NO
From lars at trolltech.com Mon Aug 16 02:16:42 2004
Date: Mon Aug 16 02:07:50 2004
Subject: [Xorg] Using transformations in the render extension
Hi,
we did some experimenting trying to use transformations provided by the render
extension on pixmaps. What we found is that they currently are about a factor
of 5 slower than sending the data over to the client, doing the
transformation there and sending it back (for the "nearest" neighbor filter).
I digged a bit through the XServer code, and it seems that we take the worst
possible code path whenever a transformation is involved (going into
fbCompositeGeneral, and using function pointers for all operations).
The other thing I noticed while looking through the code is that PictOpSrc
always seems to go through the fbComposeGeneral method (even without
transformations).
Wouldn't it be worth optimising PictOpSrc without transformations, and both
PictOpOver and PictOpSrc for affine transformations (or at least scaling
operations)?
I know that it would be best if the drivers started supporting these in
hardware, but as it currently looks to me most of them do not have the
support yet, and it would be great if the software fallback would not be
slower than what one can achieve on the client.
Cheers,
Lars
Date: Mon Aug 16 02:41:43 2004
In-Reply-To: <200408161116.42525.lars@trolltech.com>
References: <200408161116.42525.lars@trolltech.com>
On Mon, 2004-08-16 at 02:16, Lars Knoll wrote:
> Hi,
>
> we did some experimenting trying to use transformations provided by the render

> extension on pixmaps. What we found is that they currently are about a factor
> of 5 slower than sending the data over to the client, doing the
> transformation there and sending it back (for the "nearest" neighbor filter).
>
> I digged a bit through the XServer code, and it seems that we take the worst
> possible code path whenever a transformation is involved (going into
> fbCompositeGeneral, and using function pointers for all operations).
>
> The other thing I noticed while looking through the code is that PictOpSrc
> always seems to go through the fbComposeGeneral method (even without
> transformations).
>
> Wouldn't it be worth optimising PictOpSrc without transformations, and both
> PictOpOver and PictOpSrc for affine transformations (or at least scaling
> operations)?
>
> I know that it would be best if the drivers started supporting these in
> hardware, but as it currently looks to me most of them do not have the
> support yet, and it would be great if the software fallback would not be
> slower than what one can achieve on the client.
Your DDX should be handling PictOpSrc in the no-transform, no-repeat,
same-format case by using its normal CopyArea acceleration. XAA was
fixed up to do this for the next release. Repeating 1x1 PictOpSrc
should be done using the normal solid fill code as well (in the absence
of something better, which a general render acceleration might be).
Kdrive does both of these.
There are far too many possible Render combinations to provide optimized
paths for all of them in software (without codegen, which is probably
more work than it's worth). We weren't seeing too much PictOpSrc
before, but now we are with Composite. We weren't seeing much use of
transforms, and now we are seeing some (and will be seeing more and more
for eye-candy things). I expect that as people find more and more neat
effects to do with Render thanks to Composite, we'll have to keep adding
specific case improvements in software unless we improve software
compositing generally so that it's much closer to optimal.
Keith told me his plans for the general compositing code the other day,
involving converting the general code to operate on "patches" instead of
pixels. With that, then we can have a single set of fast vectored IN
handling that operates on patches, two sets of each OP (component-alpha
and non-component-alpha), and patch-loading and -storing functions which
will be able work on the framebuffer *much* faster than currently
possible per-pixel.
Note that I expect to see much more Render acceleration in drivers once
we get an acceleration architecture that's designed with Render in mind.
--
From lars at trolltech.com Mon Aug 16 03:15:38 2004
Date: Mon Aug 16 03:06:44 2004
References: <200408161116.42525.lars@trolltech.com>
<1092649298.33493.56.camel@leguin>
On Monday 16 August 2004 11:41, Eric Anholt wrote:
> On Mon, 2004-08-16 at 02:16, Lars Knoll wrote:
> > Hi,
> >
> > we did some experimenting trying to use transformations provided by the
> > render extension on pixmaps. What we found is that they currently are
> > about a factor of 5 slower than sending the data over to the client,
> > doing the
> > transformation there and sending it back (for the "nearest" neighbor
> > filter).
> >
> > I digged a bit through the XServer code, and it seems that we take the
> > worst possible code path whenever a transformation is involved (going
> > into fbCompositeGeneral, and using function pointers for all operations).
> >
> > The other thing I noticed while looking through the code is that
> > PictOpSrc always seems to go through the fbComposeGeneral method (even
> > without transformations).
> >
> > Wouldn't it be worth optimising PictOpSrc without transformations, and
> > both PictOpOver and PictOpSrc for affine transformations (or at least
> > scaling operations)?
> >
> > I know that it would be best if the drivers started supporting these in
> > hardware, but as it currently looks to me most of them do not have the
> > support yet, and it would be great if the software fallback would not be
> > slower than what one can achieve on the client.
>
> Your DDX should be handling PictOpSrc in the no-transform, no-repeat,
> same-format case by using its normal CopyArea acceleration. XAA was
> fixed up to do this for the next release. Repeating 1x1 PictOpSrc
> should be done using the normal solid fill code as well (in the absence
> of something better, which a general render acceleration might be).
> Kdrive does both of these.
Great if it does. I just couldn't find the code path, as CompositePicture() in
render/picture.c just calls ps->Composite, which I thought would map directly
to fbComposite in fb/fbPict.c for most drivers. In there I couldn't find any
code for PictOpSrc.
> There are far too many possible Render combinations to provide optimized
> paths for all of them in software (without codegen, which is probably
> more work than it's worth). We weren't seeing too much PictOpSrc
> before, but now we are with Composite. We weren't seeing much use of
> transforms, and now we are seeing some (and will be seeing more and more
> for eye-candy things).
That's also a bit a Hen and Egg problem. As long as transforms are slow people
using transforms will probably continue doing them on the client side.
I agree that there are way to many combinations to implement optimised paths
for all of them. I was mainly thinking about the scaling or rotating pixmaps
which is not all that uncommon. I know for example that KDEs style engine
needs this in some places. Currently they keep the image data on the client
side, scale it to the size they need there, and send the transformed pixmap
over to the server for blitting. Most of it doesn't even involve an alpha
channel.
> I expect that as people find more and more neat
> effects to do with Render thanks to Composite, we'll have to keep adding
> specific case improvements in software unless we improve software
> compositing generally so that it's much closer to optimal.
>
> Keith told me his plans for the general compositing code the other day,
> involving converting the general code to operate on "patches" instead of
> pixels. With that, then we can have a single set of fast vectored IN
> handling that operates on patches, two sets of each OP (component-alpha
> and non-component-alpha), and patch-loading and -storing functions which
> will be able work on the framebuffer *much* faster than currently
> possible per-pixel.
That sounds great :)
> Note that I expect to see much more Render acceleration in drivers once
> we get an acceleration architecture that's designed with Render in mind.
I expect this as well. I was mainly thinking about the software fallback.
Thanks for the info,
Lars
From vrihad at softhome.net Fri Aug 13 18:55:31 2004
From: vrihad at softhome.net (Vrihad Shoonya)
Date: Mon Aug 16 03:14:13 2004
Subject: [Xorg] Is kdrive development still on?
Message-ID: <2730.192.168.0.30.1092448531.squirrel@dev.datamax.co.in>
I had sent a query to this list last weekend which is
attached below. But it seems it got lost in the flow:-)
I am getting missing font related error messages when
all font files are present and standard XFree86 works
fine.
Am I posting to the wrong list? If so, please provide
the info of correct list.
-vrihad
-----------last message-------------
I compiled and installed kdrive based Xserver following
the instructions given in the following document.
http://www.freedesktop.org/Software/XserverInstallGuide
Now when I try to run
/usr/kdrive/bin/Xfbdev :0 -fp /usr/X11R6/lib/X11/fonts/misc,
I get an error saying "Could not init font path element
/usr/X11R6/lib/X11/fonts/misc, remoing from list!"
Then the program exits with an error message of failure to
find font 'fixed'. The server does not run without
-fp option either.
I have installed the kdrive in a non-standard location
/usr/kdrive. Also the fonts I am trying to use are from
XFree86 project. Is there any font package specific for
x.org project? Or is there a bug in latest CVS code of
kdrive based Xserver?
I am using gcc 3.2.3 on Linux 2.4.18.
Thanks in advance.
vrihad
From matthew at alledora.co.uk Mon Aug 16 03:26:14 2004
From: matthew at alledora.co.uk (Matthew Walton)
Date: Mon Aug 16 03:47:48 2004
scrollmouse to work
In-Reply-To: <200408151304.32329.nbensa@gmx.net>
.111.camel@localhost.localdomain> <1092566890.3432.4.camel@localhost>
<200408151304.32329.nbensa@gmx.net>
Message-ID: <41208BC6.5060606@alledora.co.uk>
Norberto Bensa wrote:
> Ah ha! Yes. My Intellimouse Explorer also has that configuration:
>
> Driver "mouse"
> Option "Protocol" "ExplorerPS/2"
> Option "Buttons" "7"
> Option "Emulate3Buttons" "Off"
> EndSection
>
> This one is five buttons. Left, right, and middle click. Two buttons on the
> side for back, forward. And the wheel.
My Logitech cordless comfort mouse also behaves like this, except it's
"5 6" as it's only got the one button on the side. Setting the default
to "4 5" would work for people who've got dead standard wheel mice (such
as the original kidney-shaped ones from Microsoft) but increasing
numbers of people seem to have mice with more and more buttons these
days - not to mention these new ones with scroll wheels that lean from
side to side as well!!
That said, it may still be a sensible default.
From elanthis at awesomeplay.com Mon Aug 16 07:01:28 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Mon Aug 16 07:01:38 2004
scrollmouse to work
In-Reply-To: <41208BC6.5060606@alledora.co.uk>
<1092566890.3432.4.camel@localhost> <200408151304.32329.nbensa@gmx.net>
<41208BC6.5060606@alledora.co.uk>
Message-ID: <1092664888.5520.5.camel@support02.civic.twp.ypsilanti.mi.us>
On Mon, 2004-08-16 at 06:26, Matthew Walton wrote:
> My Logitech cordless comfort mouse also behaves like this, except it's
> "5 6" as it's only got the one button on the side. Setting the default
> to "4 5" would work for people who've got dead standard wheel mice (such
> as the original kidney-shaped ones from Microsoft) but increasing
> numbers of people seem to have mice with more and more buttons these
> days - not to mention these new ones with scroll wheels that lean from
> side to side as well!!
>
> That said, it may still be a sensible default.
Most users will be using their distro/OS configuration utilities anyhow,
so long as those have options for "5 wheel mice," "6 wheel mice," and so
on, things should just work.
Alternatively... is the x axis always the last two buttons? I.e., on a
9 button mouse, would you almost always use:
If so, why not just default to using the last two buttons on the mouse?
Also, for USB mice (becoming the most common type of mouse), is it not
possible to query the USB identifier information and consult a mouse
database to get its settings? If it is easy to install new entries
(there should *always* be a simple shell script in PATH to install new
entries), vendors could even ship .xmi (X Mouse Info) files on disks
with their mice, like they do for Windows, and users can open those in
their file managers and have them be installed. That might require a
distro specific tool, but at least it would be possible.
>
> _______________________________________________
> xorg mailing list
--
Sean Middleditch <elanthis@awesomeplay.com>
AwesomePlay Productions, Inc.
From keith at tungstengraphics.com Mon Aug 16 07:25:06 2004
Date: Mon Aug 16 07:25:18 2004
Subject: [Mesa3d-dev] Re: [Xorg] Code freeze extension
In-Reply-To: <411D4875.5050901@tungstengraphics.com>
<1092437137.1072.110.camel@leguin>
Message-ID: <4120C3C2.2020907@tungstengraphics.com>
Brian Paul wrote:
>>
>> At this point, given that the X.Org tree is still monolithic, our Mesa
>> usage is somewhat independent of Mesa releases in my view. I chose to
>> integrate the development branch because of the great advances made in
>> the DRI drivers in general (though we have some issues to resolve still,
>> as bugzilla shows), though I was concerned about using something that
>> wasn't blessed as a release.
>>
>> I would like to continue using the current codebase, though we should
>> probably make it clear in glxinfo (for example) that this is a
>> development branch we're using. That is, unless a release were to
>> happen from the head branch the next couple of days.
>
>
> Well, I could probably make the Mesa 6.1 release this weekend (since I
> was planning on working anyway). I've got some memory leak fixes (see
> bug 1002030) that I haven't checked into the trunk yet (but are checked
> into the mesa_6_0_branch branch). I asked Kevin about checking them in
> but haven't heard back yet.
>
> Does anyone object to taking the trunk code we have today and making the
> 6.1 release? I'm not aware of any loose ends in it at this time.
I think that the strategy of pulling development Mesa into development Xorg
has worked well, and if we can get a new stable Mesa to come out just ahead of
a stable Xorg, all the better.
Maybe we can work towards an informal synchronization of releases in the
future, where as much as is possible and convenient for both projects, we
attempt to do releases at similar times so that there is no more lag than
necessary in getting the code to users?
Keith
Date: Mon Aug 16 07:27:39 2004
In-Reply-To: <a728f9f9040815215775024a1b@mail.gmail.com>
References: <41200F7F.3000209@yahoo.com.br>
<a728f9f9040815215775024a1b@mail.gmail.com>
Message-ID: <4120C769.7010902@yahoo.com.br>
Alex Deucher wrote:
> On Sun, 15 Aug 2004 22:35:59 -0300, Francisco Figueiredo Jr.
> <fxjrlists@yahoo.com.br> wrote:
>
>>Hi all,
>>
>>I'd like to see what are the changes in the i810 driver. As told in
>>previous messages, it was advised to check the cvs logs. But I can't
>>find where is the i810 driver sources.
>>
>>Could you help me?
>
>
> xorg web cvs access:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/?root=xorg
>
> overall changelog:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/ChangeLog?rev=1.285&root=xorg&vi
ew=log
>
> intel chipset DDX changes:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driv
ers/i810/?root=xorg
>
> 3D drivers:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/extras/Mesa/src/mesa/drivers/dri
/?root=xorg
>
>
Hi Alex!
Thank you very much!
Regards,
From d.jacobfeuerborn at conversis.de Mon Aug 16 08:17:52 2004
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Mon Aug 16 08:44:53 2004
References: <1092323016.3250.107.camel@localhost.localdomain> <1092351642.3103
.0.camel@localhost.localdomain> <1092419596.6627.5.camel@twins> <1092425214.3491
.104.camel@localhost.localdomain> <1092435950.21500.7.camel@tentacle125.go
zu.lan>
Message-ID: <4120D020.8020605@conversis.de>
Hi,
I'm testing things on my own setup here right now (AthlonXP 2600+,
nforce2 based mainboard, ATI Radeon 9500pro, 512mb RAM) with mixed
success. What is the proper configuration that *should* give the
mentioned configuration the best possible performance right now (with
enabled composite extension)? Here are the things I'm worrying about
right now:
1) What kind of kernel of kernel config (2.6) do I need? Do I have to
load the "radeon" module? How do I detect from a running X that it is
actually used?
2) What driver should I use? The included "radeon" or "ati"? Should the
binary driver from ATI work too? Would that be the best driver to use?
3) What should I put in the config? Is enabling the GLX extension
necessary to get good 2D performance? (don't care about 3D) What about
the DRI extension?
4) What steps should I perform to make sure X actually makes use of the
proper drivers and config options? (eg glxinfo, dpyinfo, etc.)
I'm trying to avoid filing bogus performance/bug reports based on a
faulty configuration. So far I have seen rendering errors, slow
performance and a freeze of the machine as soon as I start "glxinfo"
when using the ATI binary drivers. This is with a cvs checkout from
yesterday.
Date: Mon Aug 16 09:22:08 2004
Subject: [Xorg] Revision of Appendix A of the X11 Protocol Spec: KEYSYM
Encoding
Message-ID: <E1BwkF7-0005Sj-00@mta1.cl.cam.ac.uk>
I have substantially revised and updated the long neglected KEYSYM
Encoding specification in Appendix A of the X11 Protocol Standard. The
result, which I propose for inclusion into the next X.Org release,
is on
http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms.pdf
The troff source to replace xc/doc/specs/XProtocol/X11.keysyms is on
http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms
Changes in a nutshell:
- Added definition of Unicode-mapped keysyms 0x01000100 to 0x0110ffff
- Restructuring of text, with separate sections for
- Special keysyms
- Latin-1 keysyms
- Unicode keysyms
- Function keysyms
- Vendor keysyms
- Legacy keysyms
- Addition of Unicode cross-reference column to Legacy keysym table
- Added some words on long-term depreciation of some of the Legacy
keysyms (Currency, Special, etc.).
- Addition of the 0xFExx keysyms (Keyboard (XKB) Extention) from
<X11/keysymdef.h>, which were missing so far completely from the
standard.
- Replaced the archaic ISO/ECMA 16/16 notation with more useful
contemporary hexadecimal numbers
- Updated the character names to latest edition of ISO 8859 (which now uses
the ISO 10646 names)
- Removed some long obsolete and irrelevant text (e.g. the section sign vs.
paragraph sign vs. pilcrow naming discussion), and rephrased other parts
to give more modern examples.
- Added keysyms
0x06ad Ukrainian_ghe_with_upturn
0x06bd Ukrainian_GHE_WITH_UPTURN
0xfe60 dead_belowdot
0xfe61 dead_hook
0xfe62 dead_horn
from Xfree86 <X11/keysymdef.h>.
Still to do:
- Investigate the semantics of the added "Keyboard (XKB) Extention"
set.
E.g., some of these seem to come from ISO 9995-7, but cross-referencing
with that document did not give a flawless match. Any additional
information on that topic are highly welcome. Who did add the
"Keyboard (XKB) Extention" keysyms, and when. Is there any additional
background documentation about the meaning of these keysyms? Are they
all actually used and needed?
- Look at Microsoft's recent Multimedia/Internet function keys, which are
in part already covered in XFree86 vendor extensions, whether/how these
should be moved into the X11 standard.
A matching updated keysymdef.h proposal is on
http://www.cl.cam.ac.uk/~mgk25/ucs/keysymdef.h
Comments and reviews welcome!
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Date: Mon Aug 16 09:35:13 2004
Subject: [Xorg] Re: Revision of Appendix A of the X11 Protocol Spec: KEYSYM
Encoding
In-Reply-To: <E1BwkF7-0005Sj-00@mta1.cl.cam.ac.uk>
References: <E1BwkF7-0005Sj-00@mta1.cl.cam.ac.uk>
Message-ID: <4120E243.2070101@sun.com>
Markus Kuhn wrote:
> I have substantially revised and updated the long neglected KEYSYM
> Encoding specification in Appendix A of the X11 Protocol Standard. The
> result, which I propose for inclusion into the next X.Org release,
> is on
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms.pdf
While this looks good at a first glance, I think at this point it will
have to wait for the release after X11R6.8 since there's simply not time
for everyone to review it in the week remaining to the planned release
of R6.8.
--
Date: Mon Aug 16 09:39:26 2004
Encoding
In-Reply-To: <E1BwkF7-0005Sj-00@mta1.cl.cam.ac.uk>
Message-ID: <a728f9f904081609396c54602c@mail.gmail.com>
On Mon, 16 Aug 2004 17:21:52 +0100, Markus Kuhn
<markus.kuhn@cl.cam.ac.uk> wrote:
> I have substantially revised and updated the long neglected KEYSYM
> Encoding specification in Appendix A of the X11 Protocol Standard. The
> result, which I propose for inclusion into the next X.Org release,
> is on
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms.pdf
>
> The troff source to replace xc/doc/specs/XProtocol/X11.keysyms is on
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms
Please post this as a bug in xorg bugzilla so it can be tracked an
properly integrated:
http://bugs.freedesktop.org
Alex
>
> Changes in a nutshell:
>
> - Added definition of Unicode-mapped keysyms 0x01000100 to 0x0110ffff
>
> - Restructuring of text, with separate sections for
>
> - Special keysyms
> - Latin-1 keysyms
> - Unicode keysyms
> - Function keysyms
> - Vendor keysyms
> - Legacy keysyms
>
> - Addition of Unicode cross-reference column to Legacy keysym table
>
> - Added some words on long-term depreciation of some of the Legacy
> keysyms (Currency, Special, etc.).
>
> - Addition of the 0xFExx keysyms (Keyboard (XKB) Extention) from
> <X11/keysymdef.h>, which were missing so far completely from the
> standard.
>
> - Replaced the archaic ISO/ECMA 16/16 notation with more useful
> contemporary hexadecimal numbers
>
> - Updated the character names to latest edition of ISO 8859 (which now uses
> the ISO 10646 names)
>
> - Removed some long obsolete and irrelevant text (e.g. the section sign vs.
> paragraph sign vs. pilcrow naming discussion), and rephrased other parts
> to give more modern examples.
>
> - Added keysyms
>
> 0x06ad Ukrainian_ghe_with_upturn
> 0x06bd Ukrainian_GHE_WITH_UPTURN
> 0xfe60 dead_belowdot
> 0xfe61 dead_hook
> 0xfe62 dead_horn
>
> from Xfree86 <X11/keysymdef.h>.
>
> Still to do:
>
> - Investigate the semantics of the added "Keyboard (XKB) Extention"
> set.
>
> E.g., some of these seem to come from ISO 9995-7, but cross-referencing
> with that document did not give a flawless match. Any additional
> information on that topic are highly welcome. Who did add the
> "Keyboard (XKB) Extention" keysyms, and when. Is there any additional
> background documentation about the meaning of these keysyms? Are they
> all actually used and needed?
>
> - Look at Microsoft's recent Multimedia/Internet function keys, which are
> in part already covered in XFree86 vendor extensions, whether/how these
> should be moved into the X11 standard.
>
> A matching updated keysymdef.h proposal is on
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/keysymdef.h
>
> Comments and reviews welcome!
>
> Markus
>
> --
> Markus Kuhn, Computer Laboratory, University of Cambridge
> http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
>
> _______________________________________________
> xorg mailing list
>
Date: Mon Aug 16 09:44:52 2004
Encoding
In-Reply-To: <a728f9f904081609396c54602c@mail.gmail.com>
<a728f9f904081609396c54602c@mail.gmail.com>
Reminds me someone might want to apply bug #1075's patch to the
Xorg tree at some point since the shipped files contain invalid unicode
symbols (someone truncated the 3byte ones at some point)
http://bugs.xfree86.org/attachment.cgi?id=976&action=view
Date: Mon Aug 16 10:17:17 2004
Hash: SHA1
>
Just saw this one scroll by on #xorg, shows off transset nicely:
http://www.itech.ee/sn4ip3r/xorg_true_alphatrans.png
- - ajax
iD8DBQFBIOhCW4otUKDs0NMRAj2FAJ0aHk9F1jQR08kZdY6pfyp8rGvS4gCfcaan
pS9sds4BP16b7mj9in/twWI=
=YvJI
Date: Mon Aug 16 10:40:01 2004
Encoding
In-Reply-To: Your message of "Mon, 16 Aug 2004 12:39:23 EDT."
<a728f9f904081609396c54602c@mail.gmail.com>
Message-ID: <E1BwlSc-0006Sa-00@mta1.cl.cam.ac.uk>
Alex Deucher wrote on 2004-08-16 16:39 UTC:
> > http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms.pdf
> > http://www.cl.cam.ac.uk/~mgk25/ucs/X11.keysyms
>
> Please post this as a bug in xorg bugzilla so it can be tracked an
> properly integrated:
> http://bugs.freedesktop.org
I've added it to
There is also a wiki page on the subject on
http://freedesktop.org/XOrg/KeySyms
Markus
--
From morphie at unravel-music.nl Mon Aug 16 10:15:58 2004
Date: Mon Aug 16 10:43:52 2004
In-Reply-To: <0F1DCBFD-EF1C-11D8-8216-003065B218E0@pepper.com>
References: <0F1DCBFD-EF1C-11D8-8216-003065B218E0@pepper.com>
On Monday 16 August 2004 02:34, Michael Frey wrote:
> From which repository should we be testing from?
>
> I noticed that the xorg cvs tree does not contain kdrive, but the
> xserver cvs does not contain the latest composite stuff. Do I pull the
> xorg tree then build Xfbdev separate?
If you want to test X.org with composite then use this howto:
good luck,
- Dennie
From skatan at despammed.com Mon Aug 16 11:20:47 2004
From: skatan at despammed.com (Ditch Digger)
Date: Mon Aug 16 11:25:20 2004
Subject: [despammed] Re: [Xorg] Solicitation of screen shots of new
facilities in action...
<200408161300.52172.ajax@nwnk.net>
Message-ID: <4120FAFF.8010405@despammed.com>
I'm using latest CVS, ATI RADEO 9200 128Mb, amd athlon 2000+ on FC2 e
gnome 2.6.
I'm using xcmpmgr without shadow or any eye-candy just composite 'cause
I hate the ghost effect.
I notced a performance downgrade after a while of usage. At the
beginning of the session everything run fine and the speed is pretty
good then it's gettitn slower.
From de_lupus at pandora.be Mon Aug 16 13:50:48 2004
Date: Mon Aug 16 11:36:38 2004
Subject: [Xorg] is it possible to have keyboard layout detection?
is it possible to have keyboard layout detection?
I was wondering if new usb keyboards have some sort of identification
onboard.
--
From ryan.gallagher at comcast.net Mon Aug 16 12:01:02 2004
Date: Mon Aug 16 12:05:20 2004
<200408161300.52172.ajax@nwnk.net>
S'more screenshots. These won't likely be staying on my site, so any
you want to use feel free to grab and put anywhere you like.
http://ruinaudio.com/xorg-composite-mplayer.png
http://ruinaudio.com/xorg-composite-mplayer2.png
http://ruinaudio.com/xorg-composite-mplayer3.png
The third may not be the best for public consumption, it shows my cpu
cranking away at 86%
-ry
Date: Mon Aug 16 13:03:17 2004
In-Reply-To: Your message of "Mon, 16 Aug 2004 20:50:48 -0000."
Message-ID: <E1BwnhJ-00084G-00@mta1.cl.cam.ac.uk>
Kristof Vansant wrote on 2004-08-16 20:50 UTC:
> is it possible to have keyboard layout detection?
>
> I was wondering if new usb keyboards have some sort of identification
> onboard.
In theory, the USB HID spec does define an integer number to identify
one of a few dozen predefined keyboard layouts. In practice, keyboard
manufacturers leave that field undefined, because they traditionally
used the same microcontroller ROM mask in all their PC keyboards and see
at present no market forces to convince them to add the expense of
paying for either several ROM masks, EEPROM, or wire bridges to tell the
keyboard what its layout is.
http://www.usb.org/developers/hidpage/
http://www.usb.org/developers/devclass_docs/HID1_11.pdf
http://www.usb.org/developers/devclass_docs/Hut1_11.pdf
Look in the above HID spec at page 22 for the field bCountryCode and at
the table on page 23. Have you ever seen a keyboard that reports there a
value other than 0x00?
Also look at the Hut spec at pages 53-60. USB reinvented something like
keysyms, just much worse! USB HID device descriptor data is all
disappointingly messy, so it is no surprise that nobody bothers
implementing it properly. Have you ever seen a keyboard that contains a
descriptor table, which key has which Unicode character on its keycap?
It would be so nice and simple, wouldn't it?
Markus
--
Date: Mon Aug 16 13:16:02 2004
Message-ID: <412115FE.70601@Sun.COM>
Kristof Vansant wrote:
> is it possible to have keyboard layout detection?
>
> I was wondering if new usb keyboards have some sort of identification
> onboard.
I don't know about commodity usb keyboards - Sun USB keyboards
identify which international layout they have and Sun's X server
uses that to identify the layout. I've ported that to the Xorg
server for Solaris platforms, as part of the kbd driver work I've
been doing - I hope to get that finished and ready to commit sometime
after the 6.8 release. Unfortunately, I don't think that will help
any other platforms since it relies on ioctls in the Solaris kbd
drivers.
--
Date: Mon Aug 16 16:32:35 2004
Subject: [Xorg] Code freeze and first release candidate tagged
The code freeze is now in effect. This means that only documentation
changes and approved bug fixes are allowed to be checked in. If a bug
is found in the code, the process that was decided upon at the release
wranglers meeting is to:
1. Enter the problem into bugzilla (with an associated patch that fixes
the problem, if possible)
2. Send e-mail to the xorg@freedesktop.org list with the bugzilla bug
number to let everyone know that there is a potential blocker
The bug will then be reviewed and if approved, the release manager will
check in the patch. This applies to all code changes. Documentation
only changes are still allowed to be checked in directly.
The first release candidate has been tagged (XORG-6_7_99_901), and we
would like to ask that everyone please test this out. Also, those of
you who are building test packages, please build new packages for this
release candidate for people to test. Thanks!
Date: Mon Aug 16 16:47:34 2004
Subject: [Xorg] Re: Code freeze and first release candidate tagged
Message-ID: <41214793.4000001@Sun.COM>
The current tree does not build on Solaris/sparc. I've filed this
bug to cover it:
The patch attached to that bug fixed the errors so the build completed,
I'm testing a full make World now to make sure it got all the errors.
The patch only affects Imakefiles and only for the SPARC platform, so
there should be little risk of breaking any other platforms.
Any objections to this patch?
--
From hiryu at audioseek.net Mon Aug 16 17:00:14 2004
Date: Mon Aug 16 16:47:37 2004
Message-ID: <1092700814.18924.5.camel@heilong.lan.nerv>
Hello,
I'm finding this howto helpful:
However, how do I tell it where to find includes? Is there something I
can put into host.def?
I'm attempting to build this on FreeBSD 5.2.1
Thanks.
-Cameron
From Stuart.Kreitman at Sun.COM Mon Aug 16 16:55:15 2004
Date: Mon Aug 16 16:55:52 2004
In-Reply-To: <41214793.4000001@Sun.COM>
References: <20040816233226.GA23614@kem.org> <41214793.4000001@Sun.COM>
Do you have a sense for how general the condition is?
Does everyone outside of SUN use gcc, and if so, would you write an
internal bug to ask our code tools to increase the PIC table?
Question for other readers: Anyone using other than GNU tools?
skk
> The current tree does not build on Solaris/sparc. I've filed this
> bug to cover it:
>
> The patch attached to that bug fixed the errors so the build completed,
> I'm testing a full make World now to make sure it got all the errors.
> The patch only affects Imakefiles and only for the SPARC platform, so
> there should be little risk of breaking any other platforms.
>
> Any objections to this patch?
>
--
Stuart Kreitman
Sun Microsystems Inc. - X Window System Development
desk: 650 786-5106, fax: -0670 cell: 650 575-7772 stuart.kreitman@sun.com
From mfrey at pepper.com Mon Aug 16 16:58:31 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Aug 16 16:58:38 2004
In-Reply-To: <1092700814.18924.5.camel@heilong.lan.nerv>
References: <1092700814.18924.5.camel@heilong.lan.nerv>
Message-ID: <2CF51EE8-EFE0-11D8-A38B-003065B218E0@pepper.com>
Thanks,
This is helpful, however I need to build Xfbdev. Does this tree
include this?
Michael
On Aug 16, 2004, at 8:00 PM, Cameron wrote:
> Hello,
>
> I'm finding this howto helpful:
> http://ruinaudio.com/xorg-cvs-howto.txt
>
> However, how do I tell it where to find includes? Is there something I
> can put into host.def?
> I'm attempting to build this on FreeBSD 5.2.1
>
> Thanks.
>
> -Cameron
>
> _______________________________________________
> xorg mailing list
From david at fubar.dk Mon Aug 16 16:56:06 2004
From: david at fubar.dk (David Zeuthen)
Date: Mon Aug 16 17:05:30 2004
scrollmouse to work
In-Reply-To: <1092664888.5520.5.camel@support02.civic.twp.ypsilanti.mi.us>
<1092566890.3432.4.camel@localhost> <200408151304.32329.nbensa@gmx.net>
<41208BC6.5060606@alledora.co.uk>
<1092664888.5520.5.camel@support02.civic.twp.ypsilanti.mi.us>
On Mon, 2004-08-16 at 10:01 -0400, Sean Middleditch wrote:
> Also, for USB mice (becoming the most common type of mouse), is it not
> possible to query the USB identifier information and consult a mouse
> database to get its settings? If it is easy to install new entries
> (there should *always* be a simple shell script in PATH to install new
> entries), vendors could even ship .xmi (X Mouse Info) files on disks
> with their mice, like they do for Windows, and users can open those in
> their file managers and have them be installed. That might require a
> distro specific tool, but at least it would be possible.
>
This is exactly what HAL is about : associating arbitrary information
with hardware devices. I'm not saying X.org should depend on HAL, not at
all (in fact I wouldn't object to it), but it would fit very nicely with
Kristian H?gsberg's X Input Hotplug work [1], insofar that a process
external to the X server can add and remove input devices and specify
their capabilities. See [2] for an example of a device information file.
Perhaps the device information for a mouse would look like this
<?xml version="1.0" encoding="ISO-8859-1"?>

<deviceinfo version="0.2">
<device>
<match key="info.bus" string="usb">
<match key="usb.vendor_id" int="0x066f">
<match key="usb.product_id" int="0x8000">
<merge key="input.num_buttons" type="int">9</merge>

</match>
</match>
</match>
</device>
</deviceinfo>

although, IIRC, for number of mouse buttons you can actually extract
something somewhat meaningful from the USB device itself.
David
[1] : http://freedesktop.org/XOrg/XInputHotplug
[2] : http://freedesktop.org/~david/hal-spec/hal-spec.html#spec-device-info
Date: Mon Aug 16 17:23:07 2004
<41214963.5000903@Sun.COM>
Hash: SHA1
On Monday 16 August 2004 19:55, Stuart Kreitman wrote:
> Do you have a sense for how general the condition is?
> Does everyone outside of SUN use gcc, and if so, would you write an
> internal bug to ask our code tools to increase the PIC table?
>
> Question for other readers: Anyone using other than GNU tools?
#1102 and #1103 would indicate that the AIX compiler is also used. I'd also
expect the Intel compiler to be used somewhere.
For people using other than the Sun or GNU compilers (or switch-compatible
compilers), could you please take a look at bug #1054 and let me know how
your compiler pronounces -nostdlib? In order to keep dlloader modules
portable between machines of the same binary format, we can't let them link
against the system libc or libdl.
I suppose you only need to care about #1054 if your platform uses the module
loader.
- - ajax
iD8DBQFBIU5TW4otUKDs0NMRAkYqAJ4ne0Vcp44rGvo2rpNAQHDT6WHZvwCePTeL
7FlLU3UlJ3q2D28yHrVYRws=
=1tyc
Date: Mon Aug 16 17:42:31 2004
<41214963.5000903@Sun.COM>
Stuart Kreitman wrote:
> Does everyone outside of SUN use gcc, and if so, would you write an
> internal bug to ask our code tools to increase the PIC table?
They'd close it as "RTFM". If your code uses more than 2048
symbols on SPARC, you need to use -KPIC (Sun cc) or -fPIC (gcc),
instead of the -Kpic/-fpic used by default in the X Imake configs.
The fix here is simply to use the right set of PIC flags for the
GL libraries. (I fixed this before, but it seems to have gotten
lost in the Mesa 6 import and code reorganization.)
--
Date: Mon Aug 16 17:51:05 2004
Subject: [Xorg] glitz config issue on 'PTHREADS'
When running autogen.sh for glitz I'm seeing the following warning and
errors:
{bryce@blackwold} ~/src/Cairo/glitz (104): ./autogen.sh
./autogen.sh: Note: `./configure' will be run with no arguments.
If you wish to pass any to it, please specify them on the
`./autogen.sh' command line.
./autogen.sh: running `libtoolize --copy --force'
Putting files in AC_CONFIG_AUX_DIR, `config'.
./autogen.sh: running àclocal'
./autogen.sh: running àutoheader'
configure.in:92: warning: AC_TRY_RUN called without default to allow cross compi
ling
/usr/bin/autoheader-2.13: Symbol `PTHREADS' is not covered by /usr/share/autocon
f/acconfig.h
/usr/bin/autoheader-2.13: Symbol `XTHREADS' is not covered by /usr/share/autocon
f/acconfig.h
What should I be doing to make it configure?
Thanks,
Bryce
Date: Mon Aug 16 21:15:02 2004
Subject: [Xorg] Support of ancient servers in Xorg tree?
The tree still contains rudimentary support for building ancient
servers such as the old Xdec, Xsun, Xhp, etc. How much do we
care about this? Should it just be put in the release notes that
they no longer work?
I was doing a test build on Solaris SPARC this evening and forgot
to set the BuildXFree86OnSparcSunOS flag, so it defaulted to building
Xsun instead of Xorg. This failed miserably due to various damage
from Damage.
First it wouldn't link, since miext/damage/libdamage.a wasn't built
since that was only added to some X server targets in
xc/programs/Xserver/Imakefile. Adding it didn't help because that
won't build unless PIXPRIV is defined to give devPrivates in pixmaps,
which is only set in xorg.cf, xfree86.cf, and cygwin.cf. Trying to
set BuildDamage NO and not build miext/damage failed because then
misprite in libmi can't find the Damage functions it needs, since
those weren't #ifdef'ed in.
With enough work, this can all be fixed, but the question is, is it
worth it? I doubt these ancient servers will be carried over to the
modular tree - does anyone still use them today?
(If I were going to try to fix, I think the best way out of the above
mess is to define PIXPRIV by default and build miext/damage for all
servers instead of just the few that build it now. #ifdef DAMAGE
around the libmi calls to the Damage functions would also be good.
I haven't followed through on that to see if it works or not though.
I don't think we have any spare machines running that still have
hardware old enough to use the Xsun server from this tree - we could
dig some out of storage, but I've got much better uses of my time
than that.)
--
Date: Mon Aug 16 22:38:19 2004
night.
listed below.
Fixed yesterday: 8
Added yesterday: 3
-----------------------------
- Fix has been checked into Mesa CVS
- Eric Anholt has permission to merge changes from Mesa CVS
- Race condition related to bug #770
- Will test after changes are merged in from Mesa CVS
* Bug #1099: Placeholder for for all bugs "held open" but not blocking
- Each of these could use more investigation
* Bug #1104: Won't build on Solaris/SPARC
- Patch supplied and reviewed
- Waiting for new patch to review
Date: Mon Aug 16 22:42:14 2004
Subject: [Xorg] Re: Xorg tinderbox status
In-Reply-To: <20040817035019.GB4373@async.com.br>
On Tue, 17 Aug 2004, Christian Robottom Reis wrote:
> On Mon, Aug 09, 2004 at 10:20:39AM -0700, Bryce Harrington wrote:
> > + Add Bonzai
> > + Investigate how to get historical data from it
>
> Are we ready to do this? I chatted very very briefly with Daniel about
> this in Oxford but left this dangling for this week[end?].
I'd say the time's ripe for it. :-)
> > + xfw4
> > + x11perf
> > + rendertest.
>
> - Has anyone tracked down how hard or easy it is to get these running?
Yeah, I've been playing with various bits, and in fact was just playing
with rendercheck about an hour ago. 'rendertest' is part of Cairo, but
I think I must have typoed it in the list above - 'rendercheck' is the
thing we want. It pops up a little window that flashes colors for a
while, and prints out stuff like this:
src: 1x1R r8g8b8, mask: 10x10 r8g8b8, dst: r8g8b8 window
ConjointXor CA composite test error of 64.0000 at (0, 0) --
got: 0.00 1.00 0.00 1.00
expected: 0.00 0.00 0.00 1.00
src color: 0.00 1.00 0.00 1.00
msk color: 0.00 1.00 0.00 1.00
dst color: 0.00 1.00 0.00 1.00
src: 10x10 r8g8b8, mask: 1x1R r8g8b8, dst: r8g8b8 window
ConjointXor CA composite test error of 64.0000 at (0, 0) --
got: 0.00 1.00 0.00 1.00
expected: 0.00 0.00 0.00 1.00
src color: 0.00 1.00 0.00 1.00
msk color: 0.00 1.00 0.00 1.00
dst color: 0.00 1.00 0.00 1.00
I don't know how to interpret those results, though, and suspect that
like usual the value is in the analysis here...
> - Are they reasonable pre-checkin requirements, or do they run in
> geological time?
rendercheck took a few minutes to run. Unless there's a way to boil
down the above data into a yea/nay type value I don't think they're
useful as pre-checkin requirements.
> - How easy is it to fire them up and grep through the output to
> guess for errors and warnings?
rendercheck is easy to fire up - there's no supported args. The output
I'm not certain about though.
Bryce
Date: Mon Aug 16 23:05:25 2004
Subject: [Xorg] Tinderbox status
There are four boxes still performing tinderbox test runs:
alanc SolarisX86 - Error in xpawhelloworld.c finding an include file for
defining symbol XawNcurrPageNumInJob.
cl012 Debian unstable - Good
mh OpenBSD i386 - Good
reed.rainer NetBSD - Good
Bryce
Date: Tue Aug 17 00:55:57 2004
Subject: [Xorg] Xvfb + Xnest broken
Hi
Looks like Xnest and Xvfb are currently broken. Anybody who can
reproduce this? Maybe I've built something stupid?
--> Bugs #1091/#1092
Should these treated as blocker bugs?
BTW, I think verification if Xvfb still works after the build could be
easily done with a tinderbox setup. Xnest as well when started on Xvfb
...
Stefan
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
Date: Tue Aug 17 01:22:24 2004
On Mon, 16 Aug 2004, Kevin E Martin wrote:
> 1. Enter the problem into bugzilla (with an associated patch that fixes
> the problem, if possible)
> 2. Send e-mail to the xorg@freedesktop.org list with the bugzilla bug
> number to let everyone know that there is a potential blocker
CVS does not build on cygwin
Missing SharedXevieReqs on cygwin
bye
ago
--
Date: Tue Aug 17 03:16:06 2004
On Mon, 16 Aug 2004, Kevin E Martin wrote:
the xprint change has minor problems on cygwin
simple fix: change order of libraries
--
From anderson at netsweng.com Tue Aug 17 03:56:53 2004
Date: Tue Aug 17 04:02:02 2004
References: <41218642.2040806@Sun.COM>
Message-ID: <Pine.LNX.4.58.0408170653450.2750@trantor.stuart.netsweng.com>
I think it is up to the vendors that provided these DDX to decide what
their status is (ie it's your call). Fix it, turn it off, or rip it out.
Like Mike said, if it stays in, it should get a tinderbox to prove it at
least builds ok. There should be a row for it in the Release Readiness Table
if you want it.
On Mon, 16 Aug 2004, Alan Coopersmith wrote:
> The tree still contains rudimentary support for building ancient
> servers such as the old Xdec, Xsun, Xhp, etc. How much do we
> care about this? Should it just be put in the release notes that
> they no longer work?
>
Stuart
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From keith at tungstengraphics.com Tue Aug 17 04:26:10 2004
Date: Tue Aug 17 04:26:16 2004
In-Reply-To: <Pine.LNX.4.58.0408170653450.2750@trantor.stuart.netsweng.com>
<Pine.LNX.4.58.0408170653450.2750@trantor.stuart.netsweng.com>
Message-ID: <4121EB52.6030407@tungstengraphics.com>
Stuart Anderson wrote:
> I think it is up to the vendors that provided these DDX to decide what
> their status is (ie it's your call). Fix it, turn it off, or rip it out.
> Like Mike said, if it stays in, it should get a tinderbox to prove it at
> least builds ok. There should be a row for it in the Release Readiness Table
> if you want it.
>
Hmm. I'd prefer to see that differently - the presumption should be that the
code should be ripped out unless somebody steps up and (a) protests and (b) is
seen to demonstrate willingness to maintain the code. I don't see any value
in keeping broken code in the tree otherwise. If someone wants it back in the
future, it will still be in the repository (just not visible on the head).
Otherwise, we're all tiptoe-ing around trying not to offend people who
probably don't exist & if they do are much more interested in other stuff.
Keith
Date: Tue Aug 17 04:51:11 2004
In-Reply-To: <4121EB52.6030407@tungstengraphics.com>
<4121EB52.6030407@tungstengraphics.com>
I didn't mean to imply that we can't get rid of orphaned code, just that
since the "owner" of this code is present, and participating, it should
be their call as to what happens to it. If it stays, then it should be
maintained in the same manner as everything else that stays.
Changes to common code requires concensus. Vendor specific code,
however, should probably be the responsibility of that vendor.
On Tue, 17 Aug 2004, Keith Whitwell wrote:
> Stuart Anderson wrote:
> > I think it is up to the vendors that provided these DDX to decide what
> > their status is (ie it's your call). Fix it, turn it off, or rip it out.
> > Like Mike said, if it stays in, it should get a tinderbox to prove it at
> > least builds ok. There should be a row for it in the Release Readiness Table
> > if you want it.
> >
>
> Hmm. I'd prefer to see that differently - the presumption should be that the
> code should be ripped out unless somebody steps up and (a) protests and (b) is
> seen to demonstrate willingness to maintain the code. I don't see any value
> in keeping broken code in the tree otherwise. If someone wants it back in the
> future, it will still be in the repository (just not visible on the head).
>
> Otherwise, we're all tiptoe-ing around trying not to offend people who
> probably don't exist & if they do are much more interested in other stuff.
>
> Keith
>
Stuart
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From thomas at winischhofer.net Tue Aug 17 05:19:25 2004
Date: Tue Aug 17 05:21:18 2004
Message-ID: <4121F7CD.7080909@winischhofer.net>
> Yeah, I've been playing with various bits, and in fact was just playing
> with rendercheck about an hour ago. 'rendertest' is part of Cairo, but
> I think I must have typoed it in the list above - 'rendercheck' is the
> thing we want. It pops up a little window that flashes colors for a
> while, and prints out stuff like this:
>
> src: 1x1R r8g8b8, mask: 10x10 r8g8b8, dst: r8g8b8 window
> ConjointXor CA composite test error of 64.0000 at (0, 0) --
> got: 0.00 1.00 0.00 1.00
> expected: 0.00 0.00 0.00 1.00
> src color: 0.00 1.00 0.00 1.00
> msk color: 0.00 1.00 0.00 1.00
> dst color: 0.00 1.00 0.00 1.00
> src: 10x10 r8g8b8, mask: 1x1R r8g8b8, dst: r8g8b8 window
> ConjointXor CA composite test error of 64.0000 at (0, 0) --
> got: 0.00 1.00 0.00 1.00
> expected: 0.00 0.00 0.00 1.00
> src color: 0.00 1.00 0.00 1.00
> msk color: 0.00 1.00 0.00 1.00
> dst color: 0.00 1.00 0.00 1.00
>
> I don't know how to interpret those results, though, and suspect that
> like usual the value is in the analysis here...
rendercheck checks RENDER using various PictOps and various texture formats.
The results you get mean that several pixels of the RENDERed result
don't match the expected result. For each wrongly rendered pixel a table
like this is generated:
R G B A
> got: 0.00 1.00 0.00 1.00
> expected: 0.00 0.00 0.00 1.00
> src color: 0.00 1.00 0.00 1.00
> msk color: 0.00 1.00 0.00 1.00
> dst color: 0.00 1.00 0.00 1.00
1.0 means "white" (ie 255 in 8bit-per-colorchannel-mode), 0.0 means "black".
"Got" is the result from a GetImage call and evaluating the pixel
colors, ie the actual result of the RENDER operation (whose operation is
described in the line above the table)
"expected" is what the pixel's color channels should be
"src", "msk", "dst" are the source, mask and destination colors.
Seeing such a table means that RENDER did not render correctly. Such
errors should not occure if the driver in use has no RENDER
acceleration. If it does, it means that the driver's RENDER acceleration
is broken.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From rjw57 at hermes.cam.ac.uk Tue Aug 17 05:06:31 2004
From: rjw57 at hermes.cam.ac.uk (Rich Wareham)
Date: Tue Aug 17 05:23:40 2004
Subject: [Xorg] [PATCH] Stop faded windows disappearing when mapped with
xcompmgr
Message-ID: <20040817120631.GA21735@hermes.cam.ac.uk>
This is a trivial little patch to make sure things like Gtk menus don't
disappear when fade is turned on in xcompmgr. No idea if this is the
'proper' fix but it works for me.
--- xcompmgr.c 14 Aug 2004 21:39:51 -0000 1.26
+++ xcompmgr.c 17 Aug 2004 12:02:22 -0000
@@ -197,6 +197,8 @@
{
fade **prev;
+ f->w->opacity = OPAQUE;
+
for (prev = &fades; *prev; prev = &(*prev)->next)
if (*prev == f)
{
--
Rich
Date: Tue Aug 17 05:47:57 2004
In-Reply-To: <4121EB52.6030407@tungstengraphics.com>
On Maw, 2004-08-17 at 12:26, Keith Whitwell wrote:
> Hmm. I'd prefer to see that differently - the presumption should be that the
> code should be ripped out unless somebody steps up and (a) protests and (b) is

> seen to demonstrate willingness to maintain the code. I don't see any value
> in keeping broken code in the tree otherwise. If someone wants it back in the

> future, it will still be in the repository (just not visible on the head).
>
> Otherwise, we're all tiptoe-ing around trying not to offend people who
> probably don't exist & if they do are much more interested in other stuff.
After this release the assumption is it gets a lot more modular, so
perhaps the legacy code should lurk for this release and the release
notes should indicate what is going away, so people have time to save it
if they wish.
Alan
From rlinuz at homeil.com Tue Aug 17 05:32:13 2004
From: rlinuz at homeil.com (rlinuz)
Date: Tue Aug 17 06:32:11 2004
Subject: [Xorg] Mapping CTRL+<KEY> between layouts
Hi,
I'm trying to polish the default keyboard layout file for il (Hebrew).
The default layout that comes with xorg maps CTRL+<KEY> to CTRL+<HEBREW
KEY>, and thus effectively disables all the 'shortcuts' keys. For
example, when the keyboard layout is set to il, pressing <CTRL>+<a>
('select-all') actually produces <CTRL>+<hebrew_shin> which is the
corresponding Hebrew letter for 'a'.
In xkb/types/pc I've added the following lines:
type "CTRL" {
modifiers = Control;
map[Control] = Level2;
level_name[Level1] = "Base";
level_name[Level2] = "Ctrl";
};
In xkb/symbols/pc/il I've added the following for each key:

key <AC01> { [ hebrew_shin, A ] }; // the default
key <AC01> { type="CTRL", symbols[Group1]=[hebrew_shin, a ] };
After that, the il layout produced 'a' in response to <CTRL>+<a> and
this seems to work fine for OpenOffice and Mozilla. However, it does not
work in a console window.
Although this works for some applications, I'm pretty sure that mapping
<CTRL>+<hebrew_shin> to <a> is not good enough. What I really want to do
is to map <CTRL>+<hebrew_shin> to <CTRL>+<a>. I've tried the following
but it didn't work (notice the â):
key <AC01> { type="CTRL", symbols[Group1]=[hebrew_shin, â ] };
I guess I have to use the keycode of <CTRL>+<a> - any idea what's that
keycode? I've tried 0x0001 and 0x0061 they seem to work in OpenOffice
and Mozilla but again, not in the console window.
Thanks,
-S.
From morphie at unravel-music.nl Tue Aug 17 06:20:55 2004
Date: Tue Aug 17 06:38:07 2004
http://home.wanadoo.nl/bastiaantje/morphie/screenshots/snapshot50_small.png
http://home.wanadoo.nl/bastiaantje/morphie/screenshots/snapshot50.png
Latest CVS-stuff. Works nicely without damages in the screen. :-)
- Dennie
Date: Tue Aug 17 06:54:35 2004
On Tue, 2004-08-17 at 00:14, Alan Coopersmith wrote:
> The tree still contains rudimentary support for building ancient
> servers such as the old Xdec, Xsun, Xhp, etc. How much do we
> care about this? Should it just be put in the release notes that
> they no longer work?
>
I think we note that they are broken there has been no
testing, and that if there is no volunteers and testing before our next
release, they will be removed in that release.
So adding a bugzilla bug against the release notes
is probably the right solution.
- Jim
From mark at skynet.ie Tue Aug 17 07:18:47 2004
From: mark at skynet.ie (Mark McLoughlin)
Date: Tue Aug 17 07:25:34 2004
Hi,
On Thu, 2004-08-12 at 16:03, Jim Gettys wrote:
>
I've just fixed up Vino's[1] Damage support and it works great. No idea
how you'd screenshot effectively, but its one example of Damage in use
anyway.
Cheers,
Mark.
[1] - Vino is GNOME's VNC server
From Alan.Coopersmith at Sun.COM Tue Aug 17 07:35:09 2004
Date: Tue Aug 17 07:35:06 2004
Subject: [Xorg] Tinderbox status
Message-ID: <4122179D.90106@sun.com>
> There are four boxes still performing tinderbox test runs:
>
> alanc SolarisX86 - Error in xpawhelloworld.c finding an include file for
> defining symbol XawNcurrPageNumInJob.
I've reported this under #1060 and Kevin checked in a patch so it's
green again now.
--
From bryce at osdl.org Tue Aug 17 09:27:14 2004
Date: Tue Aug 17 09:27:23 2004
In-Reply-To: <20040817145639.GB934@async.com.br>
On Tue, 17 Aug 2004, Christian Robottom Reis wrote:
> On Mon, Aug 16, 2004 at 10:42:07PM -0700, Bryce Harrington wrote:
> > > Are we ready to do this? I chatted very very briefly with Daniel about
> > > this in Oxford but left this dangling for this week[end?].
> >
> > I'd say the time's ripe for it. :-)
>
> Let's schedule this for Saturday, then.
Sounds good. How can I help with it?
> > > > + rendertest.
> >
> > Yeah, I've been playing with various bits, and in fact was just playing
> > while, and prints out stuff like this:
>
> So from Thomas' description you're getting a test failure.
Yes, that explained the output very well, thanks Thomas.
Fwiw, I got a lot of output from it... It seemed fairly continuous
through the test. I'll get a better capture of it next time I run it.
> Can you quantify how much time it took to run, and what sort of hardware
> you're running it on?
Sure, I'll get a more detailed time report and machine summary tonight
or tomorrow. Like I mentioned it seemed to take less than a few minutes
- I started it, went for coffee, and it was done when I got back. This
is on a 3GHz P4 with 512k cache, 1G memory, and ATI Radeon R350.
> Have you taken a look at the other tests to evaluate how runnable they
> are?
Not yet, but I plan to do that. Rendercheck was the first test on my
list.
> > rendercheck took a few minutes to run. Unless there's a way to boil
> > down the above data into a yea/nay type value I don't think they're
> > useful as pre-checkin requirements.
>
> As they're failing, you'd assume it isn't that easy to fix anyway. It is
> probably easy to boil it down to a succeed/fail model -- just check if
> the expected values match the actual values, and bonk if not.
*Nod* And track the quantity of success/failures, like we do for LTP.
> > rendercheck is easy to fire up - there's no supported args. The output
> > I'm not certain about though.
>
> Is this someone included in the X distribution, or do you need to
> download it separately?
It's from a separate repository from the pdx.freedesktop.org anonymous
cvs. It requires xrender to run (which I got via cairo).
Bryce
Date: Tue Aug 17 09:45:04 2004
Message-ID: <4122360D.9000008@Sun.COM>
I'm not sure I want to claim any ownership or responsibility for the hw/sun
tree. The only cards listed in the README that I even know where to find are
the cg6 series, and those have a directory under hw/xfree86/drivers already.
Sun/4 is definitely the only hardware platform listed there we still have,
none of the Sun/2, Sun/3 or Sun386i hardware. Unless someone wants to step
up and volunteer, I can't see continuing to support it.
Since we're so close to the 6.8 release, I think the best solution for that
is to release note the lack of support and change the default for Solaris/SPARC
builds to build Xorg instead of Xsun (a one-line change to the svr4.cf file).
-alan-
> I didn't mean to imply that we can't get rid of orphaned code, just that
> since the "owner" of this code is present, and participating, it should
> be their call as to what happens to it. If it stays, then it should be
> maintained in the same manner as everything else that stays.
>
> Changes to common code requires concensus. Vendor specific code,
> however, should probably be the responsibility of that vendor.
>
>
> On Tue, 17 Aug 2004, Keith Whitwell wrote:
>
>
>>Stuart Anderson wrote:
>>
>>>I think it is up to the vendors that provided these DDX to decide what
>>>their status is (ie it's your call). Fix it, turn it off, or rip it out.
>>>Like Mike said, if it stays in, it should get a tinderbox to prove it at
>>>least builds ok. There should be a row for it in the Release Readiness Table
>>>if you want it.
>>>
>>
>>Hmm. I'd prefer to see that differently - the presumption should be that the
>>code should be ripped out unless somebody steps up and (a) protests and (b) is
>>seen to demonstrate willingness to maintain the code. I don't see any value
>>in keeping broken code in the tree otherwise. If someone wants it back in the
>>future, it will still be in the repository (just not visible on the head).
>>
>>Otherwise, we're all tiptoe-ing around trying not to offend people who
>>probably don't exist & if they do are much more interested in other stuff.
>>
>>Keith
>>
>
>
>
> Stuart
>
> Stuart R. Anderson anderson@netsweng.com
> Network & Software Engineering http://www.netsweng.com/
> 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
> BD03 0A62 E534 37A7 9149
--
From saturn_vk at abv.bg Tue Aug 17 14:19:31 2004
Date: Tue Aug 17 14:19:38 2004
Subject: [Xorg] Potential bug with glx + composite + nvidia
using the newest cvs code (dating 18.08.04), and the binary nvidia drivers, if L
oad "glx" is uncommented, whenever it's used (by just typing glxinfo, or startin
g any gl app), it will cause a freeze to the whole system.
-----------------------------------------------------------------
From oshofmann at amherst.edu Tue Aug 17 20:20:54 2004
From: oshofmann at amherst.edu (Owen Hofmann 06)
Date: Tue Aug 17 20:21:40 2004
Subject: [Xorg] Graphical glitches in xfwm, pekwm when used with xcompmgr
Message-ID: <1092799254.340.3.camel@le
Hi. I just got around to trying out a recent version of the X.org
server, and found that using xcompmgr along with xfwm, and later pekwm,
caused some graphical glitches in window decorations. I tried metacity,
and it seemed to be fine.
Some screenshots:
http://www.amherst.edu/~oshofmann/xorg/metacity.png
http://www.amherst.edu/~oshofmann/xorg/xfwm.png
http://www.amherst.edu/~oshofmann/xorg/pekwm.png
I'm running a cvs build from the evening of 8/17, on Arch Linux, on a
laptop with a geforce4 mx. These shots are taken with the nvidia binary
drivers, but the nv driver showed the same problems.
I must say I'm really excited about the rapid development of the X.org
server.
Thanks,
Owen
Date: Tue Aug 17 20:59:59 2004
Subject: [Xorg] Release candidate 2 tagged
The X.Org CVS tree has been tagged for the second release candidate
since several major blocker bugs were fixed today. If you are building
test packages, please build them against the XORG-6_7_99_902 tag and
reply here with the location of your packages.
For this release, we have set up a release status test matrix, which can
be found here:
On that page are instructions for running the build, install, run and
conformance tests. Your help testing and filling in this test matrix is
greatly appreciated!
Date: Tue Aug 17 21:12:49 2004
Subject: [Xorg] RC2 test report
Here is my test report:
Name: Kevin E. Martin
Test date: 17 August 2004
Platform: Linux, IA-32, Red Hat 9
Release tag: XORG-6_7_99_902 (RC2)
Build tests: all tests passed
Install tests: all tests passed
Conformance: xtest failed
Run tests: not yet run
Notes:
- It looks like most of the xtest failures are in XGrabButton, which I
am looking into.
- The test matrix has been updated with these results.
- When others post their results, I will add them to the test matrix.
Date: Tue Aug 17 21:21:04 2004
night.
listed below.
Fixed yesterday: 6
Added yesterday: 4
-----------------------------
* Bug #999: Release notes/documentation for next release
- Need to investigate what other documentation changes are needed
3. Leave hard failure in code
* Bug #1104: Won't build on Solaris/SPARC
- Waiting for new patch to review
* Bug #1105: cw break CopyArea for non-redir dst, redir src
- Patch supplied
- More testing is needed to ensure that it does not break anything
From andrew at pimlott.net Tue Aug 17 21:49:25 2004
Date: Tue Aug 17 21:49:43 2004
In-Reply-To: <200408162000.16600.Mathias.Froehlich@gmx.net>
<20040815200615.GB4574@pimlott.net>
<200408162000.16600.Mathias.Froehlich@gmx.net>
Message-ID: <20040818044925.GC4521@pimlott.net>
On Mon, Aug 16, 2004 at 08:00:16PM +0200, Mathias Fr?hlich wrote:
> I never thought about an other solution to that problem since it works
> sufficiently well for me.
Likewise, I just wrote the first way that occurred to me, and didn't
think about a timeout until I saw your patch.
> My experience with that feature (and my hardware) is that my trackpoint on my
> thinkpad sometimes slightly drifts away with a more or less little speed,
> even if I do not touch the trackpoint at all.
Good point--I have seen this on multiple laptops. On my current one, it
is not bad, but I have seen a middle-click fail at least once with my
patch because of the drifting trackpoint.
> IMO this could be better handled with the timeout approach since the decision
> of emitting middle mouse button clicks does not depend on a funky mouse
> hardware but only on your click speed ...
True; on the other hand, I'm not sure that users are very aware of how
long they hold down the mouse for a click. They may be more aware of
whether or not they moved the mouse. And maybe a threshold will remove
the funky mouse issue.
> Is the movement threshold configurable?
I did not implement a threshold initially. But it seems that it would
be necessary for my approach, so I added it, hard-coded at 5 pixels for
now. (The distance for a scroll is 10 pixels. BTW, the documentation
is wrong about that and the code is inconsistent.)
> I don't think that we should overcomlicate that issue with different
> approaches, much configuration options ....
right
> Could you provide me a mouse module with the movement approach?
The new patch is appended, and I can send you (and anyone else) the
module in a separate message. If you didn't catch the beginning of the
thread, it's at
http://freedesktop.org/pipermail/xorg/2004-August/002404.html
> I will tell you in a few days if this does not work well with that drift in
> hardware.
Likewise, I'll try out your patch soon. What timeout do you suggest?
Andrew
--- hw/xfree86/os-support/xf86OSmouse.h.orig 2004-08-15 00:24:15.000000000 -0
700
+++ hw/xfree86/os-support/xf86OSmouse.h 2004-08-17 21:31:18.000000000 -0700
@@ -150,6 +150,8 @@
Bool emulateWheel;
int wheelInertia;
int wheelButtonMask;
+ Bool wheelButtonClick;
+ int wheelButtonMoved;
int negativeX; /* Button values. Unlike the Z
and */
int positiveX; /* W equivalents, these are butt
on */
int negativeY; /* values rather than button mas
ks. */
--- hw/xfree86/input/mouse/mouse.c.orig 2004-08-15 00:07:41.000000000 -0700
+++ hw/xfree86/input/mouse/mouse.c 2004-08-17 21:34:55.000000000 -0700
@@ -185,6 +185,7 @@
OPTION_RESOLUTION,
OPTION_EMULATE_WHEEL,
OPTION_EMU_WHEEL_BUTTON,
+ OPTION_EMU_WHEEL_CLICK,
OPTION_EMU_WHEEL_INERTIA,
OPTION_X_AXIS_MAPPING,
OPTION_Y_AXIS_MAPPING,
@@ -222,6 +223,7 @@
{ OPTION_RESOLUTION, "Resolution", OPTV_INTEGER, {0}, FALSE },
{ OPTION_EMULATE_WHEEL, "EmulateWheel", OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_EMU_WHEEL_BUTTON, "EmulateWheelButton", OPTV_INTEGER, {0}, FALSE }
,
+ { OPTION_EMU_WHEEL_CLICK, "EmulateWheelClickToo", OPTV_BOOLEAN, {0}, FALSE
},
{ OPTION_EMU_WHEEL_INERTIA, "EmulateWheelInertia", OPTV_INTEGER, {0}
, FALSE },
{ OPTION_X_AXIS_MAPPING, "XAxisMapping", OPTV_STRING, {0}, FALSE },
{ OPTION_Y_AXIS_MAPPING, "YAxisMapping", OPTV_STRING, {0}, FALSE },
@@ -619,6 +621,9 @@
}
pMse->wheelButtonMask = 1 << (wheelButton - 1);

+ pMse->wheelButtonClick = xf86SetBoolOption(pInfo->options,
+ "EmulateWheelClickToo", FALSE);
+
pMse->wheelInertia = xf86SetIntOption(pInfo->options,
"EmulateWheelInertia", 10);
if (pMse->wheelInertia <= 0) {
@@ -689,8 +694,9 @@
pInfo->name, pMse->negativeY, pMse->positiveY);
}
xf86Msg(X_CONFIG, "%s: EmulateWheel, EmulateWheelButton: %d, "
- "EmulateWheelInertia: %d\n",
- pInfo->name, wheelButton, pMse->wheelInertia);
+ "EmulateWheelClickToo: %d, EmulateWheelInertia: %d\n",
+ pInfo->name, wheelButton, pMse->wheelInertia,
+ pMse->wheelButtonClick);
}
if (origButtons != pMse->buttons)
from = X_CONFIG;
@@ -1992,6 +1998,8 @@

/* Intercept wheel emulation. */
if (pMse->emulateWheel && (buttons & pMse->wheelButtonMask)) {
+ pMse->wheelButtonMoved += abs(dx) + abs(dy);
+
/* Y axis movement */
if (pMse->negativeY != MSE_NOAXISMAP) {
pMse->wheelYDistance += dy;
@@ -2044,10 +2052,9 @@
}
}

- /* Absorb the mouse movement and the wheel button press. */
+ /* Absorb the mouse movement. */
dx = 0;
dy = 0;
- buttons &= ~pMse->wheelButtonMask;
}

if (dx || dy)
@@ -2060,6 +2067,31 @@
else
change = buttons ^ reverseBits(reverseMap, pMse->lastButtons);

+ /* We generally swallow wheelButtonMask events, except when a wheel
+ * button is released, and we haven't moved the mouse since a wheel
+ * button was pressed, and EmulateWheelClickToo is set. */
+
+ if (pMse->emulateWheel && change & pMse->wheelButtonMask) {
+ int wheelChange = change & pMse->wheelButtonMask;
+
+ while (wheelChange) {
+ id = ffs(wheelChange);
+ wheelChange &= ~(1 << (id - 1));
+ if (pMse->wheelButtonClick &&
+ ! (buttons & (1 << (id - 1))) && /* released */
+ pMse->wheelButtonMoved < 5) {
+ }
+ }
+
+ if (! (buttons & pMse->wheelButtonMask))
+ pMse->wheelButtonMoved = 0;
+
+ buttons &= ~pMse->wheelButtonMask;
+ change &= ~pMse->wheelButtonMask;
+ }
+
/*
* adjust buttons state for drag locks!
* if there is drag locks
--- hw/xfree86/input/mouse/mouse.man.orig 2004-08-15 01:04:07.000000000 -0
700
+++ hw/xfree86/input/mouse/mouse.man 2004-08-15 01:16:00.000000000 -0700
@@ -112,6 +112,12 @@
.B YAxisMapping
settings. Default: 4.
.TP 7
+.BI "Option \*qEmulateWheelClickToo\*q \*q" boolean \*q
+Causes
+.B EmulateWheelButton
+to generate normal clicks when the mouse isn't moved between press and
+release. Default: off
+.TP 7
.BI "Option \*qEmulateWheelInertia\*q \*q" integer \*q
Specifies how far (in pixels) the pointer must move to generate button
press/release events in wheel emulation mode. Default: 50.
Date: Tue Aug 17 22:30:59 2004
Subject: [Xorg] Graphical glitches in xfwm, pekwm when used with xcompmgr
In-Reply-To: <1092799254.340.3.camel@le
References: <1092799254.340.3.camel@le
Seems to be the same/similar problem as bugs #1101 and #1095. Sorry if I've
cluttered up the list.
> Hi. I just got around to trying out a recent version of the X.org
> server, and found that using xcompmgr along with xfwm, and later pekwm,
> caused some graphical glitches in window decorations. I tried metacity,
> and it seemed to be fine.
>
> Some screenshots:
> http://www.amherst.edu/~oshofmann/xorg/metacity.png
> http://www.amherst.edu/~oshofmann/xorg/xfwm.png
> http://www.amherst.edu/~oshofmann/xorg/pekwm.png
>
> I'm running a cvs build from the evening of 8/17, on Arch Linux, on a
> laptop with a geforce4 mx. These shots are taken with the nvidia binary
> drivers, but the nv driver showed the same problems.
>
> I must say I'm really excited about the rapid development of the X.org
> server.
>
> Thanks,
> Owen
> _______________________________________________
> xorg mailing list
From elylevy-xserver at cs.huji.ac.il Wed Aug 18 02:43:13 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Aug 18 02:43:18 2004
In-Reply-To: <20040818042100.GC16682@kem.org>
References: <20040818042100.GC16682@kem.org>
Message-ID: <Pine.LNX.4.56.0408181242180.14080@grok.cs.huji.ac.il>
On Wed, 18 Aug 2004, Kevin E Martin wrote:
> Current list of blocker bugs:
> -----------------------------
> * Bug #999: Release notes/documentation for next release
> - Need someone to start documenting changes for release notes
> - Need to investigate what other documentation changes are needed
>
How about a list of things which would not be supported in next version?
Ely
From alexdeucher at gmail.com Wed Aug 18 05:57:54 2004
Date: Wed Aug 18 05:58:06 2004
<20040815200615.GB4574@pimlott.net>
<200408162000.16600.Mathias.Froehlich@gmx.net>
<20040818044925.GC4521@pimlott.net>
Message-ID: <a728f9f90408180557342b0c92@mail.gmail.com>
On Wed, 18 Aug 2004 00:49:25 -0400, Andrew Pimlott <andrew@pimlott.net> wrote:
> On Mon, Aug 16, 2004 at 08:00:16PM +0200, Mathias Fr?hlich wrote:
> > I never thought about an other solution to that problem since it works
> > sufficiently well for me.
>
> Likewise, I just wrote the first way that occurred to me, and didn't
> think about a timeout until I saw your patch.
>
> > My experience with that feature (and my hardware) is that my trackpoint on m
y
> > thinkpad sometimes slightly drifts away with a more or less little speed,
> > even if I do not touch the trackpoint at all.
>
> Good point--I have seen this on multiple laptops. On my current one, it
> is not bad, but I have seen a middle-click fail at least once with my
> patch because of the drifting trackpoint.
>
> > IMO this could be better handled with the timeout approach since the decisio
n
> > of emitting middle mouse button clicks does not depend on a funky mouse
> > hardware but only on your click speed ...
>
> True; on the other hand, I'm not sure that users are very aware of how
> long they hold down the mouse for a click. They may be more aware of
> whether or not they moved the mouse. And maybe a threshold will remove
> the funky mouse issue.
>
> > Is the movement threshold configurable?
>
> I did not implement a threshold initially. But it seems that it would
> be necessary for my approach, so I added it, hard-coded at 5 pixels for
> now. (The distance for a scroll is 10 pixels. BTW, the documentation
> is wrong about that and the code is inconsistent.)
>
> > I don't think that we should overcomlicate that issue with different
> > approaches, much configuration options ....
>
> right
>
> > Could you provide me a mouse module with the movement approach?
>
> The new patch is appended, and I can send you (and anyone else) the
> module in a separate message. If you didn't catch the beginning of the
> thread, it's at
> http://freedesktop.org/pipermail/xorg/2004-August/002404.html
I love this feature (been using tpscroll forever), so as soon as we
decide on an approach I'll be happy to apply the resulting patch to
cvs (after the new release is out) assuming none of the other
developers have a problem with it.
Alex
>
> > I will tell you in a few days if this does not work well with that drift in
> > hardware.
>
> Likewise, I'll try out your patch soon. What timeout do you suggest?
>
> Andrew
>
> --- hw/xfree86/os-support/xf86OSmouse.h.orig 2004-08-15 00:24:15.000000000
-0700
> @@ -150,6 +150,8 @@
> int wheelInertia;
> + int wheelButtonMoved;
> int negativeX; /* Button values. Unlike the
Z and */
> int positiveX; /* W equivalents, these are bu
tton */
> int negativeY; /* values rather than button m
asks. */
> @@ -185,6 +185,7 @@
> @@ -222,6 +223,7 @@
> { OPTION_EMU_WHEEL_BUTTON, "EmulateWheelButton", OPTV_INTEGER, {0}, FALSE
},
> + { OPTION_EMU_WHEEL_CLICK, "EmulateWheelClickToo", OPTV_BOOLEAN, {0}, FAL
SE },
> { OPTION_EMU_WHEEL_INERTIA, "EmulateWheelInertia", OPTV_INTEGER, {
0}, FALSE },
> @@ -619,6 +621,9 @@
> }
>
> +
> @@ -689,8 +694,9 @@
> }
> + "EmulateWheelClickToo: %d, EmulateWheelInertia: %d\n
",
> }
> from = X_CONFIG;
> @@ -1992,6 +1998,8 @@
>
> + pMse->wheelButtonMoved += abs(dx) + abs(dy);
> +
> @@ -2044,10 +2052,9 @@
> }
> }
>
> dx = 0;
> dy = 0;
> }
>
> if (dx || dy)
> @@ -2060,6 +2067,31 @@
> else
>
> +
> +
> + wheelChange &= ~(1 << (id - 1));
> + pMse->wheelButtonMoved < 5) {
>
>
> + }
> + }
> +
> +
> + }
> +
> /*
> --- hw/xfree86/input/mouse/mouse.man.orig 2004-08-15 01:04:07.000000000
-0700
> @@ -112,6 +112,12 @@
> .B YAxisMapping
> .TP 7
> +Causes
> +.TP 7
>
> _______________________________________________
> xorg mailing list
>
From rjw57 at hermes.cam.ac.uk Wed Aug 18 11:02:30 2004
Date: Wed Aug 18 11:01:16 2004
Message-ID: <20040818180230.GE21735@hermes.cam.ac.uk>
On Thu, Aug 12, 2004 at 11:03:36AM -0400, Jim Gettys wrote:
>
Not terribly exciting but I've been hacking Gtk + metacity to support
the new ARGB visual type. You can how have properly alpha-composited
window borders.
http://lotsofnakedwomen.com/~rjw57/haxie2.png
Note that this is just a simple PNG theme with some holes drilled in it
via the gimp. Note the nice blending around the smooth hole.
--
Rich
From thomas.klein at lanterne.org Wed Aug 18 12:23:11 2004
Date: Wed Aug 18 12:23:13 2004
<200408151502.56815.morphie@unravel-music.nl>
On Sunday 15 August 2004 15:02, Dennie Bastiaan wrote:
> xcompmgr runs, the eye-candy is on, but the screen freezes. I can
> move the mouse, and I can click on icons and the program is
> starting, but the screen won't refresh anymore so I don't see any
> changes anymore.
same problem here
linux 2.6.8
kdrive Xmach64 (16bpp)
last xcompmgr
debian unstable / kde 3.3.3
t.
From ryan.gallagher at comcast.net Wed Aug 18 12:38:18 2004
Date: Wed Aug 18 12:37:30 2004
<200408182123.11502.thomas.klein@lanterne.org>
This sounds like bug 1107. Do you have a radeon?
On Wed, 2004-08-18 at 21:23 +0200, thomas klein wrote:
> On Sunday 15 August 2004 15:02, Dennie Bastiaan wrote:
>
> > xcompmgr runs, the eye-candy is on, but the screen freezes. I can
> > move the mouse, and I can click on icons and the program is
> > starting, but the screen won't refresh anymore so I don't see any
> > changes anymore.
>
> same problem here
>
> linux 2.6.8
>
> kdrive Xmach64 (16bpp)
>
> last xcompmgr
>
> debian unstable / kde 3.3.3
>
> t.
> _______________________________________________
> xorg mailing list
From ryan.gallagher at comcast.net Wed Aug 18 12:42:27 2004
Date: Wed Aug 18 12:41:33 2004
Er... Xmach64, not a radeon, sorry for not reading more closely, btw
this bug happens for me w/xorg and xcompmgr as of 08/18.
On Wed, 2004-08-18 at 14:38 -0500, Ryan wrote:
> This sounds like bug 1107. Do you have a radeon?
>
> On Wed, 2004-08-18 at 21:23 +0200, thomas klein wrote:
> > On Sunday 15 August 2004 15:02, Dennie Bastiaan wrote:
> >
> > > xcompmgr runs, the eye-candy is on, but the screen freezes. I can
> > > move the mouse, and I can click on icons and the program is
> > > starting, but the screen won't refresh anymore so I don't see any
> > > changes anymore.
> >
> > same problem here
> >
> > linux 2.6.8
> >
> > kdrive Xmach64 (16bpp)
> >
> > last xcompmgr
> >
> > debian unstable / kde 3.3.3
> >
> > t.
> > _______________________________________________
>
> _______________________________________________
> xorg mailing list
From svu at gnome.org Wed Aug 18 13:16:19 2004
From: svu at gnome.org (Sergey V. Udaltsov)
Date: Wed Aug 18 14:21:58 2004
In-Reply-To: <20040817004233.4C51F9F150@freedesktop.org>
References: <20040817004233.4C51F9F150@freedesktop.org>
Message-ID: <4123B913.3000802@gnome.org>
While we are at this point, one more question:
Even without layout, it would be cool to perform automatic XKB
configuration for hotplugged (and not only?) keyboards. So in XKB
configuration repository, it could be handy to have IDs (USB ID)
associated with the relevant models. Currently, the universal XKB
registry file is xorg.xml (which eventually will become base.xml, I hope
- looking at xkeyboard-config). Would it make sense to put USB IDs (or
other HW-based IDs) into this file? Would this help kdb driver to
process hotplug better?
Sergey
From morphie at unravel-music.nl Wed Aug 18 14:42:17 2004
Date: Wed Aug 18 15:07:27 2004
On Wednesday 18 August 2004 21:23, thomas klein wrote:
> On Sunday 15 August 2004 15:02, Dennie Bastiaan wrote:
> > xcompmgr runs, the eye-candy is on, but the screen freezes. I can
> > move the mouse, and I can click on icons and the program is
> > starting, but the screen won't refresh anymore so I don't see any
> > changes anymore.
>
> same problem here
>
> linux 2.6.8
>
> kdrive Xmach64 (16bpp)
>
> last xcompmgr
>
> debian unstable / kde 3.3.3
>
Just to tell you that with xorg R6.7.99.902 I don't have those problems
anymore.
- Dennie
From skatan at despammed.com Wed Aug 18 15:39:57 2004
Date: Wed Aug 18 15:33:48 2004
Subject: [despammed] Re: [Xorg] Re: CVS as of Keith's commit 04/08/14
20:34:18
References: <E1BwEyC-0000Fw-LE@evo.keithp.com> <200408151502.56815.morphie@unra
vel-music.nl> <200408182123.11502.thomas.klein@lanterne.org>
Message-ID: <4123DABD.7080108@despammed.com>
Dennie Bastiaan ha scritto:
>On Wednesday 18 August 2004 21:23, thomas klein wrote:
>
>
>>On Sunday 15 August 2004 15:02, Dennie Bastiaan wrote:
>>
>>
>>>xcompmgr runs, the eye-candy is on, but the screen freezes. I can
>>>move the mouse, and I can click on icons and the program is
>>>starting, but the screen won't refresh anymore so I don't see any
>>>changes anymore.
>>>
>>>
>>same problem here
>>
>>linux 2.6.8
>>
>>kdrive Xmach64 (16bpp)
>>
>>last xcompmgr
>>
>>debian unstable / kde 3.3.3
>>
>>
>>
>
>Just to tell you that with xorg R6.7.99.902 I don't have those problems
>anymore.
>
>- Dennie
>_______________________________________________
>xorg mailing list
>
>----------------------------------------------
>Filtered by despammed.com. Tracer: 1092867365
>Consider a PayPal donation to help Despammed
>stay a step or two ahead of the bad guys.
>A new PayPal donation button is now on the
>home page. Thanks!
>
>
>
to me happen sometimes, today twice
xorg R6.7.99.902 and latest xcompmgr -c
FC2
Radeon 9200
kernel 2.6.7
From brian.paul at tungstengraphics.com Wed Aug 18 15:47:38 2004
Date: Wed Aug 18 15:49:27 2004
Subject: [Xorg] Mesa 6.1 released
Message-ID: <4123DC8A.7050701@tungstengraphics.com>
I've wrapped up Mesa 6.1. The CVS tree has been tagged with
'mesa_6_1' and the tarballs can be downloaded from the SourceForge site.
I'll leave it up to the DRI/X.org developers to pull this into the
upcoming X server release. There have been only minor changes over
the past week, I believe.
Mesa developers: if you're anxious to start checking in new
development / new feature code into the Mesa CVS tree, let me know and
I'll create a 'mesa_6_2_branch' branch. Then the trunk will be open
for new development while the mesa_6_2_branch will be for bug fixes
for the 6.2 release (the usual system).
But until I create that branch, the CVS trunk should be for bug fixes
only. Thanks.
-Brian
From skatan at despammed.com Wed Aug 18 15:55:57 2004
Date: Wed Aug 18 15:49:45 2004
Subject: [Xorg] moving windows cpu 100% + xcompmgr
Message-ID: <4123DE7D.8040907@despammed.com>
I'm testing Xorg latest CVS with xcompmgr, I notced that when I move any
window X will hit the cpu up to 100%!
am i missing something?
FC2
Radeon 9200
kernel 2.6.7
Section "Device"
Identifier "Device[0]"
Driver "radeon"
VendorName "ATI"
Option "EnablePageFlip" "on"
Option "backingstore" "yes"
Option "HWcursor"
Option "ForceCRT2Type" "VGA"
Option "MergedFB" "true"
Option "CRT2Position" "RightOf"
Option "MetaModes" "1152x864-1152x864 800x600-1024x768
1024x768-800x600 1024x768 800x600"
Option "CRT2HSync" "24-65"
Option "CRT2VRefresh" "50-120"
EndSection
From aplattner at nvidia.com Wed Aug 18 19:48:42 2004
Date: Wed Aug 18 19:52:41 2004
Subject: [Xorg] Detecting Composite from the driver
Message-ID: <20040819024841.GH3479@dhcp-177-151.nvidia.com>
When Composite is enabled, I'd like to avoid exposing any video overlay Xv
adapters in ScreenInit. Is there an interface for the driver to determine that
Composite is going to be enabled?
Thanks!
-- Aaron Plattner
Date: Wed Aug 18 20:04:00 2004
Subject: [Xorg] Detecting Composite from the driver
In-Reply-To: <20040819024841.GH3479@dhcp-177-151.nvidia.com>
References: <20040819024841.GH3479@dhcp-177-151.nvidia.com>
On Wed, Aug 18, 2004 at 07:48:42PM -0700, Aaron Plattner wrote:
> When Composite is enabled, I'd like to avoid exposing any video overlay Xv
> adapters in ScreenInit. Is there an interface for the driver to determine tha
t
> Composite is going to be enabled?
Yes, there is a global variable, Bool noCompositeExtension, that is true
when the Composite extension is disabled and false when it is enabled.
There are similar variables for the Xinerama, Xevie, Render, Test and
Xkb extensions.
From matthieu.herrb at laas.fr Wed Aug 18 21:11:01 2004
Date: Wed Aug 18 21:11:12 2004
Subject: [Xorg] small Imakefiles patch
Message-ID: <41242855.3060708@laas.fr>
I've having troubles with the code that forces uses of the kbd driver on
OpenBSD/amd64 (which uses DoLoadableServer NO). So I tried enabling
UseDeprecatedKeyboardDriver and found out that make was bailing on
incorrect Makefiles.
Don't use TABs to add white space in front of lines that are not
comments. See Bugzilla #1132:
<http://freedesktop.org/bugzilla/show_bug.cgi?id=1132>
--
Matthieu
From lista4 at comhem.se Wed Aug 18 21:15:18 2004
From: lista4 at comhem.se (Voluspa)
Date: Wed Aug 18 21:38:03 2004
Subject: [Xorg] RC2 test report
Message-ID: <200408190415.i7J4FIG04938@d1o404.telia.com>
My carnival system can't be entered in your test matrix but here's a
test report anyway:
Hardware: Celeron clocked at 1 Gig. 256 meg mem. GeForce2 MX 400, 64 MB.
System: Linux From Scratch ca 2001 (gcc 2.95.3, libc 2.2.4).
Kernel: 2.6.7 (compiled with gcc 3.3.2)
Driver: NVIDIA-Linux-x86-1.0-6111-pkg1 (compiled with gcc 3.3.2)
Option "RenderAccel" "True"
X.org: xc-6-7-99-902.tar.bz2 from "ajax" home directory.
Build, no configuration just "make World": OK (compile time 1 hour)
Install "make install": OK
startx: OK, but it didn't pick up anything from my old XF86Config-4
startx: Hard fail with a copy renamed to xorg.conf (Driver "Keyboard")
startx: OK with Driver "Keyboard" edited to "kbd"
Running: Rock stable (no desktop, just Enlightenment 0.16.6). Xv under
mplayer, no problems. Glxgears and bzflag are both OK.
Composite "Enable": Enlightenment totally useless (misdrawings
everywhere) and a glxgears run crashed the computer hard after a few
seconds - reboot necessary. A recompile of the WM made no difference.
Composite "Enable": XFce 4.0.0 as desktop/WM is rock stable.
xcompmgr -c: Initially rock stable, with known errors like glxgears
always on top, bzflag misrendered (also unable to run/accept
keypresses). Segmentation fault of xcompmgr after ca 40 minutes.
xcompmgr -c -f: Now things really start to break down ;-)
All in all a nice experience. I'm pleased that my hodgepodge system
could swallow your package this well.
Mvh
Mats Johannesson
From matthieu.herrb at laas.fr Wed Aug 18 22:18:07 2004
Date: Wed Aug 18 22:18:14 2004
Subject: [Xorg] keyboard driver fails to initialize if DoLoadableServer=NO
Message-ID: <4124380F.6070009@laas.fr>
See <http://freedesktop.org/bugzilla/show_bug.cgi?id=1133>
--
Matthieu
From rene at rocklinux-consulting.de Wed Aug 18 23:14:21 2004
Date: Wed Aug 18 23:15:20 2004
Subject: [Xorg] Radeon/PowerPC blocker bug Was: X.org radeon hangs on
startup (PowerPC/iBook2)
In-Reply-To: <20040815205416.GA6271@spring.luon.net>
References: <411E9FF8.30004@rocklinux-consulting.de>
<20040815205416.GA6271@spring.luon.net>
Message-ID: <4124453D.5050203@rocklinux-consulting.de>
Hi all,
Sjoerd Simons wrote:
> On Sat, Aug 14, 2004 at 02:27:52PM +0000, Ren? Rebe wrote:
>
>>Hi all,
>>
>>I just tried cvs:head on my iBook2 (Radeon Mobility M7 LW [Radeon
>>Mobility 7500]) and had to notice that it already hangs during startup:
>
>
> I've noticed this some time ago on my powerbook (Radeon 9600) too and reported
> a bug with patch[0]. No reaction on it yet though.
>
> Unfortunately while the patch prevents the X server from hanging, it doesn't
> make Xorg work me. Need to report a bug about that sometime.
>
> Sjoerd
> 0: http://freedesktop.org/bugzilla/show_bug.cgi?id=1007
Yes - that bugzilla patch indeed let's X.Org start here. Please apply.
Have fun,
Ren? Rebe
From sskowron at ET.PUT.Poznan.PL Wed Aug 18 23:10:57 2004
From: sskowron at ET.PUT.Poznan.PL (Stanislaw Skowronek)
Date: Wed Aug 18 23:40:25 2004
Subject: [Xorg] Non-fb video driver
Message-ID: <Pine.GSO.4.10.10408190806140.10831-100000@helios.et.put.poznan.pl>
Hello!
I would like to make a SGI Octane (ImpactSR) X driver. The problem with
this device is that it is a pure graphics pipeline, i.e. there is no
directly mapped access to the framebuffer.
Accessing the framebuffer is a rather intricate process involving setup of
about 20 registers and DMA, so "just copy a virtual fb to screen" would be
too slow.
However, I can draw accelerated rectangles, pixmaps, lines, polygons (I
haven't quite worked the stipple out as yet), alpha blending, gradients
et al. And acceleration on this card is, well, SGI standard :)
How does one write a driver for a monster like this: no fb, good accel?
Stanislaw Skowronek
--<=>--
"You're not as old as the trees, not as young as the leaves.
Not as free as the breeze, not as open as the seas."
Date: Thu Aug 19 00:38:57 2004
night.
listed below.
Fixed yesterday: 10
Added yesterday: 11
-----------------------------
* Bug #1119: Build breaks with UseInstalled* and ProjectRoot set
- Waiting for patch
- After patch is attached to bug report, others using UseInstalled
should test the patch to see if it works for them
* Bug #1126: wraphelp.c not in distro
- Due to US export laws, wraphelp.c has not been included
- Jim Gettys has begun the process to allow us to include it in future
releases
* Bug #1134: Xsun server doesn't build
- Patch supplied
- Will review tomorrow
From hiryu at audioseek.net Thu Aug 19 01:10:42 2004
Date: Thu Aug 19 00:57:55 2004
Subject: [Xorg] another kdrive build error!
Message-ID: <200408190110.42454.hiryu@audioseek.net>
Get the following error building KDrive:
fontcache.c:35:26: fontcacheint.h: No such file or directory
locate turns up nothing even resembling that filename.
Thanks.
-Cameron
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From rjw57 at hermes.cam.ac.uk Thu Aug 19 04:10:07 2004
Date: Thu Aug 19 04:08:44 2004
In-Reply-To: <20040818180230.GE21735@hermes.cam.ac.uk>
<20040818180230.GE21735@hermes.cam.ac.uk>
Message-ID: <20040819111007.GF21735@hermes.cam.ac.uk>
On Wed, Aug 18, 2004 at 07:02:30PM +0100, Rich Wareham wrote:
> On Thu, Aug 12, 2004 at 11:03:36AM -0400, Jim Gettys wrote:
> > Well, we have a release coming up.
> >
> > It sure would be nice to have some up to date eye candy screen
> > shots showing off what the new facilities (e.g. Composite, Damage,
> > Evie, etc.) to go with the release.
>
> Not terribly exciting but I've been hacking Gtk + metacity to support
> the new ARGB visual type. You can how have properly alpha-composited
> window borders.
>
> http://lotsofnakedwomen.com/~rjw57/haxie2.png
>
> Note that this is just a simple PNG theme with some holes drilled in it
> via the gimp. Note the nice blending around the smooth hole.
and I'm almost ready to submit a patch to metacity and Gtk. Look at the
sexiness here with opaque title text on a translucent background:
http://bugzilla.gnome.org/attachment.cgi?id=30745&action=view
:)
--
Rich
From airlied at linux.ie Thu Aug 19 04:40:01 2004
Date: Thu Aug 19 05:01:14 2004
Subject: [Xorg] gamma drm being removed
We have talked about it on the dri lists and we are going to drop the
gamma drm, it is horrible, supports one card and causes a lot of work to
keep it going,
Can you mention in the release notes for this Xorg release that the gamma
drm is deprecated and will be removed for the *next* release....
we think we have tracked down all 3 users...
Dave.
--
Date: Thu Aug 19 05:09:06 2004
In-Reply-To: <Pine.GSO.4.10.10408190806140.10831-100000@helios.et.put.poznan.pl>
References: <Pine.GSO.4.10.10408190806140.10831-100000@helios.et.put.poznan.pl>
On Iau, 2004-08-19 at 07:10, Stanislaw Skowronek wrote:
> Accessing the framebuffer is a rather intricate process involving setup of
> about 20 registers and DMA, so "just copy a virtual fb to screen" would be
> too slow.
To just get you going you can still use shadowfb. That will tell you
which rectangles changed so you can just blit those to screen. That
is how things like the vesa driver are working
>
> However, I can draw accelerated rectangles, pixmaps, lines, polygons (I
> haven't quite worked the stipple out as yet), alpha blending, gradients
> et al. And acceleration on this card is, well, SGI standard :)
>
> How does one write a driver for a monster like this: no fb, good accel?
Pull XFree 3.3.x and take a look at the IBM 8514 driver. This doesn't
use XAA but uses the layer above which simply requires set/get pixel but
allows you to implement higher level functions accelerated.
This driver rotted by XFree 4 as it was for old MCA bus PC hardware
which mostly doesn't exist, and certainly isn't used nowdays.
Alan
Date: Thu Aug 19 06:16:39 2004
In-Reply-To: <Pine.GSO.4.10.10408190806140.10831-100000@helios.et.put.poznan.pl>
References: <Pine.GSO.4.10.10408190806140.10831-100000@helios.et.put.poznan.pl>
Message-ID: <a728f9f9040819061611b86da6@mail.gmail.com>
On Thu, 19 Aug 2004 08:10:57 +0200 (MET DST), Stanislaw Skowronek
<sskowron@et.put.poznan.pl> wrote:
> Hello!
>
> I would like to make a SGI Octane (ImpactSR) X driver. The problem with
> this device is that it is a pure graphics pipeline, i.e. there is no
> directly mapped access to the framebuffer.
>
> Accessing the framebuffer is a rather intricate process involving setup of
> about 20 registers and DMA, so "just copy a virtual fb to screen" would be
> too slow.
>
> However, I can draw accelerated rectangles, pixmaps, lines, polygons (I
> haven't quite worked the stipple out as yet), alpha blending, gradients
> et al. And acceleration on this card is, well, SGI standard :)
Have you figured out enough to do basic 3D accel as well?
Alex
>
> How does one write a driver for a monster like this: no fb, good accel?
>
> Stanislaw Skowronek
>
> --<=>--
> "You're not as old as the trees, not as young as the leaves.
> Not as free as the breeze, not as open as the seas."
>
From Damien.Ciabrini at sophia.inria.fr Thu Aug 19 04:44:28 2004
From: Damien.Ciabrini at sophia.inria.fr (Damien Ciabrini)
Date: Thu Aug 19 06:45:10 2004
Subject: [Xorg] Fixes for Kdrive composite exposures
Message-ID: <1092915868.1656.52.camel@durga>
Hello,
I've found a problem with Kdrive handling of window exposures when
xcompmgr is running (ie in composite code).
To reproduce the bug, start afterstep and then xcompmgr. when both are
loaded, simply start afterstep's background manager:
asetroot 0 0 -l
This make Kdrive SIGBUS when it tries to repaint the root window.
The problem comes from the fact that asetroot make a call to
XCreateWindow with negatives position (IIRC x=-10000, y=-10000).
The server then try to redisplay the whole screen starting from the root
window. It computes the exposed regions to redisplay.
The SIGBUS comes from the fact that when "Redirect to pixmap" is enable
(ie xcompmgr is running), some exposed regions contains negative values.
Note that without xcompmgr (thus without redirect to pixmap) regions
never contains negatives and thus Kdrive never segfaults.
Attached, you can find a simple fix to avoid negatives values in such
exposure regions. With this patch, the computation of exposed regions
returns exactly the same result whether "Redirect to pixmap" is enable
or not.
Can someone review the patch before it can be committed into the tree ?
--
Dam
-------------- next part --------------
Name: xserver-fix-composite-exposures.patch.gz
Type: application/x-gzip
Size: 781 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040819/ec29ee86/xserve
r-fix-composite-exposures.patch.bin
From sskowron at ET.PUT.Poznan.PL Thu Aug 19 06:46:06 2004
From: sskowron at ET.PUT.Poznan.PL (Stanislaw Skowronek)
Date: Thu Aug 19 06:46:37 2004
In-Reply-To: <a728f9f9040819061611b86da6@mail.gmail.com>
Message-ID: <Pine.GSO.4.10.10408191545260.2821-100000@helios.et.put.poznan.pl>
> > However, I can draw accelerated rectangles, pixmaps, lines, polygons (I
> > haven't quite worked the stipple out as yet), alpha blending, gradients
> > et al. And acceleration on this card is, well, SGI standard :)
> Have you figured out enough to do basic 3D accel as well?
Yes, but setup has to be done in s/w. I can't use the Geometry Engines,
yet.
Stanislaw Skowronek
From ftigeot at wolfpond.org Thu Aug 19 08:22:28 2004
Date: Thu Aug 19 08:22:35 2004
Subject: [Xorg] X server autoconfiguration
With 'X -configure', the X server is able to auto-detect which driver
to use and write a sample configuration file.
This mechanism forces to run the server twice, the first time to generate
a sample xorg.conf file which will be used untouched by the server in a
second time.
Is there a way to have the server auto-detect the appropriate graphic
driver at run time without having to use a temporary configuration file ?
--
Francois Tigeot
Date: Thu Aug 19 08:47:34 2004
In-Reply-To: <20040819152228.GA38283@aoi.wolfpond.org>
On Iau, 2004-08-19 at 16:22, Francois Tigeot wrote:
> With 'X -configure', the X server is able to auto-detect which driver
> to use and write a sample configuration file.
>
> This mechanism forces to run the server twice, the first time to generate
> a sample xorg.conf file which will be used untouched by the server in a
> second time.
>
> Is there a way to have the server auto-detect the appropriate graphic
> driver at run time without having to use a temporary configuration file ?
Soething like
mv X Xsv
and set X to be
#!/bin/sh
if [ ! -e /etc/X11/xorg.conf ]; then
X -configure
fi
exec /usr/X11R6/bin/Xsv
Software tools are good. Saves putting a million ugly special cases into
applications 8)
Date: Thu Aug 19 08:49:31 2004
Subject: [Xorg] gamma drm being removed
References: <Pine.LNX.4.58.0408191238350.9701@skynet>
Message-ID: <a728f9f904081906026f8ab961@mail.gmail.com>
On Thu, 19 Aug 2004 12:40:01 +0100 (IST), Dave Airlie <airlied@linux.ie> wrote:
>
> We have talked about it on the dri lists and we are going to drop the
> gamma drm, it is horrible, supports one card and causes a lot of work to
> keep it going,
>
> Can you mention in the release notes for this Xorg release that the gamma
> drm is deprecated and will be removed for the *next* release....
>
I added a note to bug 999.
Alex
> we think we have tracked down all 3 users...
>
> Dave.
>
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / airlied at skynet.ie
> pam_smb / Linux DECstation / Linux VAX / ILUG person
>
> _______________________________________________
> xorg mailing list
>
From Alan.Coopersmith at Sun.COM Thu Aug 19 09:00:50 2004
Date: Thu Aug 19 09:00:53 2004
Message-ID: <4124CEB2.2020000@sun.com>
Francois Tigeot wrote:
>
> second time.
>
If you have no xorg.conf or XF86config files, it will try to do exactly that
already.
--
Date: Thu Aug 19 09:10:34 2004
Message-ID: <20040819161021.GE38283@aoi.wolfpond.org>
On Thu, Aug 19, 2004 at 03:45:23PM +0100, Alan Cox wrote:
> On Iau, 2004-08-19 at 16:22, Francois Tigeot wrote:
> > With 'X -configure', the X server is able to auto-detect which driver
> > to use and write a sample configuration file.
> >
> > This mechanism forces to run the server twice, the first time to generate
> > a sample xorg.conf file which will be used untouched by the server in a
> > second time.
> >
> > Is there a way to have the server auto-detect the appropriate graphic
> > driver at run time without having to use a temporary configuration file ?
>
> Soething like
>
> mv X Xsv
>
> and set X to be
>
> #!/bin/sh
>
> if [ ! -e /etc/X11/xorg.conf ]; then
> X -configure
> fi
> exec /usr/X11R6/bin/Xsv
>
> Software tools are good. Saves putting a million ugly special cases into
> applications 8)
I was hoping the special cases were already written :)
The generated xorg.conf file will need to be parsed and since this will be
done from a ramdisk with limited space and tools, it should become quite
fun :-/
--
Francois Tigeot
From matthieu.herrb at laas.fr Thu Aug 19 09:14:13 2004
Date: Thu Aug 19 09:14:18 2004
Message-ID: <4124D1D5.7000403@laas.fr>
>
> second time.
>
>
Since XFree86 4.3.99.something the X server is able to run without a
configuration file at all.
Otherwise a simple wrapper like
if [ ! -f /etc/X11/xorg.conf ]; then
Xorg -configure
mv ${HOME}/Xorg.conf.new /etc/X11/xorg.conf
fi
Xorg
will do the job too (and let you tweak the generated xorg.conf
afterwards if needed).
--
Matthieu Herrb
-------------- next part --------------
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4071 bytes
Desc: S/MIME Cryptographic Signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040819/1fbf96bf/smime.
bin
Date: Thu Aug 19 09:15:12 2004
In-Reply-To: <4124CEB2.2020000@sun.com>
<4124CEB2.2020000@sun.com>
Message-ID: <20040819161500.GF38283@aoi.wolfpond.org>
On Thu, Aug 19, 2004 at 09:00:50AM -0700, Alan Coopersmith wrote:
> Francois Tigeot wrote:
> >With 'X -configure', the X server is able to auto-detect which driver
> >to use and write a sample configuration file.
> >
> >This mechanism forces to run the server twice, the first time to generate
> >a sample xorg.conf file which will be used untouched by the server in a
> >second time.
> >
> >Is there a way to have the server auto-detect the appropriate graphic
> >driver at run time without having to use a temporary configuration file ?
>
> If you have no xorg.conf or XF86config files, it will try to do exactly that
> already.
It would really be great if this could be done with a minimal xorg.conf (I
need to define the keyboard layout), but this seems impossible.
--
Francois Tigeot
From saturn_vk at abv.bg Thu Aug 19 09:28:28 2004
Date: Thu Aug 19 09:28:35 2004
something has gone terribly wrong in enlightenment 0.16.7 when xcompmgr is start
ed:
http://urandom.hit.bg/comperror.jpg
-----------------------------------------------------------------
From matthieu.herrb at laas.fr Thu Aug 19 09:38:11 2004
Date: Thu Aug 19 09:38:16 2004
In-Reply-To: <20040819161500.GF38283@aoi.wolfpond.org>
References: <20040819152228.GA38283@aoi.wolfpond.org> <4124CEB2.2020000@sun.co
m>
<20040819161500.GF38283@aoi.wolfpond.org>
Message-ID: <4124D773.7070504@laas.fr>
> On Thu, Aug 19, 2004 at 09:00:50AM -0700, Alan Coopersmith wrote:
>
>>Francois Tigeot wrote:
>>
>>>With 'X -configure', the X server is able to auto-detect which driver
>>>to use and write a sample configuration file.
>>>
>>>This mechanism forces to run the server twice, the first time to generate
>>>a sample xorg.conf file which will be used untouched by the server in a
>>>second time.
>>>
>>>Is there a way to have the server auto-detect the appropriate graphic
>>>driver at run time without having to use a temporary configuration file ?
>>
>>If you have no xorg.conf or XF86config files, it will try to do exactly that
>>already.
>
>
> It would really be great if this could be done with a minimal xorg.conf (I
> need to define the keyboard layout), but this seems impossible.
>
You can use setxkbmap to set the keyboard layout after the X server
startup.
--
Matthieu Herrb
-------------- next part --------------
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4071 bytes
Desc: S/MIME Cryptographic Signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040819/b66458bb/smime-
0001.bin
Date: Thu Aug 19 13:17:31 2004
Subject: [Xorg] keyboard driver fails to initialize if DoLoadableServer=NO
In-Reply-To: <4124380F.6070009@laas.fr>
References: <4124380F.6070009@laas.fr>
On Thu, Aug 19, 2004 at 07:18:07AM +0200, Matthieu Herrb wrote:
> See <http://freedesktop.org/bugzilla/show_bug.cgi?id=1133>
Matthieu, this bug and #1132 look like they could be made release
blockers since they fix build and run-time problems. If you agree,
please set the "Bug # blocks:" field in each bug to 351 (i.e., the
release bug), so that the release-wranglers will consider including them
in the upcoming release.
Thanks,
Kevin
From shawn.starr at rogers.com Thu Aug 19 19:06:11 2004
From: shawn.starr at rogers.com (Shawn Starr)
Date: Thu Aug 19 19:12:56 2004
Subject: [Xorg] Getting GATOS branch created on Xorg
Message-ID: <200408192206.11770.shawn.starr@rogers.com>
It would be best to discuss this so that it gets more visibility.
What does everyone think?
Shawn.
On Tue, 17 Aug 2004, Shawn Starr wrote:
>
> Where would the latest code base be available? Would you want write access
to
> CVS? Its possible you'd get a branch for GATOS and then when its stablized
> within Xorg be merged into -HEAD.
Good question. The thing is I had very little time for development lately
so perhaps this is best asked of other GATOS developers.
So, I think it would make sense to put this question to the mailing list -
it might be better for everyone if GATOS development switches to X.Org
CVS, at least as far as driver work is concerned.
What is your opinion ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?best
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Dergachev
>
> Shawn.
>
> On August 15, 2004 12:38, Vladimir Dergachev wrote:
>> On Sun, 15 Aug 2004, Shawn Starr wrote:
>>> If you can come on #freedesktop on irc.freenode.net that would be great.
>>> Since some people are interested in getting into the tree.
>>
>> I am away at a conference, so it would be best to do this over e-mail.
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ?best
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Dergachev
>>
>>> Shawn.
>>>
>>> On August 15, 2004 03:20, you wrote:
>>>> On Sun, 15 Aug 2004, Shawn Starr wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> I would like to you if this is planned to be done or if not can I have
>>>>> your agreement on doing this myself?
>>>>>
>>>>> I would like to get GATOS into Xorg so that it will be easier to
>>>>> maintain.
>>>>>
>>>>> What do you think?
>>>>
>>>> I think it is a great idea. I am not sure how X.org operates, but it
>>>> might make sense to merge GATOS code directly - ati.2 modules have been
>>>> very well tested..
>>>>
>>>> Let me know what your plans are :)
>>>>
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?best
>>>>
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Vladimir Dergachev
>>>>
>>>>> Shawn.
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.2.5 (GNU/Linux)
>>>>>
>>>>> iD8DBQFBHwhcsX/SQXZigqcRAsAhAKCHSGaptIRsTM/cOnmbw4pxqER2awCeO4RS
>>>>> mctIHgIgocmmRQq7gOSvKVM=
>>>>> =xDrq
>>>>> -----END PGP SIGNATURE-----
>
Date: Thu Aug 19 19:37:03 2004
In-Reply-To: <200408192206.11770.shawn.starr@rogers.com>
What would it take to get GATOS into the video4linux model instead of
having it's own driver? With v4l support would be in the kernel.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
Date: Thu Aug 19 21:48:14 2004
In-Reply-To: <Pine.LNX.4.61.0408200033070.19291@node2.an-vo.com>
Why not add v4l support to the DRM device driver and ignore the X
driver?
--- Vladimir Dergachev <volodya@mindspring.com> wrote:
>
>
> On Thu, 19 Aug 2004, Jon Smirl wrote:
>
> > What would it take to get GATOS into the video4linux model instead
> of
> > having it's own driver? With v4l support would be in the kernel.
>
> Major rewrite of X radeon driver. All-in-Wonder cards require a
> portion of
> video memory (preferably dynamically allocated) for video capture or
> playback.
>
> Also, video playback requires overlay scalar unit - which thus must
> be
> shared with Xserver's XvPutImage functionality.
>
> It is simply much easier to implement video-in support in the same
> place
> the rest of Radeon driver resides.
>
> best
>
> Vladimir Dergachev
>
>
> >
> >
> > =====
> > Jon Smirl
> > jonsmirl@yahoo.com
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Y! Messenger - Communicate in real time. Download now.
> > http://messenger.yahoo.com
> >
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Date: Thu Aug 19 22:27:33 2004
night.
listed below.
The main release bug is #351:
Update:
-------
The process for having bugs be considered as release blockers is to set
the bug's "Bug # blocks:" field to the release bug, 351. The release
wranglers will then determine if the bug is one that should hold up the
release or be deferred until after the release. As we are currently in
the code freeze, only major blocker bugs are being considered.
Blocker bug stats:
------------------
Fixed yesterday: 3
Added yesterday: 5
-----------------------------
- Waiting for patch
- After patch is attached to bug report, others using UseInstalled
should test the patch to see if it works for them
* Bug #1126: wraphelp.c not in distro
- Due to US export laws, wraphelp.c has not been included
- Jim Gettys has begun the process to allow us to include it in future
releases
* Bug #1137: xterm fix for utmp cleanup
- Looks like this one is needed
- Just need a patch
* Bug #1138: Composite crash in Polyline
- Eric Anholt is investigating
* Bug #1139: SiS driver needs to support 1280x800 LCD panels
- Change limited to SiS driver only
- Will review on release wranglers call on Friday
From volodya at mindspring.com Thu Aug 19 21:36:39 2004
From: volodya at mindspring.com (Vladimir Dergachev)
Date: Thu Aug 19 22:54:44 2004
Message-ID: <Pine.LNX.4.61.0408200033070.19291@node2.an-vo.com>
On Thu, 19 Aug 2004, Jon Smirl wrote:
> What would it take to get GATOS into the video4linux model instead of
> having it's own driver? With v4l support would be in the kernel.
Major rewrite of X radeon driver. All-in-Wonder cards require a portion of
video memory (preferably dynamically allocated) for video capture or playback.
Also, video playback requires overlay scalar unit - which thus must be
shared with Xserver's XvPutImage functionality.
It is simply much easier to implement video-in support in the same place
the rest of Radeon driver resides.
best
Vladimir Dergachev
>
>
> =====
> Jon Smirl
> jonsmirl@yahoo.com
>
>
>
> __________________________________
> Do you Yahoo!?
> Y! Messenger - Communicate in real time. Download now.
> http://messenger.yahoo.com
>
Date: Thu Aug 19 22:54:53 2004
On Thu, 19 Aug 2004, Jon Smirl wrote:
> Why not add v4l support to the DRM device driver and ignore the X
> driver?
Because you would not be able to run X then. You do not want your
offscreen pixmaps overwritten with video data on a random basis.
The only way this can work is if the video memory allocator is accessible
from video-in code.
best
Vladimir Dergachev
>
> --- Vladimir Dergachev <volodya@mindspring.com> wrote:
>
>>
>>
>> On Thu, 19 Aug 2004, Jon Smirl wrote:
>>
>>> What would it take to get GATOS into the video4linux model instead
>> of
>>> having it's own driver? With v4l support would be in the kernel.
>>
>> Major rewrite of X radeon driver. All-in-Wonder cards require a
>> portion of
>> video memory (preferably dynamically allocated) for video capture or
>> playback.
>>
>> Also, video playback requires overlay scalar unit - which thus must
>> be
>> shared with Xserver's XvPutImage functionality.
>>
>> It is simply much easier to implement video-in support in the same
>> place
>> the rest of Radeon driver resides.
>>
>> best
>>
>> Vladimir Dergachev
>>
>>
>>>
>>>
>>> =====
>>> Jon Smirl
>>> jonsmirl@yahoo.com
>>>
>>>
>>>
>>> __________________________________
>>> Do you Yahoo!?
>>> Y! Messenger - Communicate in real time. Download now.
>>> http://messenger.yahoo.com
>>>
>>
>
>
> =====
> Jon Smirl
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
From de_lupus at pandora.be Fri Aug 20 02:39:57 2004
Date: Fri Aug 20 02:25:45 2004
Subject: [Xorg] Is there a way for a program to detect if composite is
enabled
I was looking at following patch for gaim and I thought there should be
a better way:
Summary: (?)
Disable tooltip shadows when X composite extension installed
The drop shadows on the buddy list tooltips interfere
with the real shadows being provided by the new X
composite extension. Eventually the real shadows from
a composition manager can probably replace any shadows
in gaim. But for now this patch detects if the
composition extension is installed at configure time
and if so it disables the drop shadows.
While having the composite extension installed does not
necessarily mean it's being used, this is the best we
can do without runtime checks. It already seems silly
enough to be checking for something we don't need.
https://sourceforge.net/tracker/index.php?func=detail&aid=1010290&group_id=235&a
tid=300235
--
From torgeir at pobox.com Fri Aug 20 02:59:34 2004
From: torgeir at pobox.com (Torgeir Veimo)
Date: Fri Aug 20 02:59:40 2004
Subject: [Xorg] binary cvs snapshots
Message-ID: <1092995974.10923.50.camel@atlantis.netenviron.com>
Are anyone providing binary snapshots of current CVC?
--
Torgeir Veimo <torgeir@pobox.com>
From thomas at winischhofer.net Fri Aug 20 04:39:35 2004
Date: Fri Aug 20 04:41:39 2004
Subject: [Xorg] Documentation updates
Message-ID: <4125E2F7.3070302@winischhofer.net>
I have some slight changes to the SiS driver's documentation in the queue.
Am I supposed to edit the SiS.sgml file or the README.SiS file? Or both?
Or is anybody going to update the formatted docs before the release?
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Fri Aug 20 04:57:18 2004
Subject: [Xorg] Documentation updates
In-Reply-To: <4125E2F7.3070302@winischhofer.net>
References: <4125E2F7.3070302@winischhofer.net>
On Fri, 2004-08-20 at 07:39, Thomas Winischhofer wrote:
> I have some slight changes to the SiS driver's documentation in the queue.
>
> Am I supposed to edit the SiS.sgml file or the README.SiS file? Or both?
IIRC, the README.SiS file is generated from SiS.sgml, so you'd edit
the sgml file.
>
> Or is anybody going to update the formatted docs before the release?
I'd expect the driver maintainer to update the file.
We certainly reformatted the documents before the April release;
haven't done that part of the process yet for this release.
- Jim
From roberto at monornet.hu Fri Aug 20 08:47:42 2004
From: roberto at monornet.hu (roberTO)
Date: Fri Aug 20 05:08:26 2004
In-Reply-To: 20040818180230.GE21735@hermes.cam.ac.uk
Message-ID: <1093016861.22410.1.camel@mon227>
Hi!
The patc or pathed metacity and gtk downloadable???
(enable Gtk + metacity to support> the new ARGB visual type. You can how
have properly alpha-composited> window borders.)
I need this!
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040820/301c9176/attachm
ent-0001.htm
From krh at bitplanet.net Fri Aug 20 05:10:41 2004
Date: Fri Aug 20 05:13:02 2004
Subject: [Xorg] binary cvs snapshots
In-Reply-To: <1092995974.10923.50.camel@atlantis.netenviron.com>
References: <1092995974.10923.50.camel@atlantis.netenviron.com>
Message-ID: <4125EA41.4010203@bitplanet.net>
Torgeir Veimo wrote:
> Are anyone providing binary snapshots of current CVC?
If you are using Fedora you can get RPMs for the 902 snapshot here:
ftp://download.fedora.redhat.com:/pub/fedora/linux/core/development/i386/Fedora/
RPMS
Look for the xorg-x11 packages.
Kristian
From jonsmirl at yahoo.com Fri Aug 20 09:31:14 2004
Date: Fri Aug 20 09:31:16 2004
There is already code in X for coordinating video memory usage with
DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
Same mechansim can be used to protect the video streaming memory.
Several other cards use kernel based v4l drivers, why is the radeon
special?
>
>
> On Thu, 19 Aug 2004, Jon Smirl wrote:
>
> > Why not add v4l support to the DRM device driver and ignore the X
> > driver?
>
> Because you would not be able to run X then. You do not want your
> offscreen pixmaps overwritten with video data on a random basis.
>
> The only way this can work is if the video memory allocator is
> accessible
> from video-in code.
>
=====
Jon Smirl
jonsmirl@yahoo.com
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
From volodya at mindspring.com Fri Aug 20 09:47:27 2004
Date: Fri Aug 20 09:47:33 2004
On Fri, 20 Aug 2004, Jon Smirl wrote:
> There is already code in X for coordinating video memory usage with
> DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
> Same mechansim can be used to protect the video streaming memory.
Last time I checked this was not straightforward. Furthermore, aren't
3d buffers fixed in size after Xserver startup ?
>
> Several other cards use kernel based v4l drivers, why is the radeon
> special?
I am only aware of bt848 cards - these are standalone video capture device
and do not have to share anything.
Also, AIW cards do have a v4l interface - however it is an auxiliary
driver only, it needs Xv program to setup the video stream for any data to
be available (this way it can use video memory already allocated by
Xserver for video stream)
best
Vladimir Dergachev
>
>
>>
>>
>> On Thu, 19 Aug 2004, Jon Smirl wrote:
>>
>>> Why not add v4l support to the DRM device driver and ignore the X
>>> driver?
>>
>> Because you would not be able to run X then. You do not want your
>> offscreen pixmaps overwritten with video data on a random basis.
>>
>> The only way this can work is if the video memory allocator is
>> accessible
>> from video-in code.
>>
>
>
> =====
> Jon Smirl
>
>
>
> _______________________________
> Do you Yahoo!?
> Express yourself with Y! Messenger! Free. Download now.
> http://messenger.yahoo.com
>
From shawn.starr at rogers.com Fri Aug 20 10:16:01 2004
Date: Fri Aug 20 10:22:44 2004
Subject: [Xorg] Re: [GATOS]Getting GATOS branch created on Xorg
In-Reply-To: <20040820074425.GK18012@watri.org.au>
Message-ID: <20040820171601.21527.qmail@web88003.mail.re2.yahoo.com>
This is best for Vladimir to answer ;-)
Anders Johansson <ajh@watri.org.au> wrote:Hi,
I am not an active developer but I have been following the project on
and off since 1999. To me it seems as if the project is currently
progressing at a pace which is too slow to produce useful result. I
just want to give my opinion about what I think should be done:
I think I would be a good idea to split the project into two. One part
which deals with TV and monitor output (+ 3D and xv) and one which
deals with TV input.
The output bit should be merged with X.org and the input bit with V4L.
Is it possible to cut a deal with ATI for giving the docs to other
projects so the development could continue?
Sorry,
//Anders
> It would be best to discuss this so that it gets more visibility.
>
> What does everyone think?
>
> Shawn.
>
> On Tue, 17 Aug 2004, Shawn Starr wrote:
>
> >
> > Where would the latest code base be available? Would you want write access
> to
> > CVS? Its possible you'd get a branch for GATOS and then when its stablized
> > within Xorg be merged into -HEAD.
>
> Good question. The thing is I had very little time for development lately
> so perhaps this is best asked of other GATOS developers.
>
> So, I think it would make sense to put this question to the mailing list -
> it might be better for everyone if GATOS development switches to X.Org
> CVS, at least as far as driver work is concerned.
>
> What is your opinion ?
>
> best
>
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040820/edd35d22/attachm
ent.html
Date: Fri Aug 20 11:07:43 2004
In-Reply-To: <20040820171601.21527.qmail@web88003.mail.re2.yahoo.com>
References: <20040820171601.21527.qmail@web88003.mail.re2.yahoo.com>
On Fri, 20 Aug 2004, Shawn Starr wrote:
> This is best for Vladimir to answer ;-)
>
> Anders Johansson <ajh@watri.org.au> wrote:Hi,
>
> I am not an active developer but I have been following the project on
> and off since 1999. To me it seems as if the project is currently
> progressing at a pace which is too slow to produce useful result. I
> just want to give my opinion about what I think should be done:
Yes and no. The parts that are most visible (like releases of new code)
are indeed slow-moving - this was mostly done by myself and I am very busy
at the moment.
However, other developers are active - for example the tv_output
branch was written by Federico Ulivi quite recently.
>
> I think I would be a good idea to split the project into two. One part
> which deals with TV and monitor output (+ 3D and xv) and one which
> deals with TV input.
>
> The output bit should be merged with X.org and the input bit with V4L.
This is a recurring suggestion. It is quite sensible when one ignores the
particulars of hardware in All-in-Wonder cards (and similar ones).
First of all, V4L was *designed* for standalone capture cards *ONLY*.
For example, both video-in and TV-output use the *SAME* chip. Do you
really want two unrelated pieces of code accessing it at the same time ?
Secondly, V4L is kernel-space code. There is *NO* reason to have
initialization code in kernel-space - it is not time sensitive or cpu
intensive. It is much simpler to develop the code in user-space.
Thirdly, there is existing code that works within framework of Xv
extension. Several people tried to make a v4l driver - there was no
working code to date. You are welcome to try - perhaps changes in recent
kernels would make it easier.
>
> Is it possible to cut a deal with ATI for giving the docs to other
> projects so the development could continue?
AFAIK, ATI does not provide documentation to projects, but to individuals.
Also, keep in mind that most of that documentation is simply listing of
registers, which you can see in existing header files as well. It is not
necessary to have documentation for porting. (In fact, initial GATOS code
was produced without any documentation at all, except for a header file
from XFree86).
best
Vladimir Dergachev
>
>
>
> Sorry,
> //Anders
>
>
>> It would be best to discuss this so that it gets more visibility.
>>
>> What does everyone think?
>>
>> Shawn.
>>
>> On Tue, 17 Aug 2004, Shawn Starr wrote:
>>
>>>
>>> Where would the latest code base be available? Would you want write access
>> to
>>> CVS? Its possible you'd get a branch for GATOS and then when its stablized
>>> within Xorg be merged into -HEAD.
>>
>> Good question. The thing is I had very little time for development lately
>> so perhaps this is best asked of other GATOS developers.
>>
>> So, I think it would make sense to put this question to the mailing list -
>> it might be better for everyone if GATOS development switches to X.Org
>> CVS, at least as far as driver work is concerned.
>>
>> What is your opinion ?
>>
>> best
>>
>> Vladimir Dergachev
>
>
>
Date: Fri Aug 20 11:16:28 2004
> On Fri, 20 Aug 2004, Jon Smirl wrote:
>
> > There is already code in X for coordinating video memory usage with
> > DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
> > Same mechansim can be used to protect the video streaming memory.
>
> Last time I checked this was not straightforward. Furthermore, aren't
> 3d buffers fixed in size after Xserver startup ?
There is a DRM API for allocating VRAM memory from the pool assigned to
3D use. Just allocate yourself a chunk and don't start any 3D
operations on it. You get a pointer to it so you can do anything you
want with it.
> > Several other cards use kernel based v4l drivers, why is the radeon
> > special?
>
> I am only aware of bt848 cards - these are standalone video capture
> device and do not have to share anything.
Check out the Matrox implementation.
> Also, AIW cards do have a v4l interface - however it is an auxiliary
> driver only, it needs Xv program to setup the video stream for any
> data to be available (this way it can use video memory already
> allocated by Xserver for video stream)
I always thought the best solution would be combining the radeon V4L
device driver into the radeon DRM driver. That way we only have a
single device driver trying to attach to the hardware. The combined
driver would expose two interfaces, DRM and V4L. Since the drivers are
combined you can easily sort out the memory allocation.
Have you tried doing the experiment of combining the radeon DRM and V4L
device drivers? I would start out by just mixing up all of the code.
But the final version should make the V4L support an add-on module to
the DRM one.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Fri Aug 20 11:34:37 2004
On Gwe, 2004-08-20 at 17:31, Jon Smirl wrote:
> There is already code in X for coordinating video memory usage with
> DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
> Same mechansim can be used to protect the video streaming memory.
Its not dynamic. AlanH added stuff to head in that direction but it isnt
there yet for the general case. The VIA/SIS drivers support this in
theory but not most of the others. (and the VIA/SIS memory mangler
isn't where we want to end up)
Alan
Date: Fri Aug 20 11:40:28 2004
Why can't you use the DRM API to allocate a piece of texture memory?
The better model is a merged driver with coordinated memory management.
--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2004-08-20 at 17:31, Jon Smirl wrote:
> > There is already code in X for coordinating video memory usage with
> > DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
> > Same mechansim can be used to protect the video streaming memory.
>
> Its not dynamic. AlanH added stuff to head in that direction but it
> isnt
> there yet for the general case. The VIA/SIS drivers support this in
> theory but not most of the others. (and the VIA/SIS memory mangler
> isn't where we want to end up)
>
> Alan
>
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Date: Fri Aug 20 12:02:02 2004
On Fri, 20 Aug 2004, Jon Smirl wrote:
> Why can't you use the DRM API to allocate a piece of texture memory?
I can. But I will receive texture memory in *system* RAM.
Video capture requires a piece of *video* RAM, the one that resides
directly on the card.
best
Vladimir Dergachev
>
> The better model is a merged driver with coordinated memory management.
>
> --- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>> On Gwe, 2004-08-20 at 17:31, Jon Smirl wrote:
>>> There is already code in X for coordinating video memory usage with
>>> DRM. The DRM memory manager keeps 2D X from stomping on 3D buffers.
>>> Same mechansim can be used to protect the video streaming memory.
>>
>> Its not dynamic. AlanH added stuff to head in that direction but it
>> isnt
>> there yet for the general case. The VIA/SIS drivers support this in
>> theory but not most of the others. (and the VIA/SIS memory mangler
>> isn't where we want to end up)
>>
>> Alan
>>
>>
>
>
> =====
> Jon Smirl
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
Date: Fri Aug 20 12:12:12 2004
<Pine.LNX.4.61.0408201339140.22448@node2.an-vo.com>
There is one more argument in favor of current implementation:
All-in-Wonder cards can be programmed to display video capture data as
it arrives in video RAM, without transferring to main memory via PCI bus.
This saves system resources and improves latency.
For this to work, one needs to use XvPutVideo - so Xv extension should be
aware of how to set this up.
best
Vladimir Dergachev
Date: Fri Aug 20 12:34:12 2004
Ian, what's the best way to get DRM to allocate a piece of video memory
for V4L to use, or do we need to wait for your new memory manager?
This can certainly be done by merging the radeon V4L driver code into
the DRM driver. Is there a way to do this from user space with changing
DRM?
> On Fri, 20 Aug 2004, Jon Smirl wrote:
>
> > Why can't you use the DRM API to allocate a piece of texture
> memory?
>
> I can. But I will receive texture memory in *system* RAM.
>
> Video capture requires a piece of *video* RAM, the one that resides
> directly on the card.
>
> best
>
=====
Jon Smirl
jonsmirl@yahoo.com
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
Date: Fri Aug 20 13:48:12 2004
Message-ID: <41266386.5010700@us.ibm.com>
Jon Smirl wrote:
> Ian, what's the best way to get DRM to allocate a piece of video memory
> for V4L to use, or do we need to wait for your new memory manager?
>
> This can certainly be done by merging the radeon V4L driver code into
> the DRM driver. Is there a way to do this from user space with changing
> DRM?
Either that or carve off a chunk at driver init time (like is done for
the back & depth buffers). :( Basically, the video capture process
isn't different from other accelerated rendering: you do it to on-screen
memory or to the moral equivalent of a pbuffer.
>
>>On Fri, 20 Aug 2004, Jon Smirl wrote:
>>
>>
>>>Why can't you use the DRM API to allocate a piece of texture
>>
>>memory?
>>
>>I can. But I will receive texture memory in *system* RAM.
>>
>>Video capture requires a piece of *video* RAM, the one that resides
>>directly on the card.
From spyderous at gentoo.org Fri Aug 20 14:53:25 2004
Date: Fri Aug 20 14:59:10 2004
Subject: [Xorg] [PATCH] xorgconfig ignores FontDir
In-Reply-To: <20040810.8OS.81243100@groupware.gentoo.org>
References: <20040810.8OS.81243100@groupware.gentoo.org>
On Mon, 2004-08-09 at 22:48, Donnie Berkholz wrote:
> If there are no problems with this patch, I'd like to get it into this
> release. The associated bug is #826.
As I submitted this to Bugzilla and this list prior to the code freeze,
there were no objections, it is a fairly trivial change and xorgconfig
is a little-used tool, it would be great if we could get this into the
release.
Thanks again,
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040820/3ce42ec3/attach
ment.pgp
Date: Fri Aug 20 15:34:39 2004
Subject: [Xorg] Xvfb visuals.
Message-ID: <200408202207.RAA41666@xanth.austin.ibm.com>
I'm just curious about this.
I started Xvfb and noted that it is defaulting to a 4-bit Pseudo Color visual.
I realize that this saves on memory usage, but is this really supposed to
be the default visual?
Dan
Date: Fri Aug 20 17:36:28 2004
In-Reply-To: <20040821100809.D22530@artificial-stupidity.net>
<20040821100809.D22530@artificial-stupidity.net>
On Sat, 21 Aug 2004, Jaymz Julian wrote:
> On Fri, Aug 20, 2004 at 03:12:05PM -0400, Vladimir Dergachev wrote:
>>
>>
>> There is one more argument in favor of current implementation:
>>
>> All-in-Wonder cards can be programmed to display video capture data as
>> it arrives in video RAM, without transferring to main memory via PCI bus.
>
> Hrm, doesn't the matrox marvel v4l driver do this as well? (except that it
> stopped playing nice with Xv post-Xfree4.1 sometime, but that's not
> uncommon for out of tree drivers, is it? :-p)
Well, GATOS plays nice with Xv - in fact it is based on it..
I looked at marvel.sf.net - am I right in thinking that their chip outputs
MJPEG directly ? In this case it would be quite different from AIW cards
which produce uncompressed YUV422.
Do you know whether Marvel cards need to use video RAM for transfer of
video data ?
best
Vladimir Dergachev
>
> -- jaymz
>
> --
> --
> Jaymz Julian - Coder, Visionary, Fat Ass.
> "Hannibal is a serial killer. He only likes to kill and eat people.
> Very few people have Ì want to be killed and eaten' on their cards,
> so Hannibal is out of a job." - http://cards.sf.net
>
From spyderous at gentoo.org Fri Aug 20 21:51:56 2004
Date: Fri Aug 20 22:24:39 2004
Subject: [Xorg] Fun bug: DPMS randomly starts
http://freedesktop.org/bugzilla/show_bug.cgi?id=792 could be nice to get
fixed for the release, if anyone with a little time feels like it.
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040820/81162685/attach
ment.pgp
From thomas.klein at lanterne.org Sat Aug 21 09:42:41 2004
Date: Sat Aug 21 09:42:47 2004
Subject: [Xorg] composite test
piii750
ati rage mach64 Mo
linux 2.6.8
debian unstable
(it's a laptop)
last xorg cvs
last xcompmgr cvs
running X in 16bpp, xcompmgr
It's unusable.
I can't move a window, resize, even typing something in xterm is slow.
What's wrong with my conf ?
Do I miss something ?
thanks in advance, and btw, great job !
t.
Date: Sat Aug 21 10:43:02 2004
References: <1093063916.8033.1.camel@localhost>
I added this as a blocker to be discussed at Monday's call;
I suspect we shouldn't hold up the release for this, if someone
can come up with a fix we can use (was the fix done by David,
or just committed by David from someone else?).
At worst, I suspect it should be fixed if we can before release.
- Jim
On Sat, 2004-08-21 at 00:51, Donnie Berkholz wrote:
> http://freedesktop.org/bugzilla/show_bug.cgi?id=792 could be nice to get
> fixed for the release, if anyone with a little time feels like it.
From morphie at unravel-music.nl Sat Aug 21 13:20:44 2004
Date: Sat Aug 21 13:19:06 2004
On Saturday 21 August 2004 18:42, thomas klein wrote:
> What's wrong with my conf ?
>
> Do I miss something ?
In your "Device" section. Put this in it:
Option "AGPFastWrite" "On"
But still, I have some troubles with transparency also. Are there more
switches/options to be set?
- Dennie
From volodya at mindspring.com Sat Aug 21 13:37:09 2004
Date: Sat Aug 21 13:37:15 2004
On Sat, 21 Aug 2004, Jim Gettys wrote:
> I added this as a blocker to be discussed at Monday's call;
> I suspect we shouldn't hold up the release for this, if someone
> can come up with a fix we can use
> (was the fix done by David,
> or just committed by David from someone else?).
Stupid question, but why is this important ?
best
Vladimir Dergachev
>
> At worst, I suspect it should be fixed if we can before release.
> - Jim
>
> On Sat, 2004-08-21 at 00:51, Donnie Berkholz wrote:
>> http://freedesktop.org/bugzilla/show_bug.cgi?id=792 could be nice to get
>> fixed for the release, if anyone with a little time feels like it.
>
> _______________________________________________
> xorg mailing list
>
From fxkuehl at gmx.de Sat Aug 21 13:37:35 2004
From: fxkuehl at gmx.de (Felix =?ISO-8859-1?Q?K=FChling?=)
Date: Sat Aug 21 13:42:08 2004
Subject: [Xorg] Where to commit Savage DDX changes?
Message-ID: <20040821223735.108953ac.felix@trabant>
Hi,
I need to make a small change to the savage DDX in order to make the new
(not yet committed) DRI interface code work properly. Currently the
visual configs created by the server don't match the ones created by
__driUtilFillInModes. Where should I commit this change? DRI CVS is dead
and Xorg CVS doesn't have the latest DRI support integrated yet (Alex'
patch). I suppose that won't happen before the next Xorg release. Alex,
what about developping DRI support in the Savage DDX on a branch in Xorg
CVS for a while? I guess this would be a good idea anyway, when I start
revamping the DRM.
Regards,
Felix
| Felix K?hling <fxkuehl@gmx.de> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
From matthieu.herrb at laas.fr Sat Aug 21 14:16:33 2004
Date: Sat Aug 21 14:16:39 2004
Subject: [Xorg] Wraphelp.c Re: CVS Update: xc (branch: trunk)
In-Reply-To: <20040821020644.E22559F7D5@freedesktop.org>
References: <20040821020644.E22559F7D5@freedesktop.org>
Message-ID: <4127BBB1.3040702@laas.fr>
Jim Gettys wrote:
> CVSROOT: /cvs/xorg
> Module name: xc
> Changes by: jg@pdx. 04/08/20 19:06:44
>
> Log message:
> Add Wraphelp.c to lib/Xdmcp, at long last, along with the U.S.
> government required notifications. The website notification went up
> first.
>
> Clean up Wraphelp.c so that it compiles cleanly.
>
> I chose the version Australian version written for R5 written
> by Eric Eay@psych.psy.uq.oz.au, as I don't know where the original one
> was, and didn't want to touch XFree86.
>
Hmm, this version doesn't work on LP64 big endian machines (like
*BSD/sparc64). The problems were fixed in OpenBSD. May I suggest to
switch to this version (it's the same origin, with the LP64 problems
fixed):
<http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/lib/Xdmcp/Wraphelp.c>
--
Matthieu
Date: Sat Aug 21 14:39:23 2004
Subject: [Xorg] Re: Where to commit Savage DDX changes?
In-Reply-To: <20040821223735.108953ac.felix@trabant>
References: <20040821223735.108953ac.felix@trabant>
Message-ID: <a728f9f90408211439365ac8fe@mail.gmail.com>
On Sat, 21 Aug 2004 22:37:35 +0200, Felix K?hling <fxkuehl@gmx.de> wrote:
> Hi,
>
> I need to make a small change to the savage DDX in order to make the new
> (not yet committed) DRI interface code work properly. Currently the
> visual configs created by the server don't match the ones created by
> __driUtilFillInModes. Where should I commit this change? DRI CVS is dead
> and Xorg CVS doesn't have the latest DRI support integrated yet (Alex'
> patch). I suppose that won't happen before the next Xorg release. Alex,
> what about developping DRI support in the Savage DDX on a branch in Xorg
> CVS for a while? I guess this would be a good idea anyway, when I start
> revamping the DRM.
This is probably a good idea, as I'm not sure how long cvs will be
locked down for pending the new xorg release. the X tree on my savage
laptop has a HUGE number of changes on it including revamped streams
handling, mode validation, and dualhead/mergedfb support for mobile
savages. I'd like to get them committed somewhere at somepoint.
Alex
>
> Regards,
> Felix
>
> | Felix K?hling <fxkuehl@gmx.de> http://fxk.de.vu |
> | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
>
Date: Sat Aug 21 14:54:54 2004
Subject: [Xorg] Wraphelp.c Re: CVS Update: xc (branch: trunk)
In-Reply-To: <4127BBB1.3040702@laas.fr>
References: <20040821020644.E22559F7D5@freedesktop.org>
<4127BBB1.3040702@laas.fr>
Thanks for the good catch...
- Jim
On Sat, 2004-08-21 at 17:16, Matthieu Herrb wrote:
> Jim Gettys wrote:
> > CVSROOT: /cvs/xorg
> > Module name: xc
> > Changes by: jg@pdx. 04/08/20 19:06:44
> >
> > Log message:
> > Add Wraphelp.c to lib/Xdmcp, at long last, along with the U.S.
> > government required notifications. The website notification went up
> > first.
> >
> > Clean up Wraphelp.c so that it compiles cleanly.
> >
> > I chose the version Australian version written for R5 written
> > by Eric Eay@psych.psy.uq.oz.au, as I don't know where the original one
> > was, and didn't want to touch XFree86.
> >
>
> Hmm, this version doesn't work on LP64 big endian machines (like
> *BSD/sparc64). The problems were fixed in OpenBSD. May I suggest to
> switch to this version (it's the same origin, with the LP64 problems
> fixed):
> <http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/lib/Xdmcp/Wraphelp.c>
Date: Sat Aug 21 15:14:13 2004
Subject: [Xorg] Re: Where to commit Savage DDX changes?
References: <20040821223735.108953ac.felix@trabant>
<a728f9f90408211439365ac8fe@mail.gmail.com>
Message-ID: <a728f9f904082115146fa76a27@mail.gmail.com>
On Sat, 21 Aug 2004 23:52:24 +0200, albert vilella
> > the X tree on my savage
> > laptop has a HUGE number of changes on it including revamped streams
> > handling, mode validation, and dualhead/mergedfb support for mobile
> > savages. I'd like to get them committed somewhere at somepoint.
>
> cool! did I hear dualhead support for mobile savages? :-)
>
> which models support dualhead? MX/IX and SuperSavage?
yup. MX/IX and SuperSavage:
http://www.botchco.com/alex/new-savage/html/
>
> Albert.
> --
> ----------------------------
> ----------------------------
>
>
Date: Sat Aug 21 15:22:26 2004
Subject: [Xorg] Question about X Server Internal
Message-ID: <1093127013.3080.6.camel@c39.hadiko.de>
I have some basic Questions on X Server. may be this very simple for
experience programmer on X Server.
1- what I am trying since one week, is to find how a Window (including
GC operations) is drawn to screen. I search for the code which write to
the framebuffer of the video card. I know that cfb and mfb do that, but
still not find where they access the framebuffer. The video card driver
should export the framebuffer for its device to ddx layer. Could you
describe how cfb code access the framebuffer or simple which structure
store the framebuffer address?.
2- is there a different between XImage and Pixmap?
3- does the X server save always a copy of a window image, so that when
copying the window to others window, also the portion of the window
which not visible, is taken?
for me Question 1 is important.
-Amir
Date: Sat Aug 21 15:42:21 2004
References: <1093063916.8033.1.camel@localhost> <1093110175.3149.235.camel@local
host.localdomain>
Message-ID: <4127CF8B.8010000@winischhofer.net>
Vladimir Dergachev wrote:
>
>
> On Sat, 21 Aug 2004, Jim Gettys wrote:
>
>> I added this as a blocker to be discussed at Monday's call;
>> I suspect we shouldn't hold up the release for this, if someone
>> can come up with a fix we can use
>
>
>
>> (was the fix done by David,
>> or just committed by David from someone else?).
>
>
> Stupid question, but why is this important ?
iff -c -r3.45 -r3.46
*** xc/programs/Xserver/os/WaitFor.c2004/03/17 23:53:033.45
--- xc/programs/Xserver/os/WaitFor.c2004/04/07 02:36:263.46
--- 697,716 ----
if (DPMSStandbyTime > 0) {
DPMSStandbyTimer = TimerSet(DPMSStandbyTimer, 0, DPMSStandbyTime,
DPMSStandbyTimerExpire, NULL);
+ } else if (DPMSStandbyTimer) {
+ TimerCancel(DPMSStandbyTimer);
}
if (DPMSSuspendTime > 0) {
DPMSSuspendTimer = TimerSet(DPMSSuspendTimer, 0, DPMSSuspendTime,
DPMSSuspendTimerExpire, NULL);
+ } else if (DPMSSuspendTimer) {
+ TimerCancel(DPMSSuspendTimer);
}
if (DPMSOffTime > 0) {
DPMSOffTimer = TimerSet(DPMSOffTimer, 0, DPMSOffTime,
DPMSOffTimerExpire, NULL);
+ } else if (DPMSOffTimer) {
+ TimerCancel(DPMSOffTimer);
}
}
#endif
Exactly. This patch is a 6-liner and if anybody sues you for taking it
over to X.org, I'll defend you for free (IAAL). Such short stuff isn't
even copyrightable.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From volodya at mindspring.com Sat Aug 21 16:00:10 2004
Date: Sat Aug 21 16:00:17 2004
In-Reply-To: <1093127013.3080.6.camel@c39.hadiko.de>
References: <1093127013.3080.6.camel@c39.hadiko.de>
On Sun, 22 Aug 2004, Amir Bukhari wrote:
> I have some basic Questions on X Server. may be this very simple for
> experience programmer on X Server.
> 1- what I am trying since one week, is to find how a Window (including
> GC operations) is drawn to screen. I search for the code which write to
> the framebuffer of the video card. I know that cfb and mfb do that, but
> still not find where they access the framebuffer. The video card driver
> should export the framebuffer for its device to ddx layer. Could you
> describe how cfb code access the framebuffer or simple which structure
> store the framebuffer address?.
Most accelerated drivers do not access framebuffer directly, just cause
the card to perform the corresponding operation.
>
> 2- is there a different between XImage and Pixmap?
AFAIK, XImage is a structure that is used for exchanging image data with
Xserver (using, for example, shared memory).
Pixmap is an area you can draw to. In particular, pixmaps can be allocated
directly in video memory.
The difference comes from the fact that XImage structure is located in
your application virtual memory, but pixmap is located in Xserver virtual
memory.
The Pixmap value that your application has is just a handle used to tell
Xserver which pixmap you are using.
>
> 3- does the X server save always a copy of a window image, so that when
> copying the window to others window, also the portion of the window
> which not visible, is taken?
AFAIK not, in fact it usually does not double buffer at all.
best
Vladimir Dergachev
>
> for me Question 1 is important.
>
> -Amir
>
> _______________________________________________
> xorg mailing list
>
Date: Sat Aug 21 16:25:48 2004
On Sun, 2004-08-22 at 01:00, Vladimir Dergachev wrote:
> Most accelerated drivers do not access framebuffer directly, just cause
> the card to perform the corresponding operation.
>
that is right when XAA is used but I would like to understand cfb code
(actually how it access the framebuffer).
> >
> > 2- is there a different between XImage and Pixmap?
>
> AFAIK, XImage is a structure that is used for exchanging image data with
> Xserver (using, for example, shared memory).
>
> Pixmap is an area you can draw to. In particular, pixmaps can be allocated
> directly in video memory.
>
> The difference comes from the fact that XImage structure is located in
> your application virtual memory, but pixmap is located in Xserver virtual
> memory.
>
> The Pixmap value that your application has is just a handle used to tell
> Xserver which pixmap you are using.
>
I have read that pixmap has no colormap and alone it does not define a
complete image but I can copy pixmap to a window, thus it will be
displayed on screen, this made confusion!
-Amir
From ajax at nwnk.net Sat Aug 21 16:56:05 2004
Date: Sat Aug 21 16:56:16 2004
In-Reply-To: <1093130815.3235.20.camel@c39.hadiko.de>
<1093130815.3235.20.camel@c39.hadiko.de>
Hash: SHA1
On Saturday 21 August 2004 19:26, Amir Bukhari wrote:
> On Sun, 2004-08-22 at 01:00, Vladimir Dergachev wrote:
> > Most accelerated drivers do not access framebuffer directly, just cause
> > the card to perform the corresponding operation.
>
> that is right when XAA is used but I would like to understand cfb code
> (actually how it access the framebuffer).
Since you keep mentioning cfb:
Just don't. cfb is designed for a much earlier generation of video cards.
It's largely dead code, and I really want to mark it deprecated and cut it in
the next release. programs/Xserver/fb has the framebuffer core that almost
all of the drivers use these days (excluding sunffb and sunleo, both of which
could probably be easily converted to fb).
Anyway. The driver tells the fb layer where the framebuffer is by calling
fbScreenInit during startup. tdfx_driver.c is typical:
if (!fbScreenInit(pScreen, pTDFX->FbBase+pTDFX->fbOffset,
pScrn->virtualX, pScrn->virtualY,
pScrn->xDpi, pScrn->yDpi,
pScrn->displayWidth, pScrn->bitsPerPixel))
return FALSE;
Here the second argument is the visible portion of VRAM. The driver has
already mmap()ed the framebuffer by this point, so framebuffer access is just
memory access.
cfb does something similar, check the sunleo driver for an example.
- - ajax
iD8DBQFBJ+EYW4otUKDs0NMRAuo6AJ441NaiLwbqt1c2b3XrJPdTNq2pLACdEn3R
Ij+BH2GApBv6g3w/tbj2ims=
=c4ID
Date: Sat Aug 21 19:46:11 2004
Message-ID: <412808F4.6030106@sun.com>
>> (was the fix done by David,
>> or just committed by David from someone else?).
>
>
> Stupid question, but why is this important ?
David Dawes has stated that all changes he creates are covered by
the new XFree86 1.1 license.
Others may be willing to license their changes under the older
MIT/X license instead.
--
Date: Sat Aug 21 20:35:57 2004
Subject: [Xorg] testing results.
I completed the build tests on Wedneday CVS of Debian unstable, and
SuSE 9.1, on x86 (Pentium III and Pentium M). No problems.
I did not do install testing.
I did some runs of VSW4 on SuSE 9.1, with some errors
reported, this being typical.
I ran X11perf on SuSE 9.1; server crash with composite enabled,
which Eric has a patch for in Bugzilla, and ran to completion
with composite disabled. Again, on SuSE 9.1.
- Jim
Compared with typical results, the following diffs were found:
--- /tmp/testing/results/tmp.13012 2004-08-20 09:45:23.665493393
-0400
+++ /tmp/testing/results/xtest.8bpp.20040820.092914.summary
2004-08-20 09:45:23.660494229 -0400
@@ -6,9 +6,25 @@
Tests for XDrawArcs: Test 66: FAIL
-Tests for XLoadQueryFont: Test 1: FAIL
+Tests for XListFonts: Test 3: FAIL
Tests for XListFontsWithInfo: Test 3: FAIL
-Tests for XQueryFont: Test 1: FAIL
-Tests for XWriteBitmapFile: Test 3: FAIL
+Tests for XChangeKeyboardControl: Test 9: FAIL
+Tests for XChangeKeyboardControl: Test 10: FAIL
+Tests for XGrabButton: Test 5: FAIL
+Tests for XGrabKey: Test 8: FAIL
+Tests for XSetPointerMapping: Test 3: FAIL
+Tests for XUngrabButton: Test 4: FAIL
From ufz6 at rz.uni-karlsruhe.de Sun Aug 22 00:55:12 2004
Date: Sun Aug 22 00:54:06 2004
<1093130815.3235.20.camel@c39.hadiko.de>
<200408211956.10702.ajax@nwnk.net>
On Sun, 2004-08-22 at 01:56, Adam Jackson wrote:
> Hash: SHA1
>
> On Saturday 21 August 2004 19:26, Amir Bukhari wrote:
> > On Sun, 2004-08-22 at 01:00, Vladimir Dergachev wrote:
> > > Most accelerated drivers do not access framebuffer directly, just cause
> > > the card to perform the corresponding operation.
> >
> > that is right when XAA is used but I would like to understand cfb code
> > (actually how it access the framebuffer).
>
> Since you keep mentioning cfb:
>
> Just don't. cfb is designed for a much earlier generation of video cards.
> It's largely dead code, and I really want to mark it deprecated and cut it in
> the next release. programs/Xserver/fb has the framebuffer core that almost
> all of the drivers use these days (excluding sunffb and sunleo, both of which
> could probably be easily converted to fb).
>
but I think cfb is used by pixmap operations! or also fb is general for
all depth?
> Anyway. The driver tells the fb layer where the framebuffer is by calling
> fbScreenInit during startup. tdfx_driver.c is typical:
>
> if (!fbScreenInit(pScreen, pTDFX->FbBase+pTDFX->fbOffset,
> pScrn->virtualX, pScrn->virtualY,
> pScrn->xDpi, pScrn->yDpi,
> pScrn->displayWidth, pScrn->bitsPerPixel))
> return FALSE;
>
Yup, that what I search for. the above function call miScreenInit which
then set:
pScrInitParms->pbits = pbits;
pScrInitParms->width = width;
pScreen->devPrivate = (pointer)pScrInitParms;
Now it is clear.
Date: Sun Aug 22 01:16:57 2004
Subject: [Xorg] 6.7.99.902, xcompmgr, xv
Hello,
is there any known issue on ${SUBJECT} ?
I've found that turning on composite, running "xcompmgr -c" and "mplayer -vo
xv", segfaults xcompmgr.
Trying to run "xmame -x11 2" (2 = windowed xv *) I get a non-working xmame. It
doesn't start (I don't have the exact message right now, but I can provide it
if you need it)
Also, kuickview (kde's graphics viewer) shows nothing but a black window when
using xcompmgr and composite.
X Window System Version 6.7.99.902 (6.8.0 RC 2)
Linux 2.6.8.1-mm2
(II) Module nvidia: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.6111
Thanks,
Norberto
[*] I haven't tested 3 = fullscreen xv
Date: Sun Aug 22 05:10:16 2004
On Saturday 21 August 2004 22:20, Dennie Bastiaan wrote:
> On Saturday 21 August 2004 18:42, thomas klein wrote:
> > What's wrong with my conf ?
> >
> > Do I miss something ?
>
> In your "Device" section. Put this in it:
>
> Option "AGPFastWrite" "On"
> Option "RenderAccel" "On"
>
>
> But still, I have some troubles with transparency also. Are there
> more switches/options to be set?
>
> - Dennie
not faster...
with kdrive&xcompmgr, X is almost usable on my mach64, but xorg's not.
anyone can explain what's the difference between xorg compositing and
kdrive ?
thanks in advance,
t.
From volodya at mindspring.com Sun Aug 22 10:07:43 2004
Date: Sun Aug 22 10:07:48 2004
In-Reply-To: <412808F4.6030106@sun.com>
<412808F4.6030106@sun.com>
On Sat, 21 Aug 2004, Alan Coopersmith wrote:
> Vladimir Dergachev wrote:
>>> (was the fix done by David,
>>> or just committed by David from someone else?).
>>
>>
>> Stupid question, but why is this important ?
>
> David Dawes has stated that all changes he creates are covered by
> the new XFree86 1.1 license.
The thing is that copyright laws apply only to documents - not ideas. The
idea and howto of this fix are free to be coded and since the change is
very small it is trivially easy to replement.
Lastly, as Thomas has mentioned this small amount of lines of code is not
copyrightable at all.
best
Vladimir Dergachev
>
> Others may be willing to license their changes under the older
> MIT/X license instead.
>
> --
> -Alan Coopersmith- alan.coopersmith@sun.com
> Sun Microsystems, Inc. - X Window System Engineering
>
From skatan at despammed.com Sun Aug 22 12:48:41 2004
Date: Sun Aug 22 12:53:03 2004
Subject: [Xorg] Latest CVS: Failed to open framebuffer device
Message-ID: <4128F899.8080509@despammed.com>
Why I can't open the framebuffer?
Any ideas?
FC2
Radeon 9200 128Mb
linux 2.6.8-1.521
...
Build Operating System: Linux 2.6.8-1.521 i686 [ELF]
Current Operating System: Linux edgar.home.dom 2.6.8-1.521 #1 Mon Aug 16
09:01:18 EDT 2004 i686
...
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Reloading /opt/XORG-6_7_99_902/lib/modules/linux/libfbdevhw.a
(WW) open /dev/fb0: No such device
(EE) RADEON(0): Failed to open framebuffer device, consult warnings
and/or errors above for possible reasons
(you may have to look at the server log to see warnings)
(WW) RADEON(0): fbdevHWInit failed, not using framebuffer device
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Reloading /opt/XORG-6_7_99_902/lib/modules/linux/libfbdevhw.a
(EE) RADEON(0): Failed to open framebuffer device, consult warnings
and/or errors above for possible reasons
(you may have to look at the server log to see warnings)
(WW) RADEON(0): fbdevHWInit failed, not using framebuffer device
From michel at daenzer.net Sun Aug 22 13:22:01 2004
Date: Sun Aug 22 13:23:15 2004
Subject: [Xorg] Latest CVS: Failed to open framebuffer device
In-Reply-To: <4128F899.8080509@despammed.com>
References: <4128F899.8080509@despammed.com>
On Sun, 2004-08-22 at 21:48 +0200, Ditch Digger wrote:
> Why I can't open the framebuffer?
[...]
> (II) Loading sub module "fbdevhw"
> (II) LoadModule: "fbdevhw"
> (II) Reloading /opt/XORG-6_7_99_902/lib/modules/linux/libfbdevhw.a
> (WW) open /dev/fb0: No such device
Because no framebuffer device is active in the kernel; not even vesafb,
but you need radeonfb for this.
--
Date: Sun Aug 22 13:27:59 2004
Subject: [despammed] Re: [Xorg] Latest CVS: Failed to open framebuffer
device
References: <4128F899.8080509@despammed.com>
<1093206121.4765.31.camel@localhost>
Message-ID: <41290359.6030100@despammed.com>
Michel D?nzer ha scritto:
>On Sun, 2004-08-22 at 21:48 +0200, Ditch Digger wrote:
>
>
>>Why I can't open the framebuffer?
>>
>>
>
>[...]
>
>
>
>>(II) Loading sub module "fbdevhw"
>>(II) LoadModule: "fbdevhw"
>>(II) Reloading /opt/XORG-6_7_99_902/lib/modules/linux/libfbdevhw.a
>>(WW) open /dev/fb0: No such device
>>
>>
>
>Because no framebuffer device is active in the kernel; not even vesafb,
>but you need radeonfb for this.
>
>
>
>
yeah.. googled around and i found somewhere to put
append="video-radeonfb" into the grub.conf but nothing changed... here
the source:
http://lists.terrasoftsolutions.com/pipermail/yellowdog-general/2004-August/0152
42.html
any ideas?
Date: Sun Aug 22 13:32:43 2004
Subject: [despammed] Re: [Xorg] Latest CVS: Failed to open framebuffer
device
In-Reply-To: <41290359.6030100@despammed.com>
References: <4128F899.8080509@despammed.com> <1093206121.4765.31.camel@localh
ost>
<41290359.6030100@despammed.com>
Message-ID: <41290476.6080308@despammed.com>
Ditch Digger ha scritto:
> Michel D?nzer ha scritto:
>
>> On Sun, 2004-08-22 at 21:48 +0200, Ditch Digger wrote:
>>
>>
>>> Why I can't open the framebuffer?
>>>
>>
>>
>> [...]
>>
>>
>>
>>> (II) Loading sub module "fbdevhw"
>>> (II) LoadModule: "fbdevhw"
>>> (II) Reloading /opt/XORG-6_7_99_902/lib/modules/linux/libfbdevhw.a
>>> (WW) open /dev/fb0: No such device
>>>
>>
>>
>> Because no framebuffer device is active in the kernel; not even vesafb,
>> but you need radeonfb for this.
>>
>>
>>
>>
> yeah.. googled around and i found somewhere to put
> append="video-radeonfb" into the grub.conf but nothing changed... here
> the source:
> http://lists.terrasoftsolutions.com/pipermail/yellowdog-general/2004-August/01
5242.html
>
>
> any ideas?
> _______________________________________________
> xorg mailing list
>
> ----------------------------------------------
> Filtered by despammed.com. Tracer: 1093207001
> Consider a PayPal donation to help Despammed
> stay a step or two ahead of the bad guys.
> A new PayPal donation button is now on the
> home page. Thanks!
>
I meant append="video=radeonfb" in the grub.conf
Date: Sun Aug 22 16:39:14 2004
In-Reply-To: Your message of "Wed, 18 Aug 2004 21:23:11 +0200."
Message-ID: <E1ByLFm-00049s-L1@evo.keithp.com>
> xcompmgr runs, the eye-candy is on, but the screen freezes.
I'm not going to get a chance to fix kdrive until next month. I may have
a chance to get the changes done in X.org merged back before then, but
I'll be busy doing X.org and "other stuff" until then.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040820/908ab21e/attach
ment.pgp
Date: Sun Aug 22 16:39:39 2004
action...
In-Reply-To: Your message of "Wed, 18 Aug 2004 19:02:30 BST."
<20040818180230.GE21735@hermes.cam.ac.uk>
Message-ID: <E1ByLCe-00048j-4S@evo.keithp.com>
Around 19 o'clock on Aug 18, Rich Wareham wrote:
> Not terribly exciting but I've been hacking Gtk + metacity to support
> the new ARGB visual type. You can how have properly alpha-composited
> window borders.
I submitted patches to deal with this a couple of months ago; if they're
not already in Gtk+/Gdk/Metacity, then we should whine. I'm pretty sure I
bugzilla'ed them as well.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040820/90b3bbfa/attach
ment.pgp
Date: Mon Aug 23 08:17:56 2004
In-Reply-To: Jim.Gettys@hp.com wrote on Wednesday,
11 August 2004 at 10:37:20 -0400
Jim Gettys writes:
> And recent experience showed us that making a library static
> reduced our options greatly in compatibility.
>
> This caused great anguish with the changes to xinerama; we couldn't
> update apps to use a new protocol version.
>
I agree that static libs create more problems than they solve - however
the Xinerama case is a bad example: here the compatibility should have
been added to the protocol layer in the server. You don't want to update
shared libs on every client system when you bump the version of an extension
on a server - especially when the old version of Xinerama has been well
established over several years.
Egbert.
Date: Mon Aug 23 09:48:36 2004
In-Reply-To: Jim.Gettys@hp.com wrote on Saturday,
14 August 2004 at 20:14:37 -0400
Jim Gettys writes:
> Well, that looks easy.
>
> Unless someone knows why it would be a bad idea, maybe we
> should consider it.
I haven't really looked into this problem, but there are mice around
with more than 3 'real' buttons; I could imagine where this limits
the ways these mice can be configured.
Egbert.
From plattner at caltech.edu Mon Aug 23 10:12:02 2004
From: plattner at caltech.edu (Aaron Plattner)
Date: Mon Aug 23 10:17:44 2004
Subject: [Xorg] [Composite] mplayer -vo x11
Message-ID: <20040823171202.GC5989@homeworld.dnsalias.net>
I'm trying to run mplayer -vo x11 and it's causing xcompmgr to segfault. This
patch gets it to work, but obviously it's not a real solution:
Index: xcompmgr.c
===================================================================
RCS file: /cvs/xapps/xcompmgr/xcompmgr.c,v
diff -u -r1.26 xcompmgr.c
--- xcompmgr.c 14 Aug 2004 21:39:51 -0000 1.26
+++ xcompmgr.c 20 Aug 2004 19:30:31 -0000
@@ -825,6 +825,8 @@
draw = w->pixmap;
#endif
format = XRenderFindVisualFormat (dpy, w->a.visual);
+ if(!format)
+ format = XRenderFindVisualFormat (dpy, DefaultVisual(dpy,scr));
pa.subwindow_mode = IncludeInferiors;
w->picture = XRenderCreatePicture (dpy, draw,
format,
The visual w->a.visual points to is 0x22, which has no picture format associated
with it according to xdpyinfo -ext RENDER.
-- Aaron
P.S. Sorry if this message goes through multiple times -- I've been
having trouble with my mail server recently.
Date: Mon Aug 23 10:28:58 2004
<20040823171202.GC5989@homeworld.dnsalias.net>
Message-ID: <E1BzIbx-0004Cg-7n@evo.keithp.com>
> The visual w->a.visual points to is 0x22, which has no picture format associat
ed
> with it according to xdpyinfo -ext RENDER.
That's "invalid" according to the Render specification. Can you send
along the snippet of xdpyinfo output cooresponding to that visual? It
will look something like:
visual:
visual id: 0x21
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040823/ef1c3e9c/attach
ment.pgp
From plattner at caltech.edu Mon Aug 23 10:39:43 2004
From: plattner at caltech.edu (Aaron Plattner)
Date: Mon Aug 23 10:45:25 2004
In-Reply-To: <E1BzIbx-0004Cg-7n@evo.keithp.com>
References: <20040823171202.GC5989@homeworld.dnsalias.net>
<E1BzIbx-0004Cg-7n@evo.keithp.com>
Message-ID: <20040823173943.GD5989@homeworld.dnsalias.net>
Here you go:
[...]
visual:
visual id: 0x22
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 10 bits
[...]
Screen formats :
Screen 0 (sub-pixel order None)
filters: nearest, bilinear, fast(nearest), good(bilinear), best(bilinear)
visual format:
visual id: 0x21
pict format id: 0x62
visual format:
visual id: 0x22
pict format id: None
[...]
---------------
Breakpoint 2, paint_all (dpy=0x804f050, region=14681842) at xcompmgr.c:829
829 printf("Bad: %x\n", w->a.visual.visualid);
(gdb) p w->a.visual
$1 = (Visual *) 0x8053b38
(gdb) p *w->a.visual
$2 = {ext_data = 0x0, visualid = 34, class = 5, red_mask = 16711680, green_mask
= 65280,
blue_mask = 255, bits_per_rgb = 10, map_entries = 256}
-- Aaron
On Mon, Aug 23, 2004 at 01:28:01PM -0400, Keith Packard wrote:
> Around 10 o'clock on Aug 23, Aaron Plattner wrote:
>
> > The visual w->a.visual points to is 0x22, which has no picture format associ
ated
> > with it according to xdpyinfo -ext RENDER.
>
> That's "invalid" according to the Render specification. Can you send
> along the snippet of xdpyinfo output cooresponding to that visual? It
> will look something like:
>
> visual:
> visual id: 0x21
> class: TrueColor
> depth: 16 planes
> available colormap entries: 64 per subfield
> red, green, blue masks: 0xf800, 0x7e0, 0x1f
> significant bits in color specification: 8 bits
>
> -keith
Date: Mon Aug 23 11:15:08 2004
<20040823173943.GD5989@homeworld.dnsalias.net>
Message-ID: <E1BzJKc-0004GV-Jk@evo.keithp.com>
> [...]
> visual:
> visual id: 0x22
> class: DirectColor
> depth: 24 planes
> available colormap entries: 256 per subfield
> red, green, blue masks: 0xff0000, 0xff00, 0xff
> significant bits in color specification: 10 bits
Arg. Render doesn't like DirectColor visuals. If you are using this
visual as a TrueColor visual with a 'corrected' ramp, you can use the
obvious Direct picture format; that's available by using XRenderFindFormat
and supplying the right values for the 'type', 'depth' and 'direct'
members in the template.
I'm wondering if Render shouldn't just use that for DirectColor visuals
all of the time. Hmm.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040823/35e45c49/attach
ment-0001.pgp
Date: Mon Aug 23 11:45:12 2004
Subject: [Xorg] why is Option "ZAxisMapping" "4 5" needed
for my scrollmouse to work
.84.camel@localhost.localdomain> <411E938B.8030608@sun.com> <411EA8B
5.906@bitplanet.net> <1092528877.3394.111.camel@localhost.localdomain>
<16681.55760.198136.984820@xf14.fra.suse.de>
Message-ID: <412A3AA1.6010303@bitplanet.net>
Egbert Eich wrote:
> Jim Gettys writes:
> > Well, that looks easy.
> >
> > Unless someone knows why it would be a bad idea, maybe we
> > should consider it.
>
> I haven't really looked into this problem, but there are mice around
> with more than 3 'real' buttons; I could imagine where this limits
> the ways these mice can be configured.
Yeah, somebody elsewhere in the thread brought this up, but the thing is
that the patch doesn't hard-code anything it just sets a sensible
default. It can still be overridden.
Kristian
Date: Mon Aug 23 12:27:11 2004
Subject: [Xorg] [Fwd: [Bug 1167] New: Add SharedXevieReqs to bsdLib.tmpl]
Message-ID: <412A4505.3040508@laas.fr>
No really critical for the release, since applications using this
extension will get linked against the dependencies anyways, but it would
be nice to keep the way shared libs are built consistent.
--
Matthieu
-------------- next part --------------
An embedded message was scrubbed...
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 1167] New: Add SharedXevieReqs to bsdLib.tmpl
Date: Mon, 23 Aug 2004 12:22:12 -0700 (PDT)
Size: 1841
Url: http://freedesktop.org/pipermail/xorg/attachments/20040823/cfbb85a4/AddShar
edXevieReqstobsdLib.mht
Date: Mon Aug 23 14:12:20 2004
Subject: [Xorg] Tinderbox error on Wraphelp.c
On tinderbox.freedesktop.org there appears to be an issue in
Wraphelp.c:
Wraphelp.c:65: error: syntax error before "skb"
This issue showed up on the Solaris build machine over the weekend
starting on 8/21 at 18:45. It resolved at 10:12 today, 8/23, however
now the same error is appearing in one of the Linux/Debian build
machines as of 11:07.
ajax commented on IRC that it looks like uint_32 vs. u_int_32 issues,
and suggested mentioning it here on the list.
Solaris / x86 / SunOS
0040823084521.log
Linux / x86 / Debian
0040823110740.log
Bryce
From fxkuehl at gmx.de Mon Aug 23 14:36:02 2004
Date: Mon Aug 23 14:33:55 2004
Message-ID: <20040823233602.0e0435a2.felix@trabant>
I just managed to compile and install an XOrg Xserver with your patch. I
tested it on the Savage4. It works ok with 3D accel. But I noticed a
regression that I saw with the 2D driver from VIA/S3's code drop last
time. The image on my 1280x1024 DFP looks like it's stretching 1279x1024
to 1280x1024. Vertical lines in the middle of the screen are blurred due
to interpolation. This problem was originally fixed when you integrated
3D support into the XFree86 version of the Savage DDX driver. Now it's
back. :-/
Felix
On Mon, 2 Aug 2004 00:45:39 -0400
Alex Deucher <alexdeucher@gmail.com> wrote:
> I just finished the preliminary merge. It seems to work ok in limited
> testing. for those interested the patch is here:
>
>
> the code still needs the "develdri" #ifdefs added. I'm not sure
> exactly where those need to go off hand. also the savage dri is still
> only in mesa.
> At this point this can probably wait until after the next release for merging.
>
> Alex
>
>
> --__--__--
Date: Mon Aug 23 14:48:05 2004
In-Reply-To: <20040823233602.0e0435a2.felix@trabant>
References: <20040823233602.0e0435a2.felix@trabant>
Message-ID: <a728f9f90408231448407abef3@mail.gmail.com>
On Mon, 23 Aug 2004 23:36:02 +0200, Felix K?hling <fxkuehl@gmx.de> wrote:
> I just managed to compile and install an XOrg Xserver with your patch. I
> tested it on the Savage4. It works ok with 3D accel. But I noticed a
> regression that I saw with the 2D driver from VIA/S3's code drop last
> time. The image on my 1280x1024 DFP looks like it's stretching 1279x1024
> to 1280x1024. Vertical lines in the middle of the screen are blurred due
> to interpolation. This problem was originally fixed when you integrated
> 3D support into the XFree86 version of the Savage DDX driver. Now it's
> back. :-/
D'OH! I'll look into it. I haven't gotten around to testing with my
savage4 yet.
Alex
>
> Felix
>
> On Mon, 2 Aug 2004 00:45:39 -0400
> Alex Deucher <alexdeucher@gmail.com> wrote:
>
> > I just finished the preliminary merge. It seems to work ok in limited
> > testing. for those interested the patch is here:
> >
> >
> > the code still needs the "develdri" #ifdefs added. I'm not sure
> > exactly where those need to go off hand. also the savage dri is still
> > only in mesa.
> > At this point this can probably wait until after the next release for mergin
g.
> >
> > Alex
> >
> >
> > --__--__--
>
>
>
Date: Mon Aug 23 14:53:00 2004
Subject: [Xorg] marking a bug a "release blocker"
Message-ID: <412A673A.3050307@Sun.COM>
I just saw this comment added to a bug in bugzilla:
Someone with enough privilages should marked this bug as a release blocker, s
o
it will be fixed in upcoming 6.8.0.
Just to be clear (not trying to pick on anyone here) - all it takes to mark
a bug as a release blocker is to sign up for a bugzilla account - if you can
add a comment, you can also fill in 351 in the field "This bug blocks" and it
will be on the list as a release blocker - don't be shy, this really just means
you're asking us to look at it before the release and determine if it
can/should be fixed for this release. Try not to do so many bugs that it
overloads the people working on the release, but if you think the bug is
important, fill it in - the worst that happens is someone takes a few minutes
to read it, posts a comment about why it's not a blocker, and removes it from
the list.
--
From fxkuehl at gmx.de Mon Aug 23 15:06:42 2004
Date: Mon Aug 23 15:04:38 2004
Subject: [Xorg] Trimmed down X.Org build for DRI developers
Message-ID: <20040824000642.30b000cb.felix@trabant>
Hi,
I modified the host.def from DRI CVS for a trimmed down build of the
X.Org tree for DRI developers. The file is attached. Ajax (aka Adam
Jackson) suggested on IRC to commit this under a different name in
config/cf. Users/developers would copy it to host.def and make any
necessary modifications for their specific setup.
Feedback about the attached file is welcome, I've only tested it on a
single system so far.
Regards,
Felix
-------------- next part --------------
Name: drihost.def
Size: 2749 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040824/965cceec/drihos
t.obj
From Stuart.Kreitman at Sun.COM Mon Aug 23 15:33:39 2004
Date: Mon Aug 23 15:34:13 2004
Message-ID: <412A70C3.7070805@Sun.COM>
Bryce:
That would be me. You may refer to the email logs at
http://freedesktop.org/pipermail/release-wranglers/2004-August/date.html
to follow the discussion on this.
A quote of Alan Coopersmith's summary:
"uint32_t is the form specified by the ISO/ANSI C99 standard, the
current version of the Single Unix Specification (the combined
replacement for the POSIX & XPG series of specs, and LSB 1.3."
If the bug is only in the current Debian distro now and not in other
Linux's, then one must ask what standards vetting they have, and whether
we should ifdef around it.
skk
Harrington wrote:
> On tinderbox.freedesktop.org there appears to be an issue in
> Wraphelp.c:
>
> Wraphelp.c:65: error: syntax error before "skb"
>
> This issue showed up on the Solaris build machine over the weekend
> starting on 8/21 at 18:45. It resolved at 10:12 today, 8/23, however
> now the same error is appearing in one of the Linux/Debian build
> machines as of 11:07.
>
> ajax commented on IRC that it looks like uint_32 vs. u_int_32 issues,
> and suggested mentioning it here on the list.
>
> Solaris / x86 / SunOS
> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=62&logfile
=20040823084521.log
>
> Linux / x86 / Debian
> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=63&logfile
=20040823110740.log
>
> Bryce
>
> _______________________________________________
> xorg mailing list
--
Stuart Kreitman
Date: Mon Aug 23 15:37:32 2004
In-Reply-To: <412A70C3.7070805@Sun.COM>
Ah, thanks for the background.
Technically we do not yet know if it is Debian only or if it affects
other Linux systems since the Debian system is the only Linux system
that's completed tests within the last several hours. The only other
Linux system (SuSE9.1) will complete in about 4 hours.
Bryce
On Mon, 23 Aug 2004, Stuart Kreitman wrote:
> Bryce:
>
> That would be me. You may refer to the email logs at
> http://freedesktop.org/pipermail/release-wranglers/2004-August/date.html
>
> to follow the discussion on this.
>
> A quote of Alan Coopersmith's summary:
>
> "uint32_t is the form specified by the ISO/ANSI C99 standard, the
> current version of the Single Unix Specification (the combined
> replacement for the POSIX & XPG series of specs, and LSB 1.3."
>
> If the bug is only in the current Debian distro now and not in other
> Linux's, then one must ask what standards vetting they have, and whether
> we should ifdef around it.
>
> skk
>
>
> Harrington wrote:
> > On tinderbox.freedesktop.org there appears to be an issue in
> > Wraphelp.c:
> >
> > Wraphelp.c:65: error: syntax error before "skb"
> >
> > This issue showed up on the Solaris build machine over the weekend
> > starting on 8/21 at 18:45. It resolved at 10:12 today, 8/23, however
> > now the same error is appearing in one of the Linux/Debian build
> > machines as of 11:07.
> >
> > ajax commented on IRC that it looks like uint_32 vs. u_int_32 issues,
> > and suggested mentioning it here on the list.
> >
> > Solaris / x86 / SunOS
> > http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=62&logfi
le=20040823084521.log
> >
> > Linux / x86 / Debian
le=20040823110740.log
> >
> > Bryce
> >
> > _______________________________________________
>
>
>
Date: Mon Aug 23 15:56:35 2004
<Pine.LNX.4.33.0408231535110.17527-100000@osdlab.pdx.osdl.net>
Message-ID: <E1BzNir-00084R-MS@evo.keithp.com>
Debian provides uint32_t in /usr/include/stdint.h (the "standard" include
file for those definitions). Is that getting included?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040823/c5596ea8/attach
ment-0001.pgp
Date: Mon Aug 23 16:07:22 2004
In-Reply-To: <E1BzNir-00084R-MS@evo.keithp.com>
References: <E1BzNir-00084R-MS@evo.keithp.com>
Message-ID: <412A78A2.5060500@laas.fr>
> Debian provides uint32_t in /usr/include/stdint.h (the "standard" include
> file for those definitions). Is that getting included?
...but if you include stdint.h unconditionnaly, it will break the build
on OpenBSD which doesn't have this file :( And the current imake
definitions don't provide any good way to determine how to define those
fixed size type.
xc/include/Xmd.h has the (not pretty) code to define CARD32 and such. It
could be copied there for now.
Date: Mon Aug 23 16:07:55 2004
In-Reply-To: <E1BzNir-00084R-MS@evo.keithp.com>
On Mon, 23 Aug 2004, Keith Packard wrote:
>
> Debian provides uint32_t in /usr/include/stdint.h (the "standard" include
> file for those definitions). Is that getting included?
>
> -keith
>
cl012:~# ls -l /usr/include/stdint.h
-rw-r--r-- 1 root root 8545 May 25 11:17
> /usr/include/stdint.h
cl012:~# grep uint32_t /usr/include/stdint.h
#ifndef __uint32_t_defined
typedef unsigned int uint32_t;
# define __uint32_t_defined
From fcatrin at tuxpan.com Mon Aug 23 19:35:29 2004
From: fcatrin at tuxpan.com (Franco Catrin)
Date: Mon Aug 23 19:34:54 2004
Subject: [Xorg] another kdrive build error!
In-Reply-To: <200408190110.42454.hiryu@audioseek.net>
References: <200408190110.42454.hiryu@audioseek.net>
Message-ID: <1093314928.2616.3.camel@shaman.txp>
El jue, 19-08-2004 a las 04:10, Cameron escribi?:
> Get the following error building KDrive:
> fontcache.c:35:26: fontcacheint.h: No such file or directory
>
> locate turns up nothing even resembling that filename.
I have the same problem, it is on the current Xfont module, is there any
branch/tag where we could get a working version of Xfont ?
--
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin/es
Date: Mon Aug 23 20:36:01 2004
Subject: [Xorg] FreeBSD sparc64 6.0-CURRENT test failure
Test build of xorg CVS as of 20040823 on FreeBSD sparc64 6.0-CURRENT
failed in the apm driver with
http://pdx.freedesktop.org/~anholt/panther-tail.txt
--
Date: Mon Aug 23 20:41:59 2004
Subject: [Xorg] X.Org release status
There are still several technical issues and bugs to be worked out for
the upcoming release, which we feel are important to address but will
not be resolved before the original deadline (25 Aug 2004). Therefore,
the release wranglers have agreed to slip the release date and remain in
the code freeze, while working out these issues.
We also need much more testing to meet our success criteria. The
testing matrix, which can be found on the following Wiki page,
currently has lots of red (i.e., untested platforms). It would help us
greatly if we could get reports back on the build testing results. The
status page (above) has instructions on how to perform the build tests.
Note that we encourage you to post successes/failures for any part of
the tests, and it is not necessary to go through the entire testing
procedure before reporting results.
Thank you for your help!
Date: Mon Aug 23 22:53:44 2004
Subject: [Xorg] suggestions on running xtest?
I was trying to use xreg, but it's taking forever. What I really want
to do, though, is run xtest's tests of graphical operations on my
running X server with automatic compositing on, and skip the rest of the
xreg process. Anyone want to suggest to me how I want to be running
xtest? I'm poking at the docs, but I'm not finding what I want easily.
--
Date: Mon Aug 23 23:31:05 2004
Subject: [Xorg] X.Org release status
Hash: SHA1
On Monday 23 August 2004 23:41, Kevin E Martin wrote:
> There are still several technical issues and bugs to be worked out for
> the upcoming release, which we feel are important to address but will
> not be resolved before the original deadline (25 Aug 2004). Therefore,
> the release wranglers have agreed to slip the release date and remain in
> the code freeze, while working out these issues.
I'm getting "BadMatch on X_GetImage" during some tests (rendercheck, x11perf,
etc), even with XLIB_SKIP_ARGB_VISUALS=1 and Composite disabled. This seems
to be correlated with switching desktops in KDE. I don't have a formal bug
open for this yet, but it is preventing me from running full tests for all
the hardware I have. Does anyone know what this might be coming from?
Besides this everything looks solid on my end, I'll post test results soon.
- - ajax
iD8DBQFBKuCcW4otUKDs0NMRAttQAKCG5NolvA6Wx8kSQBC3RARYyu4FzwCg3TJy
6oj6+pKmfQokeqeXF1fO/WY=
=L0fH
Date: Tue Aug 24 06:16:06 2004
References: <1093326812.887.55.camel@leguin>
On Mon, Aug 23, 2004 at 10:53:33PM -0700, Eric Anholt wrote:
> I was trying to use xreg, but it's taking forever. What I really want
> to do, though, is run xtest's tests of graphical operations on my
> running X server with automatic compositing on, and skip the rest of the
> xreg process. Anyone want to suggest to me how I want to be running
> xtest? I'm poking at the docs, but I'm not finding what I want easily.
This is actually what xreg is really good at handling.
For example, to run the X test suite test for XCopyArea on your running
X server running at depth 16 from the project root /tmp/XorgTEST, simply
run:
xreg -projroot /tmp/XorgTEST -d 16 -nostart -xorg -xtest -test XCopyArea
or if you want to just run the drawing tests, which are in chapter 6 of
the test suite, then run:
xreg -projroot /tmp/XorgTEST -d 16 -nostart -xorg -xtest -chapter CH06
From jens at tungstengraphics.com Tue Aug 24 06:22:00 2004
From: jens at tungstengraphics.com (Jens Owen)
Date: Tue Aug 24 06:21:14 2004
References: <1093326812.887.55.camel@leguin>
Message-ID: <412B40F8.9000303@tungstengraphics.com>
Eric Anholt wrote:
> I was trying to use xreg, but it's taking forever. What I really want
> to do, though, is run xtest's tests of graphical operations on my
> running X server with automatic compositing on, and skip the rest of the
> xreg process. Anyone want to suggest to me how I want to be running
> xtest? I'm poking at the docs, but I'm not finding what I want easily.
>
From memory, it's been a while, I think you'll find information on
running tests indivdually in the Users Guide:
xtest/xsuite/xtest/doc/userguide.mm
--
/\
Jens Owen / \/\ _
jens@tungstengraphics.com / \ \ \ Steamboat Springs, Colorado
From Deron.Johnson at Sun.COM Tue Aug 24 08:35:27 2004
Date: Tue Aug 24 08:36:47 2004
Subject: [Xorg] X11R6.8: Problem with continuous stream of requests with op
= 144
Message-ID: <412B603F.9060804@Sun.COM>
I am experiencing a problem with the latest version of X11R6.8.
I am using the head of the cvs repository as of about 10:30
this morning. But the problem has been there for a couple of
weeks.
(I've worked around the Xdmcp Wraphelp.c failures, so I know
that isn't what is causing the problem).
The problem is that whenever I run the Project Looking Glass
Display Server, which is a 3D app which uses OpenGL, the
X server receives a continual flood of requests with op = 144.
My machine has an Nvidia Quadro FX 2000 (with the 5335 driver,
I think).
When I step into the function which dispatch.c calls for this
op, the function is _nv000021gl, which doesn't tell me a whole
lot. But I'm guessing that what I am seeing is a continuous
stream of buffer swap requests.
I doubt that this is an issue with the Nvidia driver, because
I don't experience this problem when I run Xfree86 X11R6.7.
Is there some sort of extra configuration step that I need to
make for X11R6.8, or possibly some newer DRI module that I need
to configure?
Thanks for your help,
Deron Johnson
Sun Microsystems
From krahn at niehs.nih.gov Tue Aug 24 09:16:59 2004
Date: Tue Aug 24 09:17:03 2004
<41111551.1040707@niehs.nih.gov>
Message-ID: <412B69FB.7060404@niehs.nih.gov>
With Jim Gettys finally getting time to look into XInput, it
was my turn to be unavailable for a while...
Jim Gettys wrote:
>>One thing that should be possible is for two servers on one VT
>>to be able to use the same device, but with different settings.
>>That means X needs to keep device state info and re-instate it
>>when X gets it's VT switched active and it regains devices.
>
>
> I presume you mean two servers on 2 different Linux virtual
> terminals.
>
> Ugh. Do we *really* need this complexity?
It is already sort-of part of DIX and XFree86, but currently
is only oriented to sharing between one server and several text
consoles. If the DIX DeviceControl function is used the way DIX
intended, it is not so hard. DEVICE_ON and DEVICE_OFF are sent
when switching the server's VT in/out.
>
> Do USB devices provide ways to save/restore such settings?
> Or will the system have to shadow the state and try to
> keep it consistent?
>
> Or is an input device assigned to a particular X server
> statically? This maps well to the situation of
> multi-head systems (e.g. 441, like we've (HP) started selling
> in South Africa).
>
> You are helping stoke my head-ache ;-).
In some ways, this is like keyboard mapping and pointer acceleration.
Most of the state information can probably be saved in the driver
and used to convert raw data to XEvent data. For example, touch
screen input could always send raw device data, and let the driver
convert to screen coordinates. This might be useful for allowing
an application to get sub-pixel data directly from the device, and
have the same device send core events at pixel resolution.
There are a few things where this won't work, for example force
feedback joysticks. Something like that can be thought of as
holding data and complex state info, just like OpenGL textures.
So, management of that type of device data should be done similar
to the way OpenGL data is or will be done.
>> > If you detect the idea to keep as little as possible in the
>> > X server, you're right.
>> >
>> > This is analogous to the work we want to do to get display
>> > mode setting *out* of the X server.
>> >
An important issue to get a plan going is to understand the goals
of moving video display stuff out of X and into the OS kernel.
Is the plan to let the kernel pick resolution, depth, etc., and
tell X, or is the plan just to put driver functions into the kernel
and let X manage the screen resolution via a HAL interface with
the kernel?
A few more points:
Look at the idea of the core devices being virtual-only devices
that are always present, and always at screen resolution. This
gets rid of the problem of core hardware devices being special.
As for managing the X device list, one approach is to let the
OS kernel/hotplug system tell X what devices are available, but
also have X client functions for managing these. For example,
X client functions could set options pertaining to interpreting
raw events into X events, such as the keyboard mapping. Besides,
we need client functions to install virtual or remote devices.
Someone may want to always have a given device listed, even
though it may not always be plugged in. A client can open the
device, but it just gets no events until the actual device
shows up. (IRIX works this way.)
... Joe Krahn
From bryce at osdl.org Tue Aug 24 09:22:36 2004
Date: Tue Aug 24 09:22:45 2004
In-Reply-To: <412A70C3.7070805@Sun.COM>
Ah the problem in Wraphelp.c is also causing breakage for the SuSE9.1
box, so it looks like the bug may affect Linux in general.
824015833.log
Bryce
On Mon, 23 Aug 2004, Stuart Kreitman wrote:
> Bryce:
>
> That would be me. You may refer to the email logs at
> http://freedesktop.org/pipermail/release-wranglers/2004-August/date.html
>
> to follow the discussion on this.
>
> A quote of Alan Coopersmith's summary:
>
> "uint32_t is the form specified by the ISO/ANSI C99 standard, the
> current version of the Single Unix Specification (the combined
> replacement for the POSIX & XPG series of specs, and LSB 1.3."
>
> If the bug is only in the current Debian distro now and not in other
> Linux's, then one must ask what standards vetting they have, and whether
> we should ifdef around it.
>
> skk
>
>
> Harrington wrote:
> > On tinderbox.freedesktop.org there appears to be an issue in
> > Wraphelp.c:
> >
> > Wraphelp.c:65: error: syntax error before "skb"
> >
> > This issue showed up on the Solaris build machine over the weekend
> > starting on 8/21 at 18:45. It resolved at 10:12 today, 8/23, however
> > now the same error is appearing in one of the Linux/Debian build
> > machines as of 11:07.
> >
> > ajax commented on IRC that it looks like uint_32 vs. u_int_32 issues,
> > and suggested mentioning it here on the list.
> >
> > Solaris / x86 / SunOS
le=20040823084521.log
> >
> > Linux / x86 / Debian
le=20040823110740.log
> >
> > Bryce
> >
> > _______________________________________________
>
>
>
Date: Tue Aug 24 09:36:48 2004
On Tue, 24 Aug 2004, Bryce Harrington wrote:
> Ah the problem in Wraphelp.c is also causing breakage for the SuSE9.1
> box, so it looks like the bug may affect Linux in general.
>
40824015833.log
IIRC, the -ansi is turning off useful settings such as -D_POSIX_SOURCE.
Why isn't LinuxSourceDefines getting picked up here?
Stuart
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From Deron.Johnson at Sun.COM Tue Aug 24 09:40:13 2004
Date: Tue Aug 24 09:48:31 2004
Message-ID: <412B6F6D.8090607@Sun.COM>
It also fails on my SUSE 8.1 system.
> Ah the problem in Wraphelp.c is also causing breakage for the SuSE9.1
> box, so it looks like the bug may affect Linux in general.
>
40824015833.log
>
> Bryce
>
> On Mon, 23 Aug 2004, Stuart Kreitman wrote:
>
>>Bryce:
>>
>>That would be me. You may refer to the email logs at
>>http://freedesktop.org/pipermail/release-wranglers/2004-August/date.html
>>
>>to follow the discussion on this.
>>
>>A quote of Alan Coopersmith's summary:
>>
>>"uint32_t is the form specified by the ISO/ANSI C99 standard, the
>>current version of the Single Unix Specification (the combined
>>replacement for the POSIX & XPG series of specs, and LSB 1.3."
>>
>>If the bug is only in the current Debian distro now and not in other
>>Linux's, then one must ask what standards vetting they have, and whether
>>we should ifdef around it.
>>
>>skk
>>
>>
>> Harrington wrote:
>>
>>>On tinderbox.freedesktop.org there appears to be an issue in
>>>Wraphelp.c:
>>>
>>> Wraphelp.c:65: error: syntax error before "skb"
>>>
>>>This issue showed up on the Solaris build machine over the weekend
>>>starting on 8/21 at 18:45. It resolved at 10:12 today, 8/23, however
>>>now the same error is appearing in one of the Linux/Debian build
>>>machines as of 11:07.
>>>
>>>ajax commented on IRC that it looks like uint_32 vs. u_int_32 issues,
>>>and suggested mentioning it here on the list.
>>>
>>>Solaris / x86 / SunOS
>>> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=62&logfil
e=20040823084521.log
>>>
>>>Linux / x86 / Debian
>>> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=63&logfil
e=20040823110740.log
>>>
>>>Bryce
>>>
>>>_______________________________________________
>>>xorg mailing list
>>>xorg@freedesktop.org
>>>http://freedesktop.org/mailman/listinfo/xorg
>>
>>
>>
>
> _______________________________________________
> xorg mailing list
From Stuart.Kreitman at Sun.COM Tue Aug 24 10:05:05 2004
Date: Tue Aug 24 10:05:11 2004
Message-ID: <412B7541.7050402@sun.com>
If the ISO standards conformance of these platforms is inconsistent,
then maybe we should just accomodate:
#ifndef uint32_t
#define uint32_t u_int32_t
#endif
etc.
Does that work for people?
>On Tue, 24 Aug 2004, Bryce Harrington wrote:
>
>
>
>>Ah the problem in Wraphelp.c is also causing breakage for the SuSE9.1
>>box, so it looks like the bug may affect Linux in general.
>>
>>http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=76&logfile=200
40824015833.log
>>
>>
>
>IIRC, the -ansi is turning off useful settings such as -D_POSIX_SOURCE.
>
>Why isn't LinuxSourceDefines getting picked up here?
>
>
> Stuart
>
>Stuart R. Anderson anderson@netsweng.com
>Network & Software Engineering http://www.netsweng.com/
>1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
> BD03 0A62 E534 37A7 9149
>
>
Date: Tue Aug 24 10:06:45 2004
In-Reply-To: <412B7541.7050402@sun.com>
<412B7541.7050402@sun.com>
Message-ID: <412B75A2.10402@Sun.COM>
Stuart Kreitman wrote:
> If the ISO standards conformance of these platforms is inconsistent,
> then maybe we should just accomodate:
>
> #ifndef uint32_t
> #define uint32_t u_int32_t
> #endif
>
> etc.
>
> Does that work for people?
You can't check for typedefs with ifdef, so that won't work.
Again, CARD32 already solves this for the rest of the X tree,
why not just use it?
--
Date: Tue Aug 24 10:08:54 2004
In-Reply-To: <412B75A2.10402@Sun.COM>
<412B7541.7050402@sun.com> <412B75A2.10402@Sun.COM>
Message-ID: <412B761C.8010907@sun.com>
ok, I don't see why not...
skk
> Stuart Kreitman wrote:
>
>> If the ISO standards conformance of these platforms is inconsistent,
>> then maybe we should just accomodate:
>>
>> #ifndef uint32_t
>> #define uint32_t u_int32_t
>> #endif
>>
>> etc.
>>
>> Does that work for people?
>
>
> You can't check for typedefs with ifdef, so that won't work.
> Again, CARD32 already solves this for the rest of the X tree,
> why not just use it?
>
Date: Tue Aug 24 10:09:53 2004
In-Reply-To: <412B7541.7050402@sun.com>
<412B7541.7050402@sun.com>
On Tue, 24 Aug 2004, Stuart Kreitman wrote:
> If the ISO standards conformance of these platforms is inconsistent,
> then maybe we should just accomodate:
My comment wasn't so much a question of platform inconsistancy, but
rather why aren't we telling the compiler what the conformance level is
for that platform.
Strict ANSI is a very small subset of what we are used to using.
Stuart
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
Date: Tue Aug 24 10:19:33 2004
<412B7541.7050402@sun.com>
Message-ID: <412B78A6.3000804@sun.com>
>On Tue, 24 Aug 2004, Stuart Kreitman wrote:
>
>
>
>>If the ISO standards conformance of these platforms is inconsistent,
>>then maybe we should just accomodate:
>>
>>
>
>
>My comment wasn't so much a question of platform inconsistancy, but
>rather why aren't we telling the compiler what the conformance level is
>for that platform.
>
Please write the bugzilla/code diffs. I imagine this will wait till
after the release. We should just get through a point
problem for now.
skk
>
>Strict ANSI is a very small subset of what we are used to using.
>
> Stuart
>
>Stuart R. Anderson anderson@netsweng.com
>Network & Software Engineering http://www.netsweng.com/
>1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
> BD03 0A62 E534 37A7 9149
>
>
Date: Tue Aug 24 10:58:02 2004
In-Reply-To: anderson@netsweng.com wrote on Tuesday,
24 August 2004 at 13:09:31 -0400
<412B7541.7050402@sun.com>
I can make it work on a system I've tried on with the patch below.
The typedef in question is contained there.
Wether this file should be included by sys/types.h I do not know.
Egbert.
Index: Wraphelp.c
===================================================================
RCS file: /cvs/xorg/xc/lib/Xdmcp/Wraphelp.c,v
diff -u -r1.3 Wraphelp.c
--- Wraphelp.c 23 Aug 2004 17:06:37 -0000 1.3
+++ Wraphelp.c 24 Aug 2004 17:54:42 -0000
@@ -4,6 +4,7 @@
*/

#include <sys/types.h>
+#include <stdint.h>
#include "Wrap.h"

/* des routines for non-usa - eay 10/9/1991 eay@psych.psy.uq.oz.au
Date: Tue Aug 24 11:00:33 2004
<412B7541.7050402@sun.com>
<16683.33183.163436.475680@xf14.fra.suse.de>
On Tue, 24 Aug 2004, Egbert Eich wrote:
>
> I can make it work on a system I've tried on with the patch below.
> The typedef in question is contained there.
> Wether this file should be included by sys/types.h I do not know.
Accoring to POSIX, stdint.h is the right place to be getting this.
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
I think, however, that we have had a couple of reports of OSes (possibly
older versions) that don't have this file, or it at least is not visible
to the mode the compiler is using.
Stuart
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
Date: Tue Aug 24 11:05:26 2004
<16683.33183.163436.475680@xf14.fra.suse.de>
Message-ID: <E1Bzfeb-0002Na-3Z@evo.keithp.com>
Around 19 o'clock on Aug 24, Egbert Eich wrote:
> I can make it work on a system I've tried on with the patch below.
> The typedef in question is contained there.
> Whether this file should be included by sys/types.h I do not know.
We apparantly can't depend on the existance of stdint.h on all platforms
(yet).
I replaced 'uint32_t' with 'CARD32' and 'uint8_t' with 'CARD8' and then
#include <X11/Xmd.h> at the top of the file to make it build. That should
be portable to all systems that we currently run on.
Anyone care to see the patch? Should I just stuff it into CVS?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040824/2eb96259/attach
ment-0001.pgp
Date: Tue Aug 24 11:11:06 2004
In-Reply-To: <E1Bzfeb-0002Na-3Z@evo.keithp.com>
References: <E1Bzfeb-0002Na-3Z@evo.keithp.com>
Message-ID: <412B8499.3000106@Sun.COM>
Stuff!
> Around 19 o'clock on Aug 24, Egbert Eich wrote:
>
>
>>I can make it work on a system I've tried on with the patch below.
>>The typedef in question is contained there.
>>Whether this file should be included by sys/types.h I do not know.
>
>
> We apparantly can't depend on the existance of stdint.h on all platforms
> (yet).
>
> I replaced 'uint32_t' with 'CARD32' and 'uint8_t' with 'CARD8' and then
> #include <X11/Xmd.h> at the top of the file to make it build. That should
> be portable to all systems that we currently run on.
>
> Anyone care to see the patch? Should I just stuff it into CVS?
>
> -keith
>
>
--
Stuart Kreitman
Date: Tue Aug 24 11:34:25 2004
In-Reply-To: Your message of "Tue, 24 Aug 2004 11:10:33 PDT."
<412B8499.3000106@Sun.COM>
Message-ID: <E1Bzg6l-0002Rc-TN@evo.keithp.com>
Around 11 o'clock on Aug 24, Stuart Kreitman wrote:
> Stuff!
Stuffed!
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040824/9baa0239/attach
ment.pgp
From jobi at via.ecp.fr Tue Aug 24 12:07:41 2004
From: jobi at via.ecp.fr (Johan Bilien)
Date: Tue Aug 24 12:47:01 2004
Subject: [Xorg] X11R6.8 cvs and ATI fglrx drivers
Message-ID: <20040824190741.GA32094@via.ecp.fr>
Hi all,
today I gave the current CVS a try. I'm running an ATI Radeon 9600. The
radeon driver works, but everything feels really slow. With the
proprietary drivers fglrx, I experience a crash of the X server (signal
11) when I run gnome-settings-daemon (I think when it loads the GTK
theme engine), or when launching openoffice.
With both, xcompmgr gives strange shadows [1]. Once xcompmgr is
launched, everything is dead slow, but I think this has been discussed
here before.
I put my xorg.conf [2] and the crash log [3] online.
[1] http://bilien.org/~jobi/xorg-comp-buggy-shadow.png
[2] http://bilien.org/~jobi/xorg.conf
[3] http://bilien.org/~jobi/Xorg.0.log
--
Johan
Date: Tue Aug 24 13:09:05 2004
Subject: [Xorg] CVS dosen't compile on cygwin
Message-ID: <0ed601c48a15$b5e4bef0$1e01a8c0@cnt496>
Empty hosts.def file.
make[5]: Leaving directory `/home/Administrator/xorg/xc/programs/Xserver/miext/d
amage'
gcc -o Xnest.exe -O2 -fno-strength-reduce -Wall -Wpointer-arith -e _mainCRTStar
tup -L../../exports/lib hw/xnest/miinitext.o dix/libdix.a os/libos.a
hw/xnest/libxnest.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a Xi/
libxinput.a lbx/liblbx.a ../../lib/lbxutil/l
iblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a GL/glx/libglx.a
GL/mesa/GLcore/libGLcore.a randr/librandr.a render
/librender.a composite/libcomposite.a xfixes/libxfixes.a damageext/
libdamage.a miext/damage/libdamage.a miext/cw/libcw.a hw/xnest/libxnest.a -L/us
r/X11R6/lib ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -L../../exp
orts/lib -lXext -lX11 -lz.dll -lXau -lXdmcp -Wl,--enable-
auto-import,--enable-runtime-pseudo-reloc
../../exports/lib/libXdmcp.a(Wrap.o)(.text+0x0):Wrap.c: multiple definition of `
_XdmcpWrap'
../../exports/lib/libX11.a(d000548.o)(.text+0x0): first defined here
make[4]: *** [Xnest.exe] Error 1
Carl K
From dicej at mailsnare.net Tue Aug 24 12:58:21 2004
From: dicej at mailsnare.net (Joel Dice)
Date: Tue Aug 24 13:28:56 2004
Subject: [Xorg] X11R6.8 cvs and ATI fglrx drivers
In-Reply-To: <20040824190741.GA32094@via.ecp.fr>
References: <20040824190741.GA32094@via.ecp.fr>
Message-ID: <Pine.LNX.4.61.0408241357130.906@joeldicepc>
On Tue, 24 Aug 2004, Johan Bilien wrote:
> With both, xcompmgr gives strange shadows [1]. Once xcompmgr is
> launched, everything is dead slow, but I think this has been discussed
> here before.
For soft shadows, use 'xcompmgr -c' with no '-s' flag.
- Joel
From rene at rocklinux-consulting.de Tue Aug 24 15:02:14 2004
Date: Tue Aug 24 15:03:12 2004
Subject: [Xorg] Bug #1053 - Screen corruption enlightenment16 and xcompmgr
Message-ID: <412BBAE6.9000202@rocklinux-consulting.de>
Hi all,
this was already reported several times in screenshot mails and as
bugzilla bug #1053, but I want to bring this to attention in a seperate
thread.
Running the Composition Manager with Enlightenment 16 leads to screen
corruption of some of the stuff drawn by enlightenment itself.
Without the composition manager all is fine:
http://rocklinux-consulting.de/x.org/wo-xcompmgr.png
And now with xcompmgr -a (using -c or -s does not make a difference in
the way the enlightenment theme parts are corrupted ...):
http://rocklinux-consulting.de/x.org/w-xcompmgr.png
It seems that these tiny theme parts might be shifted a bit due to some
index used/computed incorrectly ...
The X.Org version is nearly CVS:HEAD and it happens on x86/Radeon and
Matrox as well as PowerPC/Radeon with and without RenderAccel. All the
X.Org included driver - I do not use the binary only ones ...
(Btw, the RenderAccel for Radeon has endianness bugs - but I ignore
those for now and report them to bugzilla when I find no time to track
them myself - but /me get's used to track endianess problem, so ... ;-)
Any idea?
- Ren? Rebe
From rayl at mail.com Tue Aug 24 15:54:45 2004
From: rayl at mail.com (Ray Lehtiniemi)
Date: Tue Aug 24 18:22:55 2004
Subject: [Xorg] build test results
Message-ID: <20040824225445.GD4314@mail.com>
hi all
xorg newbie here, just did my first cvs build test:
Build with empty host.def file
1. Ray Lehtiniemi
2. Tue Aug 24 14:21:36 MDT 2004 to Tue Aug 24 16:35:22 MDT 2004
3. Linux, IA-32, Suse 9.1 ftp installation w/ all online updates
4. XORG-6_7_99_902
5. Full build of Release 6.7 complete.
6. untested
7. untested
8. untested
i'll try to send more results later...
ps: is there a nice way to restart the build if it stops midway?
i had to install ncurses-devel for xterm, but when i did make
World again, it cleaned everything and started over!!
--
----------------------------------------------------------------------
Ray L <rayl@mail.com>
Date: Tue Aug 24 22:06:44 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 7
Added yesterday: 13
-----------------------------
* Bug #474: XV fails to alloc memory
- Needs investigation and patch
- The consensus appears to be to leave the test/hard fail in
- Should option to enable/disable hard fail be added?
* Bug #1053: Composite artifacts using Openbox, Enlightenemnt, XFCE, FVWM
* Bug #1083: lndir doesn't handle symlinks to dirs right
- Patch supplied, needs review
* Bug #1101: Background pixmaps are painted with wrong origin in child
widgets of redirected windows
- Test program provided
- Initial patch supplied.
- Others using UseInstalled should test the patch to see if it works
for them
- Eric Anholt provided initial patch
- Adam Jackson says patch fixes problem but creates others with composite
* Bug #1155: libGL build failure
- IEEE_ONE undefined on HPPA/MIPS Linux
- Fixed in current Mesa, which should be merged before release
- Merge with Mesa 6.1 already approved
* Bug #1156: Radeon driver build failures on PPC
- Patch supplied
- Just waiting for reply to question asked
* Bug #1157: Radeon line accel broken with DRI enabled
* Bug #1160: xf86drm.h needs xc/extras/drm/shared/drm.h for functional SDK
* Bug #1168: Damage crashes with rootless layer
- New fix provided, needs review
Date: Wed Aug 25 02:45:53 2004
In-Reply-To: <20040824225445.GD4314@mail.com>
References: <20040824225445.GD4314@mail.com>
On Tue, 24 Aug 2004, Ray Lehtiniemi wrote:
>
> hi all
>
> xorg newbie here, just did my first cvs build test:
>
> Build with empty host.def file
>
> 1. Ray Lehtiniemi
> 2. Tue Aug 24 14:21:36 MDT 2004 to Tue Aug 24 16:35:22 MDT 2004
> 3. Linux, IA-32, Suse 9.1 ftp installation w/ all online updates
> 4. XORG-6_7_99_902
> 5. Full build of Release 6.7 complete.
> 6. untested
> 7. untested
> 8. untested
>
>
> i'll try to send more results later...
>
> ps: is there a nice way to restart the build if it stops midway?
> i had to install ncurses-devel for xterm, but when i did make
> World again, it cleaned everything and started over!!
if the build breaks while compiling you can simply do "make". This
will continue where it stopped before. But if you changed something
in config/cf or some Imakefiles you should do make World again
to update all Makefiles and remove all objects and libs with the old
configuration.
bye
ago
--
From fxkuehl at gmx.de Wed Aug 25 08:34:01 2004
Date: Wed Aug 25 08:31:59 2004
Subject: [Xorg] Build failure: ft2build.h not found
Message-ID: <20040825173401.406ed4f3.felix@trabant>
Hi,
On my notebook the build failed in fcatomic.c because ft2build.h was not
found. It is present in the xorg tree in three different versions in
three different places, but none seems to be in the include search path
for fcatomic.c. On my other box the build worked because I have the
fontconfig development package installed which provides ft2build.h in
/usr/include.
I ran this build with the host.def file (with different Mesa and DRM
paths and optimization options) I posted to this list on Monday.
make[4]: Entering directory `/home/src/xorg/trunk/xc/lib/fontconfig'
rm -f fcatomic.o
gcc -m32 -c -gstabs+ -pipe -O3 -march=athlon-4 -ansi -pedantic -Wall -Wpointer-
arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing
-declarations -Wredundant-decls -Wnested-externs -Wundef -I
../../exports/include -I/usr/include/freetype2 -I/usr/include/freetype2/config -
I../../extras/fontconfig/src -I../../extras/fontconfig -I../../exports/includ
e/X11 -I../.. -I../../exports/include -I/usr/X11R6-XORG/include -Dlinux -D__i3
86__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN
_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DFUNCPROTO=15 -DNARRO
WPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DFC_DEFAULT_FONTS='""' -DH
AVE_EXPAT -DXFREE86_FT2 -DFONTCONFIG_PATH='"/usr/X11R6-XORG/etc/fonts"'
-fPIC fcatomic.c
In Datei, eingef?gt von ../../extras/fontconfig/src/fcint.h:38,
von fcatomic.c:49:
../../exports/include/fontconfig/fcfreetype.h:26:22: ft2build.h: Datei oder Verz
eichnis nicht gefunden
felix@trabant:~/xorg$ ls -l `find . -name ft2build.h`
-rw-r--r-- 1 felix src 2002 2004-04-23 20:42 ./extras/freetype2/devel/ft2build.
h
-rw-r--r-- 1 felix src 2185 2003-11-14 17:48 ./extras/freetype2/include/ft2buil
d.h
-rw-r--r-- 1 felix src 2505 2004-04-23 20:44 ./lib/font/FreeType/module/ft2buil
d.h
Regards,
Felix
From fyzik at amu.cz Wed Aug 25 08:38:24 2004
From: fyzik at amu.cz (fyzik)
Date: Wed Aug 25 09:03:29 2004
Subject: [Xorg] Matrox MGA G550 AGP, dueahead with 2 CRT
Message-ID: <412CB270.2050103@amu.cz>
Dear X-Org Developers,
I am using Gentoo Linux with xorg-x11 version 6.7.99.902 .
I have a Matrox MGA G550 AGP with two CTR monitors AOC Spectrum 7Glr.
The main bug I have observed is the frequency settign on the second
monitor. (The first one behaves well)
Upon start, the 1st monitor is set correctly to 1280x1024 at H-80kHz and
V-75Hz.
The second one is set out of limits specified in XF86Config, even though
both the monitor sections in the config (and the monitors themselves)
are identical.
If I play with the setting in the config, there are some changes in the
monitor setting upon restart, however they only roughly correspond to
what I've set in the config file (i.e. I specify 75 kHz , it still runs
at 82, I set max 65 and it runs at 60, etc).
If I download the binary driver for Linux from the matrox.com sitte and
I replace it, both the monitors behave as set in the config file, but
the monitors are swapped with respect to the xorg driver.
hope it helps with the development :)
and thank you guys for developing the X
cheers
0ndrej
From bryce at osdl.org Wed Aug 25 11:59:30 2004
Date: Wed Aug 25 11:59:36 2004
Subject: [Xorg] Tinderbox - all is well
Just a quick note - the problems noted on tinderbox yesterday are gone
and we're green across the board on all platforms. :-)
Bryce
From tcpdevil at linuxlover.org Wed Aug 25 11:41:40 2004
From: tcpdevil at linuxlover.org (Alberto Garcia Hierro)
Date: Wed Aug 25 12:03:22 2004
Subject: [Xorg] Failure building X.Org 6.7.99.902 on ppc
Message-ID: <200408252041.40241.tcpdevil@linuxlover.org>
Hi all list,
This morning i built X.Org 6.7.99.902 on my x86 desktop and it worked really
fine. Then i tried building it on my ibook G4 and it failed. I send you the
last output before the error because i think it could be usefull since, as
stated on http://www.freedesktop.org/XOrg/XorgReleaseStatus nobody has built
X.Org 6.7.99.902 on ppc yet. If you are interested on the distro, i run
Gentoo (unstable branch). As for the toolchain, i'm using:
gcc (GCC) 3.4.1 20040803 (Gentoo Linux 3.4.1-r2, ssp-3.4-2, pie-8.7.6.5)
binutils-2.15.90.0.3-r3
glibc-2.3.4.20040619-r1
If you want more information, just ask. I'll send everything needed very
happily.
--
Regards,
/* Alberto Garc?a Hierro (Skyhusker) */
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040825/b9997e67/attach
ment.pgp
From idr at us.ibm.com Wed Aug 25 12:11:25 2004
Date: Wed Aug 25 12:11:36 2004
In-Reply-To: <200408252041.40241.tcpdevil@linuxlover.org>
References: <200408252041.40241.tcpdevil@linuxlover.org>
Message-ID: <412CE45D.8060105@us.ibm.com>
Alberto Garcia Hierro wrote:
> Hi all list,
> This morning i built X.Org 6.7.99.902 on my x86 desktop and it worked really
> fine. Then i tried building it on my ibook G4 and it failed. I send you the
> last output before the error because i think it could be usefull since, as
> stated on http://www.freedesktop.org/XOrg/XorgReleaseStatus nobody has built
> X.Org 6.7.99.902 on ppc yet. If you are interested on the distro, i run
> Gentoo (unstable branch). As for the toolchain, i'm using:
There is a know problem building on PowerPC. Is this what you're seeing?
From cyfred at gentoo.org Wed Aug 25 14:42:47 2004
From: cyfred at gentoo.org (Andrew Bevitt)
Date: Wed Aug 25 14:39:29 2004
Subject: [Xorg] Release Status Testing Results
Message-ID: <200408260742.47339.cyfred@gentoo.org>
Hey,
Have done some testing under both IA-32 and AMD64 under Gentoo
IA-32 : http://dev.gentoo.org/~cyfred/xorg/testing/IA32/XORG-COMMENTS
AMD64 : http://dev.gentoo.org/~cyfred/xorg/testing/AMD64/XORG-COMMENTS
Log files from the builds, and *.summary from the xreg testing can be found in
the same directory as the above comments files; log files are around 4M
bunzip2-ed.
Executive summary
1) All build / install tests went smoothly
2) Conformance tests had some issues, summary files provided for info on what
FAILs I stil have the original results files aswell
3) Runtime appears uneffected by conformance testing
Andrew
NB. Sorry if this is a second appearance but it hasnt shown up here (with own
sending on) in 7 hours
From fxkuehl at gmx.de Wed Aug 25 15:31:58 2004
Date: Wed Aug 25 15:29:53 2004
Subject: [Xorg] Build failure: ft2build.h not found
In-Reply-To: <20040825173401.406ed4f3.felix@trabant>
References: <20040825173401.406ed4f3.felix@trabant>
Message-ID: <20040826003158.6c00a52f.felix@trabant>
Sorry for the fuss. RELNOTES answered all my questions WRT Freetype2.
From michel at daenzer.net Wed Aug 25 16:38:00 2004
Date: Wed Aug 25 16:38:15 2004
In-Reply-To: <412CE45D.8060105@us.ibm.com>
References: <200408252041.40241.tcpdevil@linuxlover.org>
<412CE45D.8060105@us.ibm.com>
On Wed, 2004-08-25 at 12:11 -0700, Ian Romanick wrote:
> Alberto Garcia Hierro wrote:
>
> > Hi all list,
> > This morning i built X.Org 6.7.99.902 on my x86 desktop and it worked reall
y
> > fine. Then i tried building it on my ibook G4 and it failed. I send you the
> > last output before the error because i think it could be usefull since, as
> > stated on http://www.freedesktop.org/XOrg/XorgReleaseStatus nobody has built

> > X.Org 6.7.99.902 on ppc yet. If you are interested on the distro, i run
> > Gentoo (unstable branch). As for the toolchain, i'm using:
>
> There is a know problem building on PowerPC. Is this what you're seeing?
>
I haven't seen that one, probably because I usually only build the
servers and friends, but I seem to have introduced
https://freedesktop.org/bugzilla/show_bug.cgi?id=1156 somehow.
--
From Deron.Johnson at Sun.COM Wed Aug 25 17:29:09 2004
Date: Wed Aug 25 17:30:29 2004
Subject: [Xorg] Question about the Xorg config file
Message-ID: <412D2ED5.5080102@Sun.COM>
I am currently working on a release of Project Looking Glass which
contains a modified server based on X.org X11R6.8. Previously,
the PLG users were using the X.org release prior to the renaming,
so the server config file these people are currently using is
named /etc/X11/XF86Config. I'm trying to figure out what to tell
these people about the config file when they start using 6.8.
To this end, I have some questions about the server config file.
1. If X.org X11R6.8 does not find a file named /etc/X11/xorg.conf, is it
supposed to try to find /etc/X11/XF86Config? It appears to behave
this way on my SUSE 8.1 machine.
2. What recommendations should I provide to my users on how to upgrade
their XF86Config file to become xorg.conf? Should they start with
a fresh xorg.conf file generated via Xorg -configure and then apply
their mods (such as graphics devices) to it? Or should they just
rename the XF86Config file to become xorg.conf? I tried the latter
and it complained that Driver "Keyboard" should be changed to
Driver "Kbd". Are there any other gotchas like this?
In general, is there any written documentation which discusses
config file upgrade issues?
Thank you for your assistance,
-Deron Johnson
Project Looking Glass
Sun Microsystems
From rayl at mail.com Wed Aug 25 21:46:23 2004
Date: Wed Aug 25 21:46:28 2004
Subject: [Xorg] testing xorg on suse 9.1
Message-ID: <20040826044623.GA26921@mail.com>
hi
i'd be interested in testing the latest xorg servers on my
home machine. i run suse 9.1 (free ftp edition) in IA-32.
i built XORG-6_7_99_902 last night and ran xreg, and got quite
a few Err files with the xvfb server.
is there some documentation somewhere about how to use files like
xtest.15bpp.20040825.000126.results/tset/CH06/drwarc/Err0077.err and
xtest.15bpp.20040825.000126.results/tset/CH06/drwtxt/Err0307.err?
i had problems with the xorg server. although i built with a
projroot=/tmp/XorgTEST, i got this:
# ./xreg -projroot /tmp/XorgTEST -xtest -xorg
* Wed Aug 25 14:19:21 MDT 2004: Starting script
* Wed Aug 25 14:19:21 MDT 2004: XSERVER=/tmp/XorgTEST/bin/Xorg
* Wed Aug 25 14:19:21 MDT 2004: HOST=ray
* Wed Aug 25 14:19:21 MDT 2004: DEPTHS=8 15 16 24+32
* Wed Aug 25 14:19:21 MDT 2004: Getting parameters from X server
* Wed Aug 25 14:19:21 MDT 2004: Starting X: parameters
* Wed Aug 25 14:19:21 MDT 2004: Start X server with :1 -depth 24 -fbbpp 32
* Wed Aug 25 14:19:31 MDT 2004: /tmp/XorgTEST/bin/Xorg failed to start
the output file showed
Fatal server error:
Cannot open log file "/var/log/Xorg.1.log"
so it seems that xorg is not correctly understanding that the
projroot was set in the host.def file?
--
----------------------------------------------------------------------
Date: Wed Aug 25 22:13:15 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 2
Added yesterday: 4
-----------------------------
- A configuration option should be added to enable/disable the hard
failure, with the default as enabled
for them
- Egbert will review
- Eric Anholt provided initial patch
- Adam Jackson says patch fixes problem but creates others with composite
* Bug #1156: Radeon driver build failures on PPC
- Patch supplied
- Just waiting for reply to question asked
* Bug #1157: Radeon line accel broken with DRI enabled
* Bug #1160: xf86drm.h needs xc/extras/drm/shared/drm.h for functional SDK
* Bug #1179: radeon_mergedfb.c won't build without Xinerama
- Fix supplied and reviewed
- Should the Radeon MergedFB Xinerama support be compiled in if
Xinerama support is turned off in the configuration files?
* Bug #1182: Xim deadlocks in certain situations
- Potential patch provided, but not thoroughly tested
- Egbert is asking for review of the patch
* Bug #1183: IA-64: HP ZX1/2 support current disabled
- Patch provided
Date: Wed Aug 25 22:15:53 2004
Subject: [Xorg] Release Status Testing Results
In-Reply-To: <200408260742.47339.cyfred@gentoo.org>
References: <200408260742.47339.cyfred@gentoo.org>
On Thu, Aug 26, 2004 at 07:42:47AM +1000, Andrew Bevitt wrote:
> Hey,
>
> Have done some testing under both IA-32 and AMD64 under Gentoo
>
> IA-32 : http://dev.gentoo.org/~cyfred/xorg/testing/IA32/XORG-COMMENTS
> AMD64 : http://dev.gentoo.org/~cyfred/xorg/testing/AMD64/XORG-COMMENTS
>
> Log files from the builds, and *.summary from the xreg testing can be found in

> the same directory as the above comments files; log files are around 4M
> bunzip2-ed.
>
> Executive summary
> 1) All build / install tests went smoothly
> 2) Conformance tests had some issues, summary files provided for info on what
> FAILs I stil have the original results files aswell
> 3) Runtime appears uneffected by conformance testing
>
> Andrew
Excellent report! This is exactly what we are looking for.
Thanks!
Date: Wed Aug 25 22:28:39 2004
Subject: [Xorg] testing xorg on suse 9.1
In-Reply-To: <20040826044623.GA26921@mail.com>
References: <20040826044623.GA26921@mail.com>
On Wed, Aug 25, 2004 at 10:46:23PM -0600, Ray Lehtiniemi wrote:
>
> hi
>
> i'd be interested in testing the latest xorg servers on my
> home machine. i run suse 9.1 (free ftp edition) in IA-32.
>
> i built XORG-6_7_99_902 last night and ran xreg, and got quite
> a few Err files with the xvfb server.
>
> is there some documentation somewhere about how to use files like
> xtest.15bpp.20040825.000126.results/tset/CH06/drwarc/Err0077.err and
> xtest.15bpp.20040825.000126.results/tset/CH06/drwtxt/Err0307.err?
There is a program that comes with the test suite called "blowup" that
will allow you to view these files. This is documented in the user
guide found here: xtest/xsuite/xtest/doc/userguide.mm
I'm seeing quite a few failures in XDrawText and XDrawText16 as well as
a few other individual test failures. I'm investigating each of these
and would be interested to see which tests are failing for you. Could
you post your summary file so that I could see which tests are failing
on your system?
Also, the XDrawArc and XDrawArcs failures are known and expected.
> i had problems with the xorg server. although i built with a
> projroot=/tmp/XorgTEST, i got this:
>
> # ./xreg -projroot /tmp/XorgTEST -xtest -xorg
>
> * Wed Aug 25 14:19:21 MDT 2004: Starting script
> * Wed Aug 25 14:19:21 MDT 2004: XSERVER=/tmp/XorgTEST/bin/Xorg
> * Wed Aug 25 14:19:21 MDT 2004: HOST=ray
> * Wed Aug 25 14:19:21 MDT 2004: DEPTHS=8 15 16 24+32
> * Wed Aug 25 14:19:21 MDT 2004: Getting parameters from X server
> * Wed Aug 25 14:19:21 MDT 2004: Starting X: parameters
> * Wed Aug 25 14:19:21 MDT 2004: Start X server with :1 -depth 24 -fbbpp 32
> * Wed Aug 25 14:19:31 MDT 2004: /tmp/XorgTEST/bin/Xorg failed to start
>
> the output file showed
>
> Fatal server error:
> Cannot open log file "/var/log/Xorg.1.log"
>
>
> so it seems that xorg is not correctly understanding that the
> projroot was set in the host.def file?
It tried to start the Xorg server from your project root, but from the
error, it looks like /tmp/XorgTEST/bin/Xorg is either not owned by root
or not setuid root. Perhaps you installed everything as yourself
instead of root? What I normally do is to run the make install as
myself, and then run "chown -R 0.0 /tmp/XorgTEST" as root after the
install completes.
Hope this helps,
Kevin
Date: Wed Aug 25 23:00:46 2004
In-Reply-To: <412D2ED5.5080102@Sun.COM>
References: <412D2ED5.5080102@Sun.COM>
Hash: SHA1
On Wednesday 25 August 2004 20:29, Deron Johnson wrote:
> I am currently working on a release of Project Looking Glass which
> contains a modified server based on X.org X11R6.8. Previously,
> the PLG users were using the X.org release prior to the renaming,
> so the server config file these people are currently using is
> named /etc/X11/XF86Config. I'm trying to figure out what to tell
> these people about the config file when they start using 6.8.
>
> To this end, I have some questions about the server config file.
>
> 1. If X.org X11R6.8 does not find a file named /etc/X11/xorg.conf, is it
> supposed to try to find /etc/X11/XF86Config? It appears to behave
> this way on my SUSE 8.1 machine.
Yes. This was done to make transitioning from XF86 4.3 to Xorg 6.7 as
painless as possible. In general config files that work under XFree86 4.x
(where x <= 4) should work fine under Xorg.
> 2. What recommendations should I provide to my users on how to upgrade
> their XF86Config file to become xorg.conf? Should they start with
> a fresh xorg.conf file generated via Xorg -configure and then apply
> their mods (such as graphics devices) to it? Or should they just
> rename the XF86Config file to become xorg.conf? I tried the latter
> and it complained that Driver "Keyboard" should be changed to
> Driver "Kbd". Are there any other gotchas like this?
Just rename is fine. The keyboard driver issue is a warning because we're
deprecating the old keyboard(4), but it should fall back to the kbd(4) driver
automatically.
> In general, is there any written documentation which discusses
> config file upgrade issues?
Not yet, because there aren't any issues really. Though we don't pick up
XF86Config-4 if we're missing both xorg.conf and XF86Config. Personally I'm
surprised anyone still generates files named XF86Config-4.
- - ajax
iD8DBQFBLXdoW4otUKDs0NMRAgdfAKDcBiWUoNKHKbORXgO+v+e5q+UhpACfbF+G
mxxs9ewEO7/K0eT7ahtyZkY=
=H+kd
Date: Thu Aug 26 00:25:47 2004
References: <412D2ED5.5080102@Sun.COM> <200408260138.49529.ajax@nwnk.net>
Message-ID: <412D8FF8.2030803@winischhofer.net>
Adam Jackson wrote:
> Not yet, because there aren't any issues really. Though we don't pick up
> XF86Config-4 if we're missing both xorg.conf and XF86Config. Personally I'm
> surprised anyone still generates files named XF86Config-4.
Debian, in order to have XFree86 3.3 (which still is in Woody=stable
AFAIK) and 4.x installed at the same time.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From spyderous at gentoo.org Thu Aug 26 00:38:55 2004
Date: Thu Aug 26 00:41:10 2004
On Thu, 2004-08-26 at 00:38, Adam Jackson wrote:
> Not yet, because there aren't any issues really. Though we don't pick up
> XF86Config-4 if we're missing both xorg.conf and XF86Config. Personally I'm
> surprised anyone still generates files named XF86Config-4.
ATI's binary driver config tool does by default, last I checked. Also,
XF86Config-4 ought to take precedence over XF86Config.
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040826/00b867d2/attach
ment.pgp
From dag at bakke.com Thu Aug 26 03:54:53 2004
From: dag at bakke.com (dag@bakke.com)
Date: Thu Aug 26 03:54:57 2004
Subject: [Xorg] Truly start X in the background ?
Message-ID: <20040826035453.24361.h010.c000.wm@mail.bakke.com.criticalpath.net>
Apologies if this is offtopic for this list.
I would like to have xdm start in virtual console 7 (this is under Linux)
without interrupting my work in whatever console I am working in.
I.e. if executing 'xdm' in a console, xdm would daemonize immediately and
let me continue whatever I want to do in the console I started xdm from.
When I need to switch to X, I'll do that with Alt-F7.
I don't think this is doable right now. Would it be a feature of X/xdm or
Linux' console handling?
I do know about chvt(1), but it is still "disruptive" to have the screen
flashing and keyboard handling jumping between console and X.
I also understand that X tries to probe the graphics and monitor during
startup, but is that always mandatory? Could one imagine saving the
results of the initial probing, and feeding that result back to X later.
(Effectively saying: "skip probing, this is what you want").
Regards,
Dag B
Date: Thu Aug 26 06:01:55 2004
Subject: [Xorg] Fwd: drm patch
In-Reply-To: <412DA55A.6080607@nix.lv>
References: <412DA55A.6080607@nix.lv>
Message-ID: <a728f9f904082606015fd22816@mail.gmail.com>
I haven't checked xorg cvs, but this patch may be needed there as well.
---------- Forwarded message ----------
From: Lafriks <listes@nix.lv>
Date: Thu, 26 Aug 2004 11:54:50 +0300
Subject: drm patch
To: jonsmirl@yahoo.com
Cc: dri-devel@lists.sourceforge.net
Hi,
Wanted to report that without this patch my ATI Radeon IGP 345M
didn't have direct rendering support with yesterday mesa-cvs and
dri-cvs. After applying patch I have dri support :) Hope this patch will
be included in cvs soon... it's great ;)
Lafriks
p.s. patch by Jon Smirl:
===== linux/drm_drv.h 1.8 vs edited =====
--- 1.8/linux/drm_drv.h Tue Aug 17 11:38:31 2004
+++ edited/linux/drm_drv.h Fri Aug 20 16:37:08 2004
@@ -635,7 +635,7 @@
static int __init drm_init( void )
{
struct pci_dev *pdev = NULL;
- struct pci_driver *pdriver = NULL;
+ struct pci_device_id *pid;
int i;
DRM_DEBUG( "\n" );
@@ -647,21 +647,26 @@
DRM(mem_init)();
for (i=0; DRM(pciidlist)[i].vendor != 0; i++) {
- pdev = pci_get_subsys(DRM(pciidlist[i]).vendor,
DRM(pciidlist[i]).device, DRM(pciidlist[i]).subvendor,
DRM(pciidlist[i]).subdevice, NULL);
- if (pdev)
- {
- pdriver = pci_dev_driver(pdev);
- if (pdriver)
- {
- DRM(fb_loaded)=1;
+ pid = &DRM(pciidlist[i]);
+
+ /* pass back in pdev to account for multiple identical cards */
+ while ((pdev = pci_get_subsys(pid->vendor, pid->device,
pid->subvendor, pid->subdevice, pdev))) {
+ /* is there already a driver loaded, or (short
circuit saves work) */
+ /* does something like VesaFB have control of
the memory region? */
+ if (pci_dev_driver(pdev) ||
pci_request_regions(pdev, "DRM scan")) {
+ /* go into stealth mode */
+ DRM(fb_loaded) = 1;
drm_probe(pdev, &DRM(pciidlist[i]));
+ /* keep looping to get all devices */
+ continue;
}
- else
- pci_dev_put(pdev);
+ /* no fbdev or vesadev, put things back and
wait for normal probe */
+ pci_release_regions(pdev);
+ pci_dev_put(pdev);
}
}
- if (DRM(fb_loaded)==0)
+ if (DRM(fb_loaded) == 0)
pci_register_driver(&drm_driver);
else
DRM_INFO("Used old pci detect: framebuffer loaded\n");
From tim at birdsnest.maths.tcd.ie Thu Aug 26 07:54:14 2004
From: tim at birdsnest.maths.tcd.ie (Timothy Murphy)
Date: Thu Aug 26 08:36:13 2004
<1093505934.9888.21.camel@localhost>
Message-ID: <200408261554.14762.tim@birdsnest.maths.tcd.ie>
On Thursday 26 August 2004 08:38, Donnie Berkholz wrote:
> ATI's binary driver config tool does by default, last I checked. Also,
> XF86Config-4 ought to take precedence over XF86Config.
Is there a binary driver that works with the ATI Rage Mobility graphics system
as a matter of interest?
I could only find drivers for the ATI Radeon series.
I have a Sony C1VFK Picturebook with ATI Rage Mobiliity P/M
which worked perfectly under FC-1 (and XFree86)
but will not work at 16bpp under Xorg.
I've asked many people many times about this,
but basically never got any helpfule replies.
(Well, I have a collection of 23 xorg.conf files,
but none of them are any better than my old XFree86 conf file.)
Incidentally, there is no X error shown -
but when X starts I just get a big black oval on the screen,
which gradually changes to a blank white screen.
I'm trying to downgrade to XFree86
but without success so far ...
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
From bryce at osdl.org Thu Aug 26 09:51:41 2004
Date: Thu Aug 26 09:51:43 2004
Subject: [Xorg] Tinderbox - error in 'make clean'
alanc-Solarisx86 is showing errors in the make clean process:
make -f xmakefile BOOTSTRAPSUBDIRS= clean
...
rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS
make.log MakeOut "#"*
cleaning in lib/GL/glx...
make: Fatal error in reader: Makefile, line 16: Unexpected end of line
seen
Current working directory /export/home/tinderu/XMonolithic/xc/lib/GL/glx
*** Error code 1
826074412.log
The other build machines haven't exhibited this behavior but it's
occurred several times on the alanc machine. This started happening at
around 5am PST (5 hrs ago) today.
Bryce
From cyfred at gentoo.org Wed Aug 25 07:39:48 2004
From: cyfred at gentoo.org (Andrew Bevitt)
Date: Thu Aug 26 11:45:23 2004
Subject: [Xorg] Release Status Results (IA-32 / AMD64 Gentoo LInux)
Message-ID: <200408260039.48555.cyfred@gentoo.org>
Hey,
Have done some testing under both IA-32 and AMD64 under Gentoo
IA-32 : http://dev.gentoo.org/~cyfred/xorg/testing/IA32/XORG-COMMENTS
AMD64 : http://dev.gentoo.org/~cyfred/xorg/testing/AMD64/XORG-COMMENTS
Log files from the builds, and *.summary from the xreg testing can be found in
the same directory as the above comments files; log files are around 4M
bunzip2-ed.
Executive summary
1) All build / install tests went smoothly
2) Conformance tests had some issues, summary files provided for info on what
FAILs I stil have the original results files aswell
3) Runtime appears uneffected by conformance testing
Andrew
From npmccallum at gentoo.org Thu Aug 26 11:11:37 2004
From: npmccallum at gentoo.org (Nathaniel McCallum)
Date: Thu Aug 26 12:08:47 2004
Subject: [Xorg] Truly start X in the background ?
In-Reply-To: <20040826035453.24361.h010.c000.wm@mail.bakke.com.criticalpath.net>
References: <20040826035453.24361.h010.c000.wm@mail.bakke.com.criticalpath.net>
On Thu, 2004-08-26 at 03:54 -0700, dag@bakke.com wrote:
> Apologies if this is offtopic for this list.
>
> I would like to have xdm start in virtual console 7 (this is under Linux)
> without interrupting my work in whatever console I am working in.
>
> I.e. if executing 'xdm' in a console, xdm would daemonize immediately and
> let me continue whatever I want to do in the console I started xdm from.
> When I need to switch to X, I'll do that with Alt-F7.
> I don't think this is doable right now. Would it be a feature of X/xdm or
> Linux' console handling?
>
> I do know about chvt(1), but it is still "disruptive" to have the screen
> flashing and keyboard handling jumping between console and X.
>
> I also understand that X tries to probe the graphics and monitor during
> startup, but is that always mandatory? Could one imagine saving the
> results of the initial probing, and feeding that result back to X later.
> (Effectively saying: "skip probing, this is what you want").
I believe daniels already did a patch for this (its a -noswitchvt
option). I'm not sure if it is in upstream yet.
Nathaniel
Date: Thu Aug 26 16:01:22 2004
Subject: [Xorg] any comments on this xrender vs Imlib2 benchmarks?
Any comments on this xrender vs Imlib2 benchmarks?
I mean like: is Imlib2 really so mutch faster? If so why isn't it used
:)
http://www.osnews.com/comment.php?news_id=7953#268194
some extra stuff about the subject:
http://forums.gentoo.org/viewtopic.php?p=1459060&highlight=xorg+rasterman#145906
0
--
From shawn.starr at rogers.com Thu Aug 26 16:32:47 2004
Date: Thu Aug 26 16:32:07 2004
Subject: [Xorg] RE: [GATOS]Getting GATOS branch created on Xorg
In-Reply-To: <200408270031.44200.lourens@rainbowdesert.net>
Message-ID: <003801c48bc5$00a5caa0$0200080a@panic>
But we still need a branch in Xorg to start with ;-)
> -----Original Message-----
> From: Lourens Veen [mailto:lourens@rainbowdesert.net]
> Sent: Thursday, August 26, 2004 18:32
> To: Shawn Starr; volodya@mindspring.com;
> gatos-devel@lists.sourceforge.net
> Cc: xorg@freedesktop.org
> Subject: Re: [GATOS]Getting GATOS branch created on Xorg
>
>
> On Fri 20 August 2004 03:54, Shawn Starr wrote:
> > It would be best to discuss this so that it gets more visibility.
> >
> > What does everyone think?
> >
> > Shawn.
> >
> > On Tue, 17 Aug 2004, Shawn Starr wrote:
> > > Where would the latest code base be available? Would you
> want write
> > > access
> >
> > to
> >
> > > CVS? Its possible you'd get a branch for GATOS and then when its
> > > stablized within Xorg be merged into -HEAD.
> >
> > Good question. The thing is I had very little time for development
> > lately so perhaps this is best asked of other GATOS developers.
> >
> > So, I think it would make sense to put this question to the mailing
> > list - it might be better for everyone if GATOS development
> switches
> > to X.Org CVS, at least as far as driver work is concerned.
> >
> > What is your opinion ?
>
> I don't think my opinion should carry much weight, given my newness
> to Gatos, but you asked for an opinion, so you get one :-).
>
> I think this is a good first step on the road to merging Gatos back
> into Xorg. The whole idea for Gatos was to develop TV-in support
> separately from XFree86, and then fold it back into XFree86 when it
> was ready. Unfortunately this last thing never happened, because of
> the closed development model of XFree86. Now that we have Xorg, we
> have an actual chance of eventually merging Gatos back in.
>
> What this project needs is more users to test and give feedback, and
> more developers to write code and fix bugs (and more docs from ATI<
> but well...). Merging it back into Xorg eventually can give us that
> extra exposure and move the project forward faster.
>
> So, as a first step towards that goal, switching to Xorg CVS may be
> a good idea. It might also be a bit more reliable :-). Personally,
> I'd be happy to send my patches to a list for someone else to
> commit. I don't feel at home enough to be checking things in
> without outside review anyway.
>
> My 2 eurocents (soon to be Swiss centimes, for three months at
> least).
>
> Lourens
> --
> GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
>
Date: Thu Aug 26 17:01:33 2004
Subject: [Xorg] Nvidia testing on SuSE 9.1.
Message-ID: <1093564868.16010.3.camel@linux.site>
OK, Keith helped me figure out why I was losing with 3D.
So I can report that composite works very nicely (acceptable
performance) with the nvidia binary driver in widespread distribution
on SuSE 9.1, with render acceleration enabled.
And I'm happily able to run glxgears and, more importantly,
Quake 3 demo fine.
This is a relief, as we were worried something might have broken
the binary interface.
I'll try Andy's RandR driver tomorrow if I have time (not clear).
- Jim
From chris at adebenham.com Thu Aug 26 16:53:26 2004
From: chris at adebenham.com (Chris Debenham)
Date: Thu Aug 26 17:07:00 2004
In-Reply-To: <20040824225445.GD4314@mail.com>
References: <20040824225445.GD4314@mail.com>
Message-ID: <20040826235325.GB1462@hackbox>
G'day all,
Just completed trying to get x.org compiled on Debian/SPARC
Build with empty host.def file
1. Chris Debenham
2. Fri Aug 27 09:48:21 EST 2004
3. Linux, SPARC, Debian/SID
4. XORG-6_7_99_902
5. All three attempts failed.
host.defs/LOG files can be found at http://www.adebenham.com/xorg
6. untested
7. untested
8. untested
They seem to fail while compiling MESA:
make[6]: Entering directory usr/local/src/xc/lib/GL/mesa/sparc'
rm -f sparc.o
gcc -c -O2 -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict
-prototypes -Wmissing-prototypes -Wmissing-declarations -
Wredundant-decls -Wnested-externs -Wundef -I../../../../expo rts/include -I../..
/../../include/extensions -I../../../../extras/Mesa/src -I../../../../extras/Mes
a/src/SPARC -I../../../include -I.. /../../.. -I../../../../exports/include -D
linux -D__sparc__ -D_POSIX_C_SOURCE= 199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_
BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DMALLO C_0
_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGL X_
USE_MESA -D__GLX_ALIGN64 -DUSE_SPARC_ASM -fPIC sparc.c
sparc.c:32:21: context.h: No such file or directory
sparc.c:33:26: math/m_xform.h: No such file or directory
sparc.c:34:27: tnl/t_context.h: No such file or directory
sparc.c:35:19: sparc.h: No such file or directory
It also fails with errors in freetype/libxml as seen in the
buildserversonly attempt. I'll re-install libxml-dev and try this again
but I think it will fail on MESA eventually anyway
Chris
--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
From aritger at nvidia.com Thu Aug 26 17:03:37 2004
Date: Thu Aug 26 17:08:49 2004
Subject: [Xorg] Re: Nvidia testing on SuSE 9.1.
In-Reply-To: <1093564868.16010.3.camel@linux.site>
References: <1093564868.16010.3.camel@linux.site>
On Thu, 26 Aug 2004, Jim Gettys wrote:
> OK, Keith helped me figure out why I was losing with 3D.
What was wrong? I assume this was an install issue? Maybe the
Mesa OpenGL libraries from the X.org build were colliding with the
NVIDIA OpenGL libs?
Thanks,
- Andy
> So I can report that composite works very nicely (acceptable
> performance) with the nvidia binary driver in widespread distribution
> on SuSE 9.1, with render acceleration enabled.
>
> And I'm happily able to run glxgears and, more importantly,
> Quake 3 demo fine.
>
> This is a relief, as we were worried something might have broken
> the binary interface.
>
> I'll try Andy's RandR driver tomorrow if I have time (not clear).
> - Jim
>
>
>
From ajax at nwnk.net Thu Aug 26 16:59:11 2004
Date: Thu Aug 26 17:21:07 2004
In-Reply-To: <20040826235325.GB1462@hackbox>
References: <20040824225445.GD4314@mail.com> <20040826235325.GB1462@hackbox>
Hash: SHA1
On Thursday 26 August 2004 19:53, Chris Debenham wrote:
> G'day all,
>
> Just completed trying to get x.org compiled on Debian/SPARC
> <snip>
> They seem to fail while compiling MESA:
> <snip>
> sparc.c sparc.c:32:21: context.h: No such file or directory
> sparc.c:33:26: math/m_xform.h: No such file or directory
> sparc.c:34:27: tnl/t_context.h: No such file or directory
> sparc.c:35:19: sparc.h: No such file or directory
This was http://freedesktop.org/bugzilla/show_bug.cgi?id=1104 , which was
fixed two days after RC2 was tagged.
Perhaps we need an RC3 sometime soon?
- - ajax
iD8DBQFBLnlSW4otUKDs0NMRAnhmAJ9bwtecIBx/wtlxHDEoMkrre+/1BwCgqw+I
Gp6joqWOZxLttIK6tsN5RFQ=
=T/MM
Date: Thu Aug 26 17:57:00 2004
In-Reply-To: <Pine.LNX.4.58.0408262002190.12438@paert.nvidia.com>
References: <1093564868.16010.3.camel@linux.site>
<Pine.LNX.4.58.0408262002190.12438@paert.nvidia.com>
Message-ID: <1093568195.18239.1.camel@linux.site>
On Thu, 2004-08-26 at 20:03, Andy Ritger wrote:
> On Thu, 26 Aug 2004, Jim Gettys wrote:
>
> > OK, Keith helped me figure out why I was losing with 3D.
>
> What was wrong? I assume this was an install issue? Maybe the
> Mesa OpenGL libraries from the X.org build were colliding with the
> NVIDIA OpenGL libs?
Exactly. Both the libGL.so and the GLX module, since you use one
of your own.
In any case, I'm a happy camper :-). And the composite performance
with xcompmgr -c is quite acceptable.
- Jim
>
> Thanks,
> - Andy
>
> > So I can report that composite works very nicely (acceptable
> > performance) with the nvidia binary driver in widespread distribution
> > on SuSE 9.1, with render acceleration enabled.
> >
> > And I'm happily able to run glxgears and, more importantly,
> > Quake 3 demo fine.
> >
> > This is a relief, as we were worried something might have broken
> > the binary interface.
> >
> > I'll try Andy's RandR driver tomorrow if I have time (not clear).
> > - Jim
> >
> >
> >
> _______________________________________________
> xorg mailing list
Date: Thu Aug 26 18:15:41 2004
In-Reply-To: Your message of "Thu, 26 Aug 2004 20:03:37 EDT."
<Pine.LNX.4.58.0408262002190.12438@paert.nvidia.com>
Message-ID: <E1C0VJH-0001lD-J7@evo.keithp.com>
Around 20 o'clock on Aug 26, Andy Ritger wrote:
> What was wrong? I assume this was an install issue? Maybe the
> Mesa OpenGL libraries from the X.org build were colliding with the
> NVIDIA OpenGL libs?
That was the obvious problem, but not the real issue. It was the GLX X
server module -- when the nvidia glx .so wasn't present, the driver would
segfault when a GL client was run. Seems like the segfault could be
avoided...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040826/544cca62/attach
ment.pgp
From carl at personnelware.com Thu Aug 26 19:05:53 2004
Date: Thu Aug 26 19:07:16 2004
Subject: [Xorg] quicker re-make
Message-ID: <28f001c48bda$65600720$1e01a8c0@cnt496>
I heard that make World first does a make clean? (didn't look at the make file,
been too long and I may have forgotten how it works)
If so, is there a way to just build the files that are out of date?
Carl K
Date: Thu Aug 26 19:17:27 2004
In-Reply-To: <28f001c48bda$65600720$1e01a8c0@cnt496>
References: <28f001c48bda$65600720$1e01a8c0@cnt496>
Message-ID: <a728f9f904082619176ff1aaf3@mail.gmail.com>
On Thu, 26 Aug 2004 21:05:53 -0500, Carl Karsten <carl@personnelware.com> wrote:
> I heard that make World first does a make clean? (didn't look at the make fil
e,
> been too long and I may have forgotten how it works)
>
> If so, is there a way to just build the files that are out of date?
make Everything
Alex
>
> Carl K
>
Date: Thu Aug 26 19:19:01 2004
On Thu, Aug 26, 2004 at 09:05:53PM -0500, Carl Karsten wrote:
e,
>
There are two options here. If none of the configuration or Imakefiles
have changed, then you should be able to just do a "make" at the top
level to rebuild all files. Otherwise, you can do a "make Everything",
which is very similar to make World, but it does not do a make clean
first.
Date: Thu Aug 26 19:28:05 2004
Subject: [Xorg] Development policies/GATOS merge
I have a few questions about Xorg development policies that I could not
find an easy answer to on the web, could some of the developer please
comment ? - Thank you !
* What is the procedure for submitting patches to Xorg tree ?
* Is it possible/what is required to obtain CVS access ?
(Specifically for GATOS TV-in/TV-out enhancements to ATI cards
drivers)
* Is there a particular person maintaining
xc/programs/Xserver/hw/xfree86/drivers/ati
thank you !
Vladimir Dergachev
From rlrevell at joe-job.com Thu Aug 26 19:31:01 2004
From: rlrevell at joe-job.com (Lee Revell)
Date: Thu Aug 26 19:37:47 2004
Subject: [Xorg] xorg cvs won't compile: security/pam_appl.h not found
Message-ID: <1093573861.30490.6.camel@krustophenia.net>
I had the following error compiling from CVS:
making all in programs/xdm...
make[3]: Entering directory `/home/rlrevell/cvs/xc/programs/xdm'
rm -f auth.o
gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -
Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I.
./.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_S
OURCE -D_GNU_SOURCE -DFU
NCPROTO=15 -DNARROWPROTO -DBINDIR=\"/usr/X11R6/bin\" -DXDMDIR=\"/usr/X11R6/lib
/X11/xdm\" -DHASXDMAUTH -DUSESHADOW -DUSE
_PAM -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6 -
DGREET_USER_STATIC -DFRAGILE_DEV_MEM -DDEV_RANDOM=\"/dev/random\"
-DOSMAJORVERSION=2 -DOSMINORVERSION=6
-DXPM -DUSE_XINERAMA -DHAS_MKSTEMP auth.c
In file included from auth.c:45:
dm.h:106:31: security/pam_appl.h: No such file or directory
In file included from auth.c:45:
dm.h:428: error: parse error before '*' token
dm.h:428: warning: type defaults to ìnt' in declaration of `thepamhp'
dm.h:428: error: ISO C forbids data definition with no type or storage class
dm.h:429: error: parse error before '*' token
dm.h:429: warning: type defaults to ìnt' in declaration of `thepamh'
dm.h:429: error: ISO C forbids data definition with no type or storage class
make[3]: *** [auth.o] Error 1
make[3]: Leaving directory `/home/rlrevell/cvs/xc/programs/xdm'
make[2]: Leaving directory `/home/rlrevell/cvs/xc/programs'
make[1]: Leaving directory `/home/rlrevell/cvs/xc'
make: *** [all] Error 2
It turns out that file was from the libpam0g-dev Debian package.
Why isn't this checked for at the beginning of the build? For that
matter why doesn't xorg use autoconf?
Lee
From chris at adebenham.com Thu Aug 26 19:25:35 2004
From: chris at adebenham.com (Chris Debenham)
Date: Thu Aug 26 20:03:36 2004
References: <20040824225445.GD4314@mail.com> <20040826235325.GB1462@hackbox>
<200408261959.16009.ajax@nwnk.net>
Message-ID: <20040827022534.GC1462@hackbox>
On Thu, Aug 26, 2004 at 07:59:11PM -0400, Adam Jackson wrote in a legally bindin
g way:
> Date: Thu, 26 Aug 2004 19:59:11 -0400
> From: Adam Jackson <ajax@nwnk.net>
> To: xorg@freedesktop.org, chris@adebenham.com
> Subject: Re: [Xorg] build test results
>
> Hash: SHA1
>
> On Thursday 26 August 2004 19:53, Chris Debenham wrote:
> > G'day all,
> >
> > Just completed trying to get x.org compiled on Debian/SPARC
> > <snip>
> > They seem to fail while compiling MESA:
> > <snip>
> > sparc.c sparc.c:32:21: context.h: No such file or directory
> > sparc.c:33:26: math/m_xform.h: No such file or directory
> > sparc.c:34:27: tnl/t_context.h: No such file or directory
> > sparc.c:35:19: sparc.h: No such file or directory
>
> This was http://freedesktop.org/bugzilla/show_bug.cgi?id=1104 , which was
> fixed two days after RC2 was tagged.
>
> Perhaps we need an RC3 sometime soon?
>
> - - ajax
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBLnlSW4otUKDs0NMRAnhmAJ9bwtecIBx/wtlxHDEoMkrre+/1BwCgqw+I
> Gp6joqWOZxLttIK6tsN5RFQ=
> =T/MM
> -----END PGP SIGNATURE-----
Should I now test it with just the patch applied, or update cvs to a
different tag?
Chris
--
Mary had a little key (It's all she could export),
and all the email that she sent was opened at the Fort.
From eta at lclark.edu Thu Aug 26 20:09:44 2004
Date: Thu Aug 26 20:43:54 2004
Message-ID: <1093576184.13315.2.camel@abbey>
On Thu, 2004-08-26 at 19:05, Carl Karsten wrote:
e,
>
"make World" does the bootstrapping, cleans, makes new makefiles,
includes, depends, and builds
"make Everything" makes new makefiles, includes, depends, and builds
"make" alone just builds.
Date: Thu Aug 26 21:17:41 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 5
Added yesterday: 1
-----------------------------
- A configuration option should be added to enable/disable the hard
failure, with the default as enabled
for them
- Egbert will review
- Patch provided
* Bug #1188: ARM build failure
- Patch provided
From aritger at nvidia.com Thu Aug 26 22:11:45 2004
Date: Thu Aug 26 22:12:23 2004
In-Reply-To: <E1C0VJH-0001lD-J7@evo.keithp.com>
References: <E1C0VJH-0001lD-J7@evo.keithp.com>
On Thu, 26 Aug 2004, Keith Packard wrote:
>
> Around 20 o'clock on Aug 26, Andy Ritger wrote:
>
> > What was wrong? I assume this was an install issue? Maybe the
> > Mesa OpenGL libraries from the X.org build were colliding with the
> > NVIDIA OpenGL libs?
>
> That was the obvious problem, but not the real issue. It was the GLX X
> server module -- when the nvidia glx .so wasn't present, the driver would
> segfault when a GL client was run. Seems like the segfault could be
> avoided...
Right, the driver should fall back to indirect rendering in that case. I'll inv
estigate...
- Andy
> -keith
>
>
>
From nathanh at manu.com.au Fri Aug 27 01:31:24 2004
From: nathanh at manu.com.au (Nathan Hand)
Date: Fri Aug 27 01:39:24 2004
Subject: [Xorg] 6_7_99_2 build test results: debian/ppc
Build results for Debian/unstable on PPC (G4). This is a 12" PowerBook
G4 so the chipset is an Nvidia FX Go5200.
1. Nathan Hand <nathanh@manu.com.au>
2. 26 August 2004
3. Debian Linux/PPC unstable
4. XORG-6_7_99_2
5. Build emptydef: passed, serversonly: passed, doloadable: passed
6. Install emptydef: passed, projectroot (/opt/xorg): passed
7. Conformance test status: untested, details below
8. Run test status: passed and failed, details below
All builds were flawless, near as I can tell. Ran to completion with
"Full build of Release 6.7 complete" as the last message.
Build compiler was gcc 3.3.4 (Debian package 3.3.4-9).
Run tests only completed for 16bpp. Composite extension disabled.
1. X test suite: untested, see below
2. x11perf: ran to completion, all tests successful, unsure about
pixel accuracy.
3. rendercheck: seems every test had errors. Always the alpha is
wrong (got 1.0, expected 0.0). Sometimes RED is off by 0.02.
4. GNOME: works fine, no glitches observed, used for several hours
without any problems.
5. GL: software rendering only (nvidia chipset), glxgears works at
145 fps. Looks OK.
6. VT switching: ctrl-alt-fn-f1 seems to not work, not sure why, I
haven't disabled it in xorg.conf.
The xreg script caused the server to bomb out with Fatal 11. I haven't
yet investigated the problem so I don't have any conformance tests.
The world.logs and install.logs for each build are available. Can also
provide x11perf and rendercheck test results.
From svu at gnome.org Fri Aug 27 04:42:38 2004
From: svu at gnome.org (Sergey V. Udaltsov)
Date: Fri Aug 27 05:13:43 2004
Subject: [Xorg] xkeyboard-config and xorg releases
In-Reply-To: <20040827021905.DEE339FC5A@freedesktop.org>
References: <20040827021905.DEE339FC5A@freedesktop.org>
Message-ID: <412F1E2E.6000603@gnome.org>
Hi all
Unfortunately, it seems xkeyboard-config missed upcoming xorg release -
but still the issue is in the air: whether it is going to be used as a
reference XKB config repository for xorg - or not (and if yes - how
should be manage this process). Currently xkeyboard-config is in usable
state (starting from version 0.3) and I would like to offer it for all
future xorg releases. Sure, I would be interested in extensive testing,
reviewing. For more information, see
http://www.freedesktop.org/Software/XKeyboardConfig.
Sergey
From gorik.vansteenberge at gmail.com Thu Aug 26 14:31:20 2004
From: gorik.vansteenberge at gmail.com (Gorik Van Steenberge)
Date: Fri Aug 27 05:17:32 2004
Subject: [Xorg] libXt-0.1.5 compilation error in Initialize.c
Message-ID: <44a7f8d2040826143148896747@mail.gmail.com>
Hello,
When compiling libXt-0.1.5 (found here:
http://freedesktop.org/~xlibs/release/), I get the following error:
gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -DXTHREADS
-I/usr/local/include -I./include -I./include/X11 -g -O2 -MT
Initialize.lo -MD -MP -MF .deps/Initialize.Tpo -c Initialize.c -fPIC
-DPIC -o .libs/Initialize.o
Initialize.c: In function `_XtGetUserName':
Initialize.c:306: error: structure has no member named `pw_age'
Initialize.c:306: error: structure has no member named `pw_comment'
Initialize.c: In function `GetRootDirName':
make[2]: *** [Initialize.lo] Error 1
make[2]: Leaving directory `/home/gvs/src/x.org/libXt-0.1.5'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/gvs/src/x.org/libXt-0.1.5'
make: *** [all] Error 2
Google turns up nothing searching for this problem, so I assume
something must be wrong on my end? I'm running slackware 10 and X.org
6.7 (checked out from cvs today).
Thanks!
From eich at suse.de Fri Aug 27 06:27:41 2004
From: eich at suse.de (Egbert Eich)
Date: Fri Aug 27 06:27:57 2004
In-Reply-To: kem@freedesktop.org wrote on Friday,
27 August 2004 at 00:17:35 -0400
Kevin E Martin writes:
> * Bug #1119: Build breaks with UseInstalled* and ProjectRoot set
> - Initial patch supplied.
> - Others using UseInstalled should test the patch to see if it works
> for them
> - Egbert will review
>
Done.
Egbert.
Date: Fri Aug 27 08:25:44 2004
Subject: [Xorg] xorg cvs won't compile: security/pam_appl.h not found
In-Reply-To: <1093573861.30490.6.camel@krustophenia.net>
References: <1093573861.30490.6.camel@krustophenia.net>
Message-ID: <412F5278.90700@sun.com>
Lee Revell wrote:
> For that matter why doesn't xorg use autoconf?
Because the tree is huge, supports a huge number of platforms, with a
very complicated build setup, and conversion of all that to autoconf
is a huge undertaking which is being done in the "modular" tree for a
future release, while we continue to use imake in the monolithic tree
while the autoconf conversion is still a work in progress.
--
Date: Fri Aug 27 11:44:52 2004
References: <Pine.LNX.4.61.0408262210260.7459@node2.an-vo.com>
Message-ID: <412F7992.5030802@us.ibm.com>
>
> I have a few questions about Xorg development policies that I could not
> find an easy answer to on the web, could some of the developer please
> comment ? - Thank you !
>
> * What is the procedure for submitting patches to Xorg tree ?
Either send them to the mailing list or submit a bugzilla with the patch
as an attachment. I think the later is better for larger patches, esp.
when a release is close.
> * Is it possible/what is required to obtain CVS access ?
> (Specifically for GATOS TV-in/TV-out enhancements to ATI cards
> drivers)
Like with most open-source projects: prove your worth, then ask. :)
> * Is there a particular person maintaining
> xc/programs/Xserver/hw/xfree86/drivers/ati
I /think/ either Egbert Eich or Hui Yu. I'm not 100% sure. I suppose
that's one thing that the various drivers could really use. Each driver
should clearly list the maintainer (if there is one) in the header of
the *_driver.c file. This is, of course, above and beyond listing the
authors.
Date: Fri Aug 27 11:51:15 2004
In-Reply-To: <412F7992.5030802@us.ibm.com>
<412F7992.5030802@us.ibm.com>
Message-ID: <a728f9f90408271151245f935@mail.gmail.com>
On Fri, 27 Aug 2004 11:12:34 -0700, Ian Romanick <idr@us.ibm.com> wrote:
>
> >
> > I have a few questions about Xorg development policies that I could not
> > find an easy answer to on the web, could some of the developer please
> > comment ? - Thank you !
> >
> > * What is the procedure for submitting patches to Xorg tree ?
>
> Either send them to the mailing list or submit a bugzilla with the patch
> as an attachment. I think the later is better for larger patches, esp.
> when a release is close.
>
> > * Is it possible/what is required to obtain CVS access ?
> > (Specifically for GATOS TV-in/TV-out enhancements to ATI cards
> > drivers)
>
> Like with most open-source projects: prove your worth, then ask. :)
>
> > * Is there a particular person maintaining
> > xc/programs/Xserver/hw/xfree86/drivers/ati
>
> I /think/ either Egbert Eich or Hui Yu. I'm not 100% sure. I suppose
> that's one thing that the various drivers could really use. Each driver
> should clearly list the maintainer (if there is one) in the header of
> the *_driver.c file. This is, of course, above and beyond listing the
> authors.
>
Kevin E. Martin was the xfree86 radeon maintainer, however, so many
people work on the radeon driver nowadays, it doesn't really have an
"official maintainer...I guess none of the drivers do.
Alex
From ajax at nwnk.net Fri Aug 27 11:36:47 2004
Date: Fri Aug 27 11:58:49 2004
In-Reply-To: <412F7992.5030802@us.ibm.com>
<412F7992.5030802@us.ibm.com>
Hash: SHA1
On Friday 27 August 2004 14:12, Ian Romanick wrote:
> > * Is it possible/what is required to obtain CVS access ?
> > (Specifically for GATOS TV-in/TV-out enhancements to ATI cards
> > drivers)
>
> Like with most open-source projects: prove your worth, then ask. :)
Since Vladimir's name is all over the GATOS stuff I think we can skip straight
to step 2. Any objections?
- - ajax
iD8DBQFBL38/W4otUKDs0NMRAiZkAKCCc7Z7QmXmD+SgABeUQvnL7UVsEQCffJ8u
9/bd+gcR/ED56y4jLsWdzwE=
=5LER
Date: Fri Aug 27 12:08:12 2004
<412F7992.5030802@us.ibm.com> <200408271436.58781.ajax@nwnk.net>
Message-ID: <a728f9f904082712081be43e4c@mail.gmail.com>
On Fri, 27 Aug 2004 14:36:47 -0400, Adam Jackson <ajax@nwnk.net> wrote:
> Hash: SHA1
>
> On Friday 27 August 2004 14:12, Ian Romanick wrote:
> > Vladimir Dergachev wrote:
> > > * Is it possible/what is required to obtain CVS access ?
> > > (Specifically for GATOS TV-in/TV-out enhancements to ATI cards
> > > drivers)
> >
> > Like with most open-source projects: prove your worth, then ask. :)
>
> Since Vladimir's name is all over the GATOS stuff I think we can skip straight
> to step 2. Any objections?
none here.
Alex
>
> - - ajax
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBL38/W4otUKDs0NMRAiZkAKCCc7Z7QmXmD+SgABeUQvnL7UVsEQCffJ8u
> 9/bd+gcR/ED56y4jLsWdzwE=
> =5LER
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> xorg mailing list
>
From matthieu.herrb at laas.fr Fri Aug 27 12:09:27 2004
Date: Fri Aug 27 12:11:42 2004
Subject: [Xorg] OpenBSD/i386 test report
Message-ID: <200408271909.i7RJ9RhC027858@cortez.herrb.com>
Name: Matthieu Herrb
OS: OpenBSD 3.6
Architecture: IA32
Version: CVS HEAD as of Aug 26
A. build.
- empty host.def
build - OK
install - OK
- BuildServersOnly YES
- DoLoadableServer NO
build - OK
install - OK
B. Run
OK as far as I can see (via driver) without composite extension.
With composite extension:
OK with and without xcompmgr on a via chipset at depth 24
problems (artefacts) both with and without xcompmgr on a neomagic chipset
at depth 16.
C. Conformance
Need to edit xsuite/xtest/tetbuild.cfg -> XP_DEFINES= -DUNIXCONN -DCSRG_BASED
to build the test suite, and fix the >& in xreg to run it...
This is for 24+32 bpp, but it's the same at all depths:
--- /local/xorg/test/results/tmp.11724 Thu Aug 26 23:44:56 2004
+++ /local/xorg/test/results/xtest.8bpp.20040826.231121.summary Thu Aug 26 23:44
:56 2004
@@ -6,9 +6,11 @@
+Tests for XLoadFont: Test 1: FAIL
Tests for XLoadQueryFont: Test 1: FAIL
+Tests for XSync: Test 2: FAIL
Date: Fri Aug 27 13:03:37 2004
<412F7992.5030802@us.ibm.com> <200408271436.58781.ajax@nwnk.net>
Message-ID: <412F8736.9020804@us.ibm.com>
Adam Jackson wrote:
> On Friday 27 August 2004 14:12, Ian Romanick wrote:
>>Vladimir Dergachev wrote:
>>
>>> * Is it possible/what is required to obtain CVS access ?
>>> (Specifically for GATOS TV-in/TV-out enhancements to ATI cards
>>> drivers)
>>
>>Like with most open-source projects: prove your worth, then ask. :)
>
> Since Vladimir's name is all over the GATOS stuff I think we can skip straight

> to step 2. Any objections?
I have none.
Date: Fri Aug 27 13:13:12 2004
Subject: [Xorg] OpenBSD/amd64 test report
Message-ID: <200408272013.i7RKD5SN004081@cortez.herrb.com>
Name: Matthieu Herrb
OS: OpenBSD 3.6
Architecture: AMD64
Version: CVS HEAD as of Aug 26
A. build.
DoLoadableServer is always NO.
- empty host.def
build - OK
install - OK
- BuildServersOnly YES
build - OK
install - fails, because mkfontscale is not built.
B. Run
OK as far as I can see (nv driver) without composite extension.
With composite extension:
OK with and without xcompmgr on a via chipset at depth 24
problems (artefacts) with compmgr running, OK without.
C. Conformance
Need to edit xsuite/xtest/tetbuild.cfg -> XP_DEFINES= -DUNIXCONN -DCSRG_BASED
to build the test suite, and fix the >& in xreg to run it...
results for 24+32bpp, same at other depths:
--- /local/build/xtest/results/tmp.30908 Fri Aug 27 21:36:07 2004
+++ /local/build/xtest/results/xtest.24+32bpp.20040827.211356.summary Fri Aug
27 21:36:07 2004
@@ -1,14 +1,4 @@
-Tests for XDrawArc: Test 42: FAIL
-Tests for XDrawArcs: Test 45: FAIL
-Tests for XLoadQueryFont: Test 1: FAIL
-Tests for XListFontsWithInfo: Test 3: FAIL
-Tests for XListFontsWithInfo: Test 4: FAIL
+Tests for XMinCmapsOfScreen: Test 1: FAIL
+Tests for MinCmapsOfScreen: Test 1: FAIL
+Tests for XChangeWindowAttributes: Test 3: FAIL
+Tests for XSetWindowBackground: Test 2: FAIL
From hiryu at audioseek.net Fri Aug 27 14:31:27 2004
Date: Fri Aug 27 14:18:38 2004
Subject: [Xorg] xcompmgr and Gnome
Hello,
In Gnome, at least for Linux and FreeBSD, starting xcompmgr makes it so
windows can be placed over the menu on the top of the desktop and the
taskbar (the bar at the bottom of the gnome desktop). Where as before
starting xcompmgr this cannot and does not occur. Maximizing windows
takes up the whole screen rather than the maximized window being between
the 2 bars which is how it's meant to work.
Quitting xcompmgr does not fix the problem. The Xorg xserver must be
restarted.
I was also unable to rename desktop icons on Gnome. I would select
rename and the icon text would be highlighted, but the text would only
enter into a gaim window no matter how much I selected and reselected
the icon on my desktop. Quitting xcompmgr did fix this problem.
Under KDE, windows still respect the taskbar at the bottom of the
screen. Don't know about desktop icons in KDE (yet).
Should this be entered into bugzilla?
Thanks.
-Cameron
Date: Fri Aug 27 15:09:03 2004
Subject: [Xorg] about the XorgReleaseStatus page
Message-ID: <412FB0FB.3000708@laas.fr>
Hi,
<http://wiki.freedesktop.org/XOrg/XorgReleaseStatus> tells several times
to mail to release-wranglers@freedesktop.org. But messages from
non-members of this list are rejected, making this request useless.
So I've posted my test results to xorg@ instead.
Date: Fri Aug 27 15:28:45 2004
In-Reply-To: <412FB0FB.3000708@laas.fr>
References: <412FB0FB.3000708@laas.fr>
On Sat, Aug 28, 2004 at 12:08:59AM +0200, Matthieu Herrb wrote:
> Hi,
>
> <http://wiki.freedesktop.org/XOrg/XorgReleaseStatus> tells several times
> to mail to release-wranglers@freedesktop.org. But messages from
> non-members of this list are rejected, making this request useless.
> So I've posted my test results to xorg@ instead.
I've made the change to the XorgReleaseStatus page to e-mail the
xorg@fdo list instead.
Also, I added a note about the xreg script and xtest tarball being
updated. For those running xtest, these fix some of the test failures,
and I would recommend that updating to them. I will send a more
complete note about these changes later today.
Thanks,
Kevin
Date: Fri Aug 27 16:46:58 2004
References: <412FB0FB.3000708@laas.fr> <20040827222839.GA11220@kem.org>
Message-ID: <1093650055.2851.24.camel@abbey>
On Fri, 2004-08-27 at 15:28, Kevin E Martin wrote:
> On Sat, Aug 28, 2004 at 12:08:59AM +0200, Matthieu Herrb wrote:
> > Hi,
> >
> > <http://wiki.freedesktop.org/XOrg/XorgReleaseStatus> tells several times
> > to mail to release-wranglers@freedesktop.org. But messages from
> > non-members of this list are rejected, making this request useless.
> > So I've posted my test results to xorg@ instead.
>
> I've made the change to the XorgReleaseStatus page to e-mail the
> xorg@fdo list instead.
>
> Also, I added a note about the xreg script and xtest tarball being
> updated. For those running xtest, these fix some of the test failures,
> and I would recommend that updating to them. I will send a more
> complete note about these changes later today.
Also, if you have composite enabled and are using xreg, be sure to set
the XLIB_SKIP_ARGB_VISUALS=1 in your environment. Otherwise, the extra
visual will confuse xtest.
From Khurram at mailextreme.com Fri Aug 27 16:41:06 2004
From: Khurram at mailextreme.com (Khurram Ahmed)
Date: Fri Aug 27 17:13:43 2004
Subject: [Xorg] Xp Extension: could not find config dir error.
Message-ID: <20040827234106.D46837267@sitemail.everyone.net>
I installed X.org over XFree86 by following the directions here:
I got everything to work, but i do, however get a error when booting up. From /
var/log/messages:

Aug 27 09:58:18 debian Xprt_33: Xp Extension: could not find config dir /usr/X11
R6/lib/X11/xserver/C/print
What does that mean, as it is now, i do not have a C/p
rint directory? I did remove xprt than did apt-get install xprt again, but that
doesnt seem to help.
Any way to fix this?
Thanks,
using X -version:
Build Operating System: Linux 2.6.8.1 i686 [ELF]
Current Operating System: Linux debian unstable/Sid 2.6.8.1 #1 Sat Aug 14 12:04:
54 EDT 2004 i686
Date: Fri Aug 27 21:24:31 2004
In-Reply-To: <20040820183730.GK2173@async.com.br>
On Fri, 20 Aug 2004, Christian Robottom Reis wrote:
> > > Can you quantify how much time it took to run, and what sort of hardware
> > > you're running it on?
> >
> > Sure, I'll get a more detailed time report and machine summary tonight
> > or tomorrow. Like I mentioned it seemed to take less than a few minutes
> > - I started it, went for coffee, and it was done when I got back. This
> > is on a 3GHz P4 with 512k cache, 1G memory, and ATI Radeon R350.
>
> Did you manage to pick up these timings?
{bryce@blackwold} ~/src/rendercheck (57): date; time ./rendercheck > test.out;
date
Fri Aug 27 21:08:45 PDT 2004
5.979u 8.187s 1:15.48 18.7% 0+0k 0+0io 0pf+0w
Fri Aug 27 21:10:01 PDT 2004
product: Dimension XPS Gen 2
vendor: Dell Computer Corporation
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
cache size : 512 KB
bogomips : 5914.62
MemTotal: 903268 kB
MemFree: 165816 kB
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800
]
01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon 9800] (Seco
ndary)
Monitor: SONY SDM-S91
Bryce
Date: Fri Aug 27 23:25:27 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 7
Added yesterday: 7
-----------------------------
- A configuration option was added to disable the hard failure, which
is off by default
- Needs testing by those experiencing problem
* Bug #1109: ATI Rage Mobility on Dell Insprion 7500 fails to display anything
- New fix provided
- Keith Packard needs to review patch
- Patch provided
* Bug #1203: Multiple definitions of XdmcpWrap
- Not a problem on IA32
- Needs verification and/or further explanation
* Bug #1204: Xvfb fails XDrawText and XDrawText16
- Xvfb fails the X Test Suite on these tests
- Needs investigation
* Bug #1210: GL contexts are sometimes not displayed with XDarwin's AGL
* Bug #1212: dllloader will not work when LD_BIND_NOW=1
- Fix provided for workaround
- Needs review
* Bug #1213: make install fails with BuildServersOnly YES
- Patch provided
Date: Sat Aug 28 04:08:36 2004
Subject: [Xorg] ZPixmap format
X Server support XYPixmap or ZFormat to represent images. when using 16
bits Depth how RGB data is represented in 2 Byte?
is it like 0rrrrrgggggbbbbb?
may be this question is out of scope of this list, sorry!
-Amir
Date: Sat Aug 28 08:53:44 2004
Subject: [Xorg] Release update and new release candidate tagged
On yesterday's releases wranglers call, the release date was set for
next Tuesday, 31 August 2004. We are actively working to resolve the
remaining issues and will discuss the updated status on Monday.
Toward that goal, the X.Org CVS tree has been tagged for the third
release candidate. If you are building test packages, please build them
against the XORG-6_7_99_903 tag and reply to this mailing list with the
location of your packages.
The test matrix on the status page has been updated with last week's
test results. If there are any test results that I have missed, please
let me know. The test matrix can be found here:
On that page are instructions for running the build, install, run and
conformance tests. We would like to fill in as much of this test matrix
as possible before the release next week. There has been much more
testing during the past week, and we very much appreciate your help.
Several additional notes regarding the release:
1. The xreg script and xtest.tar.gz tarball have been updated to fix
several of the test suite failures. Please get these updated tools
from the same place as before (see the instructions on "Setting up
the X test suite" on the release status page above for downloading,
building and using these tools).
2. There are several platforms that have not been tested, so we do not
know if the release still builds or runs on them. If there are
people with those platforms available, we ask that you test this
release candidate to make sure that it builds and runs. We can still
accept small patches that update support for those platforms (e.g.,
cf or tmpl file changes).
3. As we are in the final stages of the release, we need to make sure
that all of the documentation has been updated for this release.
This includes any release notes, man page, etc. If you have any
updates, please send in patches as soon as possible.
Thank you all for your help with this release!
From fxkuehl at gmx.de Sat Aug 28 12:23:31 2004
Date: Sat Aug 28 12:21:21 2004
Subject: [Xorg] Worried about the Savage 2D driver status
Message-ID: <20040828212331.270de192.felix@trabant>
Hi,
I wonder what's the status of the savage driver in Xorg CVS. The
directory contains some files that seem to indicate that the driver has
DRI support, but it's not working. Also the driver has a strange
mode-setting problem on my Savage4 that I last saw with a code drop from
S3/Via. I know that Tim Robert's drivers has lots of quirks for strange
hardware that were partially missing in the S3/Via code drop and the
code drop had more problems on some hardware. Therefore we decided to
base DRI support in DRI CVS on Tim Robert's 2D driver. Alex Deucher
integrated code from the S3/Via code drop for DRI support and improved
Xv support. This approach got rid of the mode setting problem mentioned
above and fixed other problems as well. Seeing that bug again in current
Xorg CVS makes me worried about the stability and compatibility of the
code. Can someone fill me in on the history of the Savage driver in Xorg
CVS and maybe dispel my concerns?
Best regards,
Felix
From rayl at mail.com Sat Aug 28 12:45:48 2004
Date: Sat Aug 28 12:45:56 2004
Subject: [Xorg] cvs warning on checkout
hi all
fyi, i get a (seemingly harmless) warning when i check out xc:
# cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg co -r XORG-6_7_99_903 x
c
cvs checkout: warning: cannot open /cvs/xorg/CVSROOT/val-tags read/write: Permis
sion denied
cvs checkout: Updating xc
U xc/BUILD
....
i'm using Concurrent Versions System (CVS) 1.11.14 (client/server) on
SuSE 9.1
cheers
--
----------------------------------------------------------------------
From rene at rocklinux-consulting.de Sat Aug 28 15:14:09 2004
Date: Sat Aug 28 15:14:34 2004
Subject: [Xorg] CVS HEAD ok on PowerPC and UltraSPARC Linux
Message-ID: <413103B1.8000202@rocklinux-consulting.de>
Hi,
just a quick note (not a full conformance test run), that X.Org HEAD
runs well on PowerPC and UltraSPARC Linux (both yet unreleased ROCK
Linux forks). Since Eric Anholt's Bug #1101 PaintWindow I also do not
yet had any screen corruptions anymore.
PowerPC:
G3, iBook2, Ati/Radeon Mobility M7 LW, Linux 2.6.8.1, gcc-3.2.3
XRender ok, Xv: ok, dri: ok, MergedFB: ok
SPARC:
Ultra5, Ati/Mach64, Linux 2.6.3 (with custom PCI fix), gcc-3.2.3
(32bit user-land)
XV: ok, dri: not yet played with
Thanks for the great work and have fun,
Ren? Rebe
Date: Sat Aug 28 16:30:34 2004
Subject: [Xorg] 903 results for suse 9.1
hi all
results for "install tests, number 2" hosts.def file:
1. Ray Lehtiniemi
2. Sat Aug 28 16:22:01 MDT 2004
4. XORG-6_7_99_903
5. passed
6. passed
7. in progress, see below
8. untested
for the build test, i get a lot of compile warnings, but no
errors. are any warnings particularly significant that i should
be looking for?
the -O option seems to be busted on the new xreg? if i run this:
# ./xreg -projroot /tmp/XorgTEST -display :2 -xtest -xvfb -O results-903-xvfb
i get this:
./xreg: line 1904: results-903-xvfb/xtest.8bpp.20040828.170048.report: No such f
ile or directory
and the test fails soon after. same problem on lines 433 and 2050.
if i omit the -O option, the test proceeds fine using the default
'results' directory.
i am now running the xvfb tests and will post summary file in a
few hours.
i also managed to get the xorg server running. after installation
as a normal user, i had to:
# chown -R root.root /tmp/XorgTEST
# chmod 4755 /tmp/XorgTEST/bin/Xorg
then i edited my /etc/X11/XF86Config to use "kbd" instead of
"Keyboard", and it seems i'm up and running.
i am now running the xorg tests and will post summary file in a
few hours as well.
is there any need to worry about these?
(EE) Failed to load module "speedo" (module does not exist, 0)
(EE) MGA: Failed to load module "mga_hal" (module does not exist, 0)
thanks
--
----------------------------------------------------------------------
From ajax at nwnk.net Sat Aug 28 16:51:27 2004
Date: Sat Aug 28 16:51:39 2004
Hash: SHA1
On Saturday 28 August 2004 19:30, Ray Lehtiniemi wrote:
> is there any need to worry about these?
>
> (EE) Failed to load module "speedo" (module does not exist, 0)
Only if you care about Speedo fonts (you probably don't).
> (EE) MGA: Failed to load module "mga_hal" (module does not exist, 0)
Only if you want TV out on MGA cards to work. You should be able to copy the
mga_hal module from your existing X installation over.
- - ajax
iD8DBQFBMRp/W4otUKDs0NMRAuy8AJ4u76An0SS578QvfIjRsdfmodqWtwCfdvx8
3sA6vABY/7BmXFsD7gUeAjo=
=NaUv
Date: Sat Aug 28 16:52:51 2004
Subject: [Xorg] dummy driver for testing?
Message-ID: <20040828235248.GB11810@mail.com>
hi
is there some way to prevent the desktops switching while running
xreg on the xorg server?
my desktop flashes back and forth between F7 and F8 screens, especially
at the start of the test run. this happens with both the mga driver and
the dummy driver... the only difference is that the mga driver
actually shows a valid-looking X session on F8 while the test runs,
while the dummy driver shows a bunch of garbage...
is there a reason to use the dumy driver, or can i just use the
normal mga driver while running the tests?
thanks
--
----------------------------------------------------------------------
Date: Sat Aug 28 20:36:11 2004
Message-ID: <20040829033605.GC11810@mail.com>
On Sat, Aug 28, 2004 at 05:30:29PM -0600, Ray Lehtiniemi wrote:
>
> results for "install tests, number 2" hosts.def file:
>
> 1. Ray Lehtiniemi
> 2. Sat Aug 28 16:22:01 MDT 2004
> 4. XORG-6_7_99_903
> 5. passed
> 6. passed
> 7. mixed results...
> 8. untested
>
> i am now running the xvfb tests and will post summary file in a
> few hours.
i've attached the summary files to this email.
> i am now running the xorg tests and will post summary file in a
> few hours as well.
my xorg server hung right away, and the test did not complete. i did
not use the dummy driver, but rather the mga driver. maybe this was
the cause?
here's the output of xreg:
y:/opt/xorg/testing-xorg> ./xreg -projroot /tmp/XorgTEST -display :3 -xtest -xor
g
* Sat Aug 28 17:46:51 MDT 2004: Starting script
* Sat Aug 28 17:46:51 MDT 2004: XSERVER=/tmp/XorgTEST/bin/Xorg
* Sat Aug 28 17:46:51 MDT 2004: HOST=ray
* Sat Aug 28 17:46:51 MDT 2004: DEPTHS=8 15 16 24+32
* Sat Aug 28 17:46:51 MDT 2004: 8bpp.20040828.174651
* Sat Aug 28 17:46:51 MDT 2004: Getting parameters from X server
* Sat Aug 28 17:46:51 MDT 2004: Starting X: parameters
* Sat Aug 28 17:46:51 MDT 2004: Start X server with :3 -depth 8 -kb
* Sat Aug 28 17:47:01 MDT 2004: PID=2653
* Sat Aug 28 17:47:01 MDT 2004: Stopping X: (00:00:10)
* Sat Aug 28 17:47:02 MDT 2004: -s "The X.Org Foundation" -r 60799903 -w 361 -h
271
* Sat Aug 28 17:47:02 MDT 2004: Configuration in /tmp/xreg.tetexec.cfg.2630
[2]+ Terminated xlogo
* Sat Aug 28 17:47:02 MDT 2004: Default /tmp/xreg.link_scen.2630
* Sat Aug 28 17:47:02 MDT 2004: Starting X: depth = 8 xtest
* Sat Aug 28 17:47:02 MDT 2004: Start X server with :3 -depth 8 -kb
* Sat Aug 28 17:47:12 MDT 2004: PID=2702
journal file name is: /opt/xorg/testing-xorg/results/xtest.8bpp.20040828.174651.
results/journal
the last line in the journal file is:
10|7 /tset/CH02/clsdsply/clsdsply 17:47:27|TC Start, scenario ref 43-1, ICs {all
}
and here's the process tree:
rayl 11843 0.1 3.2 29536 16576 ? S 16:36 0:19 \_ kdeinit: kons
ole
rayl 11844 0.0 0.3 3860 1748 pts/2 Ss 16:36 0:00 | \_ /bin/bash
rayl 2630 0.0 0.3 4108 1668 pts/2 S+ 17:49 0:00 | \_ /bin/
sh ./xreg -projroot /tmp/XorgTEST -display :3 -xtest -xorg
root 2702 0.0 2.0 37076 10472 ? S 17:49 0:10 | \_ /
tmp/XorgTEST/bin/Xorg :3 -ac -s 0 -depth 8 -kb
rayl 2712 0.0 0.1 2572 740 pts/2 S+ 17:49 0:00 | \_ t
cc -e -s /tmp/xreg.link_scen.2630 -x /tmp/xreg.tetexec.cfg.2630 -i /opt/xorg/t
rayl 2784 0.0 0.2 2748 1076 pts/2 S+ 17:49 0:00 |
\_ /tmp/2712a/clsdsply/clsdsply all
i hit ctrl-c to kill it, my display started flashing between consoles
on F7 and F8, and eventually hung up again with this line in the journal:
10|42 /tset/CH02/opndsply/opndsply 21:32:38|TC Start, scenario ref 78-1, ICs {al
l}
any idea what i'm doing wrong?
thanks
--
----------------------------------------------------------------------
-------------- next part --------------
Tests for XDisplayString: Test 1: FAIL
Tests for XOpenDisplay: Test 3: FAIL
Tests for DisplayString: Test 1: FAIL
Tests for XDrawArc: Test 42: FAIL
Tests for XDrawText: Test 1: FAIL
Tests for XDrawText16: Test 1: FAIL
Tests for XSync: Test 2: FAIL
--- /opt/xorg/testing/results/tmp.27195 2004-08-28 17:44:03.399444273 -0600
+++ /opt/xorg/testing/results/xtest.8bpp.20040828.170151.summary 2004-08-
28 17:44:03.381449756 -0600
@@ -1,3 +1,10 @@
+Tests for XDisplayString: Test 1: FAIL
+Tests for XOpenDisplay: Test 3: FAIL
+Tests for DisplayString: Test 1: FAIL
@@ -6,4 +13,44 @@
+Tests for XDrawText: Test 1: FAIL
+Tests for XDrawText16: Test 1: FAIL
DEPTH=8
XSERVER=/tmp/XorgTEST/bin/Xvfb
-------------- next part --------------
28 18:22:07.952151849 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,44 @@
DEPTH=15
-------------- next part --------------
28 18:59:59.074596502 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,44 @@
DEPTH=16
-------------- next part --------------
+++ /opt/xorg/testing/results/xtest.24+32bpp.20040828.170151.summary 2004-08-
28 19:38:29.556970954 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,44 @@
DEPTH=24+32
Date: Sat Aug 28 22:11:13 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 0
Added yesterday: 1
-----------------------------
is off by default
- New fix provided
- Keith Packard needs to review patch
- Patch provided
* Bug #1195: I810 DRI failed
- Patch for ARGB cursors supplied
* Bug #1212: dllloader will not work when LD_BIND_NOW=1
- Fix provided for workaround
- Needs review
- Patch provided
- Needs review
From yernst at ndsisrael.com Sun Aug 29 01:09:47 2004
From: yernst at ndsisrael.com (Ernst, Yehuda)
Date: Sun Aug 29 01:11:03 2004
Subject: [Xorg] (no subject)
Message-ID: <31058754212B50469824909BE90A4CFBB6BD30@ILEX2.IL.NDS.COM>
unsubscribe
From nik at varna.net Sun Aug 29 02:34:21 2004
From: nik at varna.net (Nikolay Datchev)
Date: Sun Aug 29 02:41:25 2004
Subject: Problems with S3 Trio 64 V2/DX and Xorg 6.7.0
Message-ID: <Pine.LNX.4.33.0408291227330.15492-200000@ns1.varna.net>
Hi all,
I am trying to configure my Xorg 6.7.0 (slackware-current) with my video
card - S3 Trio 64 V2/DX. It works only with "vesa" and "vga" drivers, but
not with the "s3" driver. It seems that this driver even don't have a
manual page. When i try to use "s3", i get unreadable screen, but the
monitor is in proper mode (800x600@75Hz).
I've been used this card with older Xfree86 version and the s3 driver with
no problems.
My Xorg.0.log is attached
Thanks in advance.
-- Nikolay Datchev
-------------- next part --------------
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/zita:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
Build Operating System: Linux 2.4.26 i686 [ELF]
Current Operating System: Linux zita 2.4.26 #3 ?? ??? 28 21:20:51 EEST 2004 i586
Build Date: 28 April 2004
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 29 12:09:43 2004
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen 1" (0)
(**) | |-->Monitor "CTX"
(**) | |-->Device "S3"
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard1"
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) XKB: rules: "xorg"
(**) Option "XkbModel" "pc101"
(**) XKB: model: "pc101"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/local/".
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/local/").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi/".
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi/").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi/".
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi/").
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75
dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/
usr/X11R6/lib/X11/fonts/75dpi/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(WW) Open APM failed (/dev/apm_bios) (No such device)
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.2
X.Org Video Driver: 0.7
X.Org XInput driver : 0.4
X.Org Server Extension : 0.2
X.Org Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
(++) using VT number 7
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1039,5597 card 0000,0000 rev 02 class 06,00,00 hdr 00
(II) PCI: 00:01:1: chip 1039,5513 card 0000,0000 rev d0 class 01,01,8a hdr 80
(II) PCI: 00:0b:0: chip 8086,1229 card 1014,305c rev 08 class 02,00,00 hdr 00
(II) PCI: 00:0d:0: chip 1274,1371 card 1274,1371 rev 06 class 04,01,00 hdr 00
(II) PCI: End of PCI scan
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:1:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI:*(0:17:0) S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] rev 22, Mem @ 0xe
0000000/26
(II) Addressable bus resource ranges are
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
[0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B)
[1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) Active PCI resource ranges:
[0] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[1] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[2] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[3] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[4] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[5] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[6] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[7] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[8] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[9] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[1] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[3] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[4] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[5] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[6] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[7] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[8] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[9] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[6] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[10] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[11] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[12] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[13] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[14] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[15] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[16] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="X.Org Foundation"
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="X.Org Foundation"
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension DPMS
(II) Loading extension FontCache
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="X.Org Foundation"
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "speedo"
(II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a
(II) Module speedo: vendor="X.Org Foundation"
(II) Loading font Speedo
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
(II) Loading font FreeType
(II) LoadModule: "s3"
(II) Loading /usr/X11R6/lib/modules/drivers/s3_drv.o
(II) Module s3: vendor="X.Org Foundation"
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.4
(II) S3: driver (version 0.3.5 for S3 chipset: 964-0, 964-1, 968,
Trio32/64, Aurora64V+, Trio64UV+, Trio64V2/DX/GX
(II) Primary Device is: PCI 00:11:0
(--) Assigning device section with no busID to primary device
(--) Chipset Trio64V2/DX/GX found
(II) resource ranges after xf86ClaimFixedResources() call:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[6] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[10] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[11] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[12] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[13] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[14] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[15] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[16] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
(II) resource ranges after probing:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[6] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[14] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[15] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[16] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[17] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[18] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[19] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
[20] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[21] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="X.Org Foundation"
(II) s3(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(**) s3(0): Depth 16, (--) framebuffer bpp 16
(==) s3(0): RGB weight 565
(==) s3(0): Default visual is TrueColor
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
(II) s3(0): Primary V_BIOS segment is: 0xc000
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Loading /usr/X11R6/lib/modules/libvbe.a
(II) Module vbe: vendor="X.Org Foundation"
(II) s3(0): VESA BIOS detected
(II) s3(0): VESA VBE Version 1.2
(II) s3(0): VESA VBE Total Mem: 2048 kB
(II) s3(0): VESA VBE OEM: S3 Incorporated. 86C775/86C785
(==) s3(0): Using gamma correction (1.0, 1.0, 1.0)
(**) s3(0): Chipset: "Trio64V2/DX/GX"
(--) s3(0): Framebuffer @ 0xe0000000
(--) s3(0): MMIO @ 0xe1000000
(--) s3(0): videoRam = 2048 Kb
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="X.Org Foundation"
(--) s3(0): MCLK 50.114 Mhz
(--) s3(0): RefClock: 16000
(--) s3(0): Max pixel clock at this depth is 80 Mhz
(II) s3(0): CTX: Using hsync range of 31.50-48.50 kHz
(II) s3(0): CTX: Using vrefresh range of 50.00-100.00 Hz
(II) s3(0): Clock range: 15.60 to 80.00 MHz
(II) s3(0): Not using default mode "320x240" (bad mode clock/interlace/doublesca
n)
(II) s3(0): Not using default mode "800x600" (hsync out of range)
(II) s3(0): Not using default mode "1024x768" (bad mode clock/interlace/doublesc
an)
n)
an)
an)
(II) s3(0): Not using default mode "1280x960" (insufficient memory for mode)
n)
n)
n)
n)
n)
n)
n)
n)
n)
n)
n)
n)
an)
an)
an)
(II) s3(0): Not using default mode "1152x768" (width too large for virtual size)
(II) s3(0): Not using default mode "1024x768" (width too large for virtual size)
(--) s3(0): Virtual size is 800x600 (pitch 800)
(**) s3(0): *Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz
(II) s3(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync
+vsync
(**) s3(0): *Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz
(II) s3(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsync
-vsync
(**) s3(0): Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz
+vsync
+vsync
+vsync
-vsync
-vsync
-vsync
+vsync
+vsync
-vsync
(**) s3(0): Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D)
(II) s3(0): Modeline "576x384" 32.50 576 589 657 736 384 385 388 403 doubles
can +hsync +vsync
can -hsync -vsync
can +hsync +vsync
can +hsync +vsync
can +hsync +vsync
can +hsync +vsync
can -hsync -vsync
can -hsync -vsync
can -hsync -vsync
can -hsync +vsync
can -hsync +vsync
can +hsync -vsync
(==) s3(0): DPI set to (75, 75)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="X.Org Foundation"
ABI class: X.Org ANSI C Emulation, version 0.2
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="X.Org Foundation"
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] 0 0 0xe0000000 - 0xe3ffffff (0x4000000) MS[B]
[3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[6] -1 0 0xe4000000 - 0xe40fffff (0x100000) MX[B]
[7] -1 0 0xe4101000 - 0xe4101fff (0x1000) MX[B]
[9] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
[10] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
[11] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
[12] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[13] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[14] -1 0 0x00006400 - 0x0000643f (0x40) IX[B]
[15] -1 0 0x00006300 - 0x0000633f (0x40) IX[B]
[16] -1 0 0x00004000 - 0x0000400f (0x10) IX[B]
[17] -1 0 0x00000374 - 0x00000374 (0x1) IX[B]
[18] -1 0 0x00000170 - 0x00000170 (0x1) IX[B]
[19] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B]
[20] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
[21] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[22] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(==) s3(0): Write-combining range (0xe0000000,0x200000)
(==) s3(0): Backing store disabled
(II) s3(0): Using XFree86 Acceleration Architecture (XAA)
8x8 color pattern filled rectangles
CPU to Screen color expansion
Solid Lines
(II) s3(0): Acceleration enabled
(II) s3(0): Using NewMMIO
(II) s3(0): Using SW cursor
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(**) Option "Protocol" "PS/2"
(**) Mouse1: Device: "/dev/mouse"
(**) Mouse1: Protocol: "PS/2"
(**) Option "CorePointer"
(**) Mouse1: Core Pointer
(**) Option "Device" "/dev/mouse"
(**) Option "Emulate3Buttons"
(**) Mouse1: Emulate3Buttons, Emulate3Timeout: 50
(==) Mouse1: Buttons: 3
(II) Keyboard "Keyboard1" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
(II) Mouse1: ps2EnableDataReporting: succeeded
-------------- next part --------------
Scanned by evaluation version of Dr.Web antivirus Daemon
http://drweb.ru/unix/
From marcin.giedz at eulerhermes.pl Sun Aug 29 02:44:27 2004
From: marcin.giedz at eulerhermes.pl (Marcin Giedz)
Date: Sun Aug 29 03:28:38 2004
Subject: Matrox G550 and DualHead support.
Message-ID: <200408291144.27895.marcin.giedz@eulerhermes.pl>
Hello all,
My question is: is it possible without any drivers from matrox (specially
mga_hal.o) and with x.org from CVS run 2 independent screens (independent
resolution, rotation etc)? or I should use mga_hal.o and speciall option
passed to xorg.conf 0 like DigitalScreen = YES or something like that ;)
BR and many thanks
Marcin Giedz
From matthieu.herrb at laas.fr Sun Aug 29 04:39:41 2004
Date: Sun Aug 29 04:39:42 2004
In-Reply-To: <Pine.LNX.4.33.0408291227330.15492-200000@ns1.varna.net>
References: <Pine.LNX.4.33.0408291227330.15492-200000@ns1.varna.net>
Message-ID: <4131C07D.5000100@laas.fr>
Nikolay Datchev wrote:
> Hi all,
>
> I am trying to configure my Xorg 6.7.0 (slackware-current) with my video
> card - S3 Trio 64 V2/DX. It works only with "vesa" and "vga" drivers, but
> not with the "s3" driver. It seems that this driver even don't have a
> manual page. When i try to use "s3", i get unreadable screen, but the
> monitor is in proper mode (800x600@75Hz).
>
> I've been used this card with older Xfree86 version and the s3 driver with
> no problems.
Could you be more specific? Which XFree86 version word last with this
card? AFAIK no XFree86 4.x version has supported Trio64 cards correctly.
The 4.x s3 driver only supports some RAMDACS and it has had few support
in the past.
From crimofbai at web.de Sun Aug 29 07:05:19 2004
From: crimofbai at web.de (robert)
Date: Sun Aug 29 07:30:45 2004
Subject: Usage of Tilt Wheel?
Message-ID: <4131E29F.8080001@web.de>
Hi List,
I've got a MS Wireless Optical Mouse (yes, i know), that has got a tilt
Wheel. Thats a function of the Scroll Wheel to tilt it left and right to
scroll horizontal.
I like this functionality and of course I want to use it under Linux ;)
I posted to linuxquestions.org and one of the Users there made a small
patch for the hid driver that seems to work and produces some "crap"
when the wheel is tilted. The thread is there:
http://www.linuxquestions.org/questions/showthread.php?s=&threadid=186975
Could it be possible to creatve events that xev can read and some other
program work with (imwheel...) ?
As you maybe see I'm no developer, so any help is welcome =)
Thanks,
-Robert
Date: Sun Aug 29 07:49:58 2004
In-Reply-To: <200408291144.27895.marcin.giedz@eulerhermes.pl>
References: <200408291144.27895.marcin.giedz@eulerhermes.pl>
Message-ID: <a728f9f904082907491814ad60@mail.gmail.com>
On Sun, 29 Aug 2004 11:44:27 +0200, Marcin Giedz
<marcin.giedz@eulerhermes.pl> wrote:
> Hello all,
>
> My question is: is it possible without any drivers from matrox (specially
> mga_hal.o) and with x.org from CVS run 2 independent screens (independent
> resolution, rotation etc)? or I should use mga_hal.o and speciall option
> passed to xorg.conf 0 like DigitalScreen = YES or something like that ;)
You can run dualhead as long as both screens are crts. DVI, tv, and
mergedfb all require HAL.
Alex
>
> BR and many thanks
> Marcin Giedz
Date: Sun Aug 29 08:35:26 2004
Subject: c&t 65555 setup
Message-ID: <456601c48dde$04fa38a0$1e01a8c0@cnt496>
Setting up a compaq armada 1700 laptop - video is "Chips and Technologies
65555 - HiQV Pro, 2 meg frame buffer" - anyone know what the best way to config
this is?
Carl K
http://www.personnelware.com/carl/resume.html
Date: Sun Aug 29 08:42:58 2004
In-Reply-To: <456601c48dde$04fa38a0$1e01a8c0@cnt496>
References: <456601c48dde$04fa38a0$1e01a8c0@cnt496>
Message-ID: <a728f9f904082908424d6e648c@mail.gmail.com>
On Sun, 29 Aug 2004 10:36:57 -0500, Carl Karsten <carl@personnelware.com> wrote:
> Setting up a compaq armada 1700 laptop - video is "Chips and Technologies
> 65555 - HiQV Pro, 2 meg frame buffer" - anyone know what the best way to confi
g
> this is?
use the chips driver.
Alex
>
> Carl K
> http://www.personnelware.com/carl/resume.html
>
Date: Sun Aug 29 08:49:51 2004
Subject: [xorg] no longer added to subject
Message-ID: <458801c48ddf$5528fef0$1e01a8c0@cnt496>
Is this temporary, or do I need to update my mail rules?
Carl K
----- Original Message -----
From: "Carl Karsten" <carl@personnelware.com>
To: <xorg@freedesktop.org>
Sent: Sunday, August 29, 2004 10:36 AM
> Setting up a compaq armada 1700 laptop - video is "Chips and Technologies
> 65555 - HiQV Pro, 2 meg frame buffer" - anyone know what the best way to
config
> this is?
>
> Carl K
> http://www.personnelware.com/carl/resume.html
>
> _______________________________________________
> xorg mailing list
>
Date: Sun Aug 29 10:17:33 2004
Subject: [xorg] no longer added to subject
In-Reply-To: <458801c48ddf$5528fef0$1e01a8c0@cnt496>
<458801c48ddf$5528fef0$1e01a8c0@cnt496>
Carl Karsten wrote:
> Is this temporary, or do I need to update my mail rules?
Never use Subject as a filter rule. You'll have better results using List-Id.
List-Id: Discuss issues related to the xorg tree <xorg.freedesktop.org>
So your filter rule will test:
if List-Id has xorg.freedesktop.org; then
file into inbox.xorg
Or something like that.
Regards,
Norberto
From marcin.giedz at eulerhermes.pl Sun Aug 29 10:39:05 2004
From: marcin.giedz at eulerhermes.pl (Marcin Giedz)
Date: Sun Aug 29 10:59:18 2004
In-Reply-To: <a728f9f904082907491814ad60@mail.gmail.com>
<a728f9f904082907491814ad60@mail.gmail.com>
Message-ID: <200408291939.05133.marcin.giedz@eulerhermes.pl>
> > My question is: is it possible without any drivers from matrox (specially
> > mga_hal.o) and with x.org from CVS run 2 independent screens (independent
> > resolution, rotation etc)? or I should use mga_hal.o and speciall option
> > passed to xorg.conf 0 like DigitalScreen = YES or something like that ;)
>
> You can run dualhead as long as both screens are crts. DVI, tv, and
> mergedfb all require HAL.
Ok Thanks so much ;)
But another question. I have downloaded beta source and binary drivers from
matrox. Binary are compiled only for XFree4.3 and source hmmm I simply can't
find how to compile it. Can I use binary from XFree4.3 with X.org compiled
from CVS or is it possible to compile drivers and how can I do it?
Marcin
From nemesis-lists at icequake.net Sun Aug 29 13:22:52 2004
From: nemesis-lists at icequake.net (Ryan Underwood)
Date: Sun Aug 29 13:22:56 2004
In-Reply-To: <200408291939.05133.marcin.giedz@eulerhermes.pl>
<200408291939.05133.marcin.giedz@eulerhermes.pl>
Message-ID: <20040829202251.GA8075@dbz.icequake.net>
On Sun, Aug 29, 2004 at 07:39:05PM +0200, Marcin Giedz wrote:
>
> But another question. I have downloaded beta source and binary drivers from
> matrox. Binary are compiled only for XFree4.3 and source hmmm I simply can't
> find how to compile it. Can I use binary from XFree4.3 with X.org compiled
> from CVS or is it possible to compile drivers and how can I do it?
You only need the mga_hal_drv.o from the matrox binary package. The
X.org driver should find and load it ok assuming it can be located
through one of your ModulePath directives.
--
Ryan Underwood, <nemesis@icequake.net>
-------------- next part --------------
Name: not available
Size: 189 bytes
ment.pgp
From tim at birdsnest.maths.tcd.ie Sun Aug 29 13:22:32 2004
Date: Sun Aug 29 14:26:15 2004
Subject: How to use fbdev ?
Someone suggested that I should try the fbdev driver
on my Sony C1VFK Picturebook instead of the ati driver,
but when I try that I get the error message:
"/dev/fb0: No such device"
although there are devices /dev/fb* created by
"dev/MAKEDEV -v fb"
creating eg
=====================================
[tim@william tim]$ ls -ls /dev/fb0
0 crw------- 1 root root 29, 0 Aug 29 04:32 /dev/fb0
=====================================
Where did I go wrong?
--
Timothy Murphy
tel: +353-86-2336090, +353-1-2842366
From rene at rocklinux-consulting.de Sun Aug 29 14:35:31 2004
Date: Sun Aug 29 14:36:08 2004
In-Reply-To: <200408292122.32971.tim@birdsnest.maths.tcd.ie>
References: <200408292122.32971.tim@birdsnest.maths.tcd.ie>
Message-ID: <41324C23.9000207@rocklinux-consulting.de>
Hi,
Timothy Murphy wrote:
> Someone suggested that I should try the fbdev driver
> on my Sony C1VFK Picturebook instead of the ati driver,
> but when I try that I get the error message:
> "/dev/fb0: No such device"
> although there are devices /dev/fb* created by
> "dev/MAKEDEV -v fb"
> creating eg
> =====================================
> [tim@william tim]$ ls -ls /dev/fb0
> 0 crw------- 1 root root 29, 0 Aug 29 04:32 /dev/fb0
> =====================================
>
> Where did I go wrong?
No framebuffer support in the kernel? Try recompile the kernel with ati
variants or the vesa one. You can also try the x vesa driver on the box
directly.
Ren?
Date: Sun Aug 29 14:45:13 2004
In-Reply-To: <20040829202251.GA8075@dbz.icequake.net>
<200408291939.05133.marcin.giedz@eulerhermes.pl>
<20040829202251.GA8075@dbz.icequake.net>
Message-ID: <a728f9f9040829144567145901@mail.gmail.com>
On Sun, 29 Aug 2004 15:22:52 -0500, Ryan Underwood
<nemesis-lists@icequake.net> wrote:
>
> On Sun, Aug 29, 2004 at 07:39:05PM +0200, Marcin Giedz wrote:
> >
> > But another question. I have downloaded beta source and binary drivers from
> > matrox. Binary are compiled only for XFree4.3 and source hmmm I simply can't
> > find how to compile it. Can I use binary from XFree4.3 with X.org compiled
> > from CVS or is it possible to compile drivers and how can I do it?
>
> You only need the mga_hal_drv.o from the matrox binary package. The
> X.org driver should find and load it ok assuming it can be located
> through one of your ModulePath directives.
You also may need to specify "use HAL" or some similar thing in you
host.def as I recall. I don't remeber what the default is.
Alex
>
> --
> Ryan Underwood, <nemesis@icequake.net>
>
>
From rene at rocklinux-consulting.de Sun Aug 29 15:23:47 2004
Date: Sun Aug 29 15:24:02 2004
Subject: various 903 results
Message-ID: <41325773.4050703@rocklinux-consulting.de>
Hi,
OS -- Linux
Arch -- PPC
Distro/Release -- T2
Name -- Ren? Rebe
Build -- 903
Build -- ok
Install -- ok
Conformance -- todo
Run -- ok
OS -- Linux
Arch -- SPARC
Name -- Ren? Rebe
Build -- 903
Build -- ok
Install -- ok
Conformance -- todo
Run -- ok
OS -- Linux
Arch -- IA-32
Name -- Ren? Rebe
Build -- 903
Build -- ok
Install -- ok
Conformance -- todo
Run -- ok
I plan to run conformance test, soon.
PS: T2 is a in-development ROCK Linux successor ...
Ren?
From rayl at mail.com Sun Aug 29 19:32:32 2004
Date: Sun Aug 29 19:32:43 2004
Subject: 903 xorg server test summaries for suse 9.1
hi all
results for "install tests, number 2" hosts.def file:
1. Ray Lehtiniemi
2. Sun Aug 29 03:22:01 MDT 2004
4. XORG-6_7_99_903
5. passed
6. passed
7. some failures
8. untested
no luck running tests with the dummy driver, it just hangs... i did
have good luck with the mga driver, and have attached the summary
files.
i started kde 3.2 on the xorg 903 server and ran x11perf, all tests.
seems like everything is working fine so far...
cheers
--
----------------------------------------------------------------------
-------------- next part --------------
Tests for XGetPointerMapping: Test 2: FAIL
Tests for XSetPointerMapping: Test 1: FAIL
--- /opt/xorg/testing-xorg/results/tmp.5818 2004-08-29 01:59:12.597189525 -0
600
+++ /opt/xorg/testing-xorg/results/xtest.8bpp.20040829.011112.summary 2004-08-
29 01:59:12.580194542 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,6 @@
+Tests for XGetPointerMapping: Test 2: FAIL
DEPTH=8
XSERVER=/tmp/XorgTEST/bin/Xorg
-------------- next part --------------
600
29 02:40:47.807287137 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,6 @@
DEPTH=15
-------------- next part --------------
600
29 03:22:28.857659526 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,6 @@
DEPTH=16
-------------- next part --------------
Tests for XFillRectangles: Test 25: FAIL
600
+++ /opt/xorg/testing-xorg/results/xtest.24+32bpp.20040829.011112.summary
2004-08-29 04:06:14.709347476 -0600
@@ -1,3 +1,10 @@
@@ -6,4 +13,7 @@
+Tests for XFillRectangles: Test 25: FAIL
DEPTH=24+32
From kem at freedesktop.org Sun Aug 29 20:39:04 2004
Date: Sun Aug 29 20:39:12 2004
Subject: Current blocker bug list
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 4
Added yesterday: 2
-----------------------------
is off by default
- Possible solution by building without damage for servers using
rootless layer
- Torrey Lyons is checking if this will work
- Patch provided
- Torry Lyons is finalizing a self-contained patch to aglGlx.c
- Patch to fix problem checked in
- Roland Mainz has proposed a different solution and will provide a
patch
From nik at varna.net Sun Aug 29 22:45:53 2004
From: nik at varna.net (Nikolay Datchev)
Date: Sun Aug 29 22:46:00 2004
In-Reply-To: <4131C07D.5000100@laas.fr>
Message-ID: <Pine.LNX.4.33.0408300840570.26200-100000@ns1.varna.net>
That's great :-(
The Xfree86 that worked was so old that i even cannot remember the version
(it was the time of slackware 7.1. So, this card is not supported anymore?
> Could you be more specific? Which XFree86 version word last with this
> card? AFAIK no XFree86 4.x version has supported Trio64 cards correctly.
> The 4.x s3 driver only supports some RAMDACS and it has had few support
> in the past.
> _______________________________________________
> xorg mailing list
>
From matthieu.herrb at laas.fr Sun Aug 29 23:04:20 2004
Date: Sun Aug 29 23:04:31 2004
Message-ID: <4132C364.50803@laas.fr>
Nikolay Datchev wrote:
> That's great :-(
>
> The Xfree86 that worked was so old that i even cannot remember the version
> (it was the time of slackware 7.1. So, this card is not supported anymore?
Unfortunatly, more or less yes. The XFree86 3.x XF86_S3 server is a
really complicated and obfuscated code maze. No one managed to port it
as is to the new design.
No developper has enough motiviation to really work on the new s3 driver
to add support to a wide range of legacy s3 boards.
This is why some Unix project still provide some the XFree86 3.3.6
servers in addition to XFree86 4.x based ones to support those old cards.
From mharris at www.linux.org.uk Sun Aug 29 22:09:46 2004
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Mon Aug 30 00:33:53 2004
Subject: 903 xorg server test summaries for suse 9.1
Message-ID: <4132B69A.2080300@www.linux.org.uk>
Ray Lehtiniemi wrote:
> hi all
>
> results for "install tests, number 2" hosts.def file:
>
> 1. Ray Lehtiniemi
> 2. Sun Aug 29 03:22:01 MDT 2004
> 4. XORG-6_7_99_903
> 5. passed
> 6. passed
> 7. some failures
> 8. untested
>
> no luck running tests with the dummy driver, it just hangs... i did
> have good luck with the mga driver, and have attached the summary
> files.
>
> i started kde 3.2 on the xorg 903 server and ran x11perf, all tests.
> seems like everything is working fine so far...
I get the same problem with the "dummy" driver on Fedora Core 2/i386
with the same Xorg release. My test results basically mirror yours.
I'll be submitting the full results tonight hopefully.
From tim at birdsnest.maths.tcd.ie Mon Aug 30 04:21:26 2004
Date: Mon Aug 30 04:24:55 2004
In-Reply-To: <41324C23.9000207@rocklinux-consulting.de>
References: <200408292122.32971.tim@birdsnest.maths.tcd.ie>
<41324C23.9000207@rocklinux-consulting.de>
On Sunday 29 August 2004 22:35, Ren? Rebe wrote:
> > Someone suggested that I should try the fbdev driver
> > on my Sony C1VFK Picturebook instead of the ati driver,
> > but when I try that I get the error message:
> > "/dev/fb0: No such device"
> > although there are devices /dev/fb* created by
> > "dev/MAKEDEV -v fb"
> > creating eg
> > =====================================
> > [tim@william tim]$ ls -ls /dev/fb0
> > 0 crw------- 1 root root 29, 0 Aug 29 04:32 /dev/fb0
> > =====================================
> >
> > Where did I go wrong?
>
> No framebuffer support in the kernel? Try recompile the kernel with ati
> variants or the vesa one. You can also try the x vesa driver on the box
> directly.
I think I included all relevant options when compiling linux-2.6.8.1 .
I noticed that the atyfb module was not loaded,
but modprob-ing it (and restarting X) made no difference;
I still get the error message
"/dev/fb0: no such device".
I googled a little for devfb material,
but what I found rather puzzling is that the latest versions
of fbutils and fbset seem to date from 1999.
(I've no objection to running old programs,
but am I missing something more recent?)
--
Timothy Murphy
tel: +353-86-2336090, +353-1-2842366
From biscani at pd.astro.it Mon Aug 30 05:47:06 2004
From: biscani at pd.astro.it (Francesco Biscani)
Date: Mon Aug 30 05:49:32 2004
Subject: RenderAccel on IGP?
Message-ID: <200408301447.06372.biscani@pd.astro.it>
Hi,
I read from the ChangeLog that Render acceleration has been implemented for
Radeon r100 and r200. Does this includes also Radeon IGP? If not, is it
planned for the future?
BTW, thanks for all the good work you are doing :)
Regards.
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Universit? di Padova
biscani@pd.astro.it
Date: Mon Aug 30 06:01:50 2004
In-Reply-To: <200408301447.06372.biscani@pd.astro.it>
References: <200408301447.06372.biscani@pd.astro.it>
Message-ID: <a728f9f904083006017af3ffb2@mail.gmail.com>
On Mon, 30 Aug 2004 14:47:06 +0200, Francesco Biscani
<biscani@pd.astro.it> wrote:
> Hi,
>
> I read from the ChangeLog that Render acceleration has been implemented for
> Radeon r100 and r200. Does this includes also Radeon IGP? If not, is it
> planned for the future?
IGP should work as well (they are basically slightly modified
r100/r200 cores w/o TCL).
Alex
>
> BTW, thanks for all the good work you are doing :)
>
> Regards.
>
> Francesco
>
> --
> Dr. Francesco Biscani
>
> Dipartimento di Astronomia
> Universit? di Padova
>
> biscani@pd.astro.it
Date: Mon Aug 30 06:05:30 2004
In-Reply-To: <a728f9f904083006017af3ffb2@mail.gmail.com>
<a728f9f904083006017af3ffb2@mail.gmail.com>
On Monday 30 August 2004 15:01, Alex Deucher wrote:
> IGP should work as well (they are basically slightly modified
> r100/r200 cores w/o TCL).
>
> Alex
Ok, thanks very much - that's good news :) Installing RC3 right now, will
report here if someone is interested.
Regards,
--
biscani@pd.astro.it
From ntt at control.uchicago.edu Mon Aug 30 06:54:15 2004
From: ntt at control.uchicago.edu (Nguyen The Toan)
Date: Mon Aug 30 07:02:10 2004
Subject: x.org and GTK+ 1.x progs
Message-ID: <200408300854.15612.ntt@control.uchicago.edu>
Hi,
I compile x.org cvs on my Suse 9.1 at home and get the error "gdk-ERROR:
BadMatch ..." (I'm not at home so I could not be more accurate) when I run
GTK+ 1.x applications such as xmms, vmware. They quit immediately after
printing out the errors. Does anyone know how to fix this?
Thanks,
Toan
From linux at cryos.net Mon Aug 30 07:04:41 2004
From: linux at cryos.net (Marcus D. Hanwell)
Date: Mon Aug 30 07:29:45 2004
Subject: 903 xorg, nVidia, TwinView and xcompmgr = corrupt display
Message-ID: <413333F9.1000408@cryos.net>
Hi,
First post to the list, so go easy. I have been using the new xorg
builds on Gentoo Linux for the last week or so (902 and then 903). I am
using the amd64 64 bit Gentoo Linux build, with the amd64 nvidia 6106
drivers. Everything is compiled 64 bit.
I am using an nVidia GeForce FX 5900XT 128MB graphics card with two 17"
TFT monitors and TwinView. TwinView works just fine with the new
xorg-6.7.99.902/903. I have enabled composite support in xorg.conf and
everything still works fine too. Using KDE 3.3, and fluxbox.
Unfortunately whenever I execute xcompmgr I get screen corruption of the
second screen, and about a third of the first screen. I can then click
on the Konsole where I launched xcompmgr, kill it and everything is fine
again.
I also recently discovered that I could also take a snapshot using
ksnapshot, and most of the screen corruption went. By triggering the
redraw event of the windows (dragging a window over corrupted areas of
the screen), I can get the rest back. I can use xcompmgr -cf and set
transparencies and get shadows.
Unfortunately in KDE if I change virtual desktops, and then go back to
the original with the transparent windows they are not redrawn. I have
to click over where the Konsole is, Ctrl+C and I get everything back.
All the problems seem to be related to redraw events not being called or
handled correctly - although I am no X expert!
The transparency looks great, but is quite unusable with TwinView in its
current form. I would appreciate any comments - didn't know whether a
bug should be filed on this issue and so am asking here first.
Thanks,
Marcus
Date: Mon Aug 30 07:30:45 2004
On Llu, 2004-08-30 at 06:45, Nikolay Datchev wrote:
> That's great :-(
>
> The Xfree86 that worked was so old that i even cannot remember the version
> (it was the time of slackware 7.1. So, this card is not supported anymore?
It depends which ramdac is in use on your card. One of
the problems beyond the crufty state of XFree 3.3.x
code is that you need to actually own a card with a
given ramdac in order to port the code for that ramdac
into XFree 4.x otherwise how do you test it.
Given the card and the RAMDAC info you can if is worth
your time port the ramdac code over.
Alan
Date: Mon Aug 30 09:06:51 2004
<200408301502.52563.biscani@pd.astro.it>
On Monday 30 August 2004 15:02, Francesco Biscani wrote:
> Ok, thanks very much - that's good news :) Installing RC3 right now, will
> report here if someone is interested.
Ok, got it up and running. The (very) good points:
- installed without a hitch (running Gentoo here);
- Dri working out-of-the-box (had to mess around with DRI cvs with older
versions);
- RenderAccel accepted by my Radeon IGP 340M;
- No crashes so far, also with GLX+Composite+Transset+RenderAccel.
The "placebo" points:
- seems snappier;
- displaying of fonts on screen seems much faster. I tried to do "find /" on a
console with aa fonts and seemed faster than prevoius version (is this
because of RenderAccel?)
The not-so-good point:
- transparencies and shadows are still dead slow. Better with RenderAccel, but
still quite unusable. Is this because the lack of support for component alpha
rendering in the "radeon" driver? Is there something to tweak to get better
performance?
Anyway, this seems to be going in the right direction. Amazing! Thanks to all
the people who are working on this project, you are great! :)
Regards,
--
biscani@pd.astro.it
From saturn_vk at abv.bg Mon Aug 30 11:04:06 2004
Date: Mon Aug 30 11:41:34 2004
Subject: Signal 11 with current xorg + nvidia drivers.
With the current cvs xorg and the latest nvidia drivers + an empty host.def file
, xorg freezes the whole machine whenever some opengl apps are started. The apps
that cause X to freeze the computer are quite big (enemy terrytory, maya), howe
ver, glxgears or engage (gl engine) do not cause a freeze.
After a reboot, the last entry in the log is about the signal (the log is includ
ed)
on a side, and totally unrelated note, does the mga driver support direct render
ing for the pci g200? I use it for a second head, but it seems that I cannot tur
n on the dr.
-----------------------------------------------------------------
http://www.mtel.bg/games/3m/ - ?-??? ??????? ?????????? ?? ???? ?? ?????????!
-------------- next part --------------
Name: Xorg.0.log.gz
Size: 9405 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040830/0c3d9dfc/Xorg.0
.log-0001.obj
Date: Mon Aug 30 12:44:24 2004
In-Reply-To: Your message of "Mon, 30 Aug 2004 21:04:06 +0300."
<1827255529.1093889046256.JavaMail.nobody@app1.ni.bg>
Message-ID: <E1C1s4b-0000JG-Fm@evo.keithp.com>
Around 21 o'clock on Aug 30, Viktor Kojouharov wrote:
> With the current cvs xorg and the latest nvidia drivers + an empty host.def
> file, xorg freezes the whole machine whenever some opengl apps are started.
It's important to note that you have both an nvidia card and an mga card
connected to the same X server, and that these cards use incompatible
implementations of the GLX extension. That's likely the cause of your
crash.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040830/cb56dff2/attach
ment.pgp
Date: Mon Aug 30 12:44:45 2004
Subject: [Xorg] Worried about the Savage 2D driver status
In-Reply-To: <20040828212331.270de192.felix@trabant>
References: <20040828212331.270de192.felix@trabant>
Message-ID: <a728f9f904083012447e269ec2@mail.gmail.com>
On Sat, 28 Aug 2004 21:23:31 +0200, Felix K?hling <fxkuehl@gmx.de> wrote:
> Hi,
>
> I wonder what's the status of the savage driver in Xorg CVS. The
> directory contains some files that seem to indicate that the driver has
> DRI support, but it's not working. Also the driver has a strange
> mode-setting problem on my Savage4 that I last saw with a code drop from
> S3/Via. I know that Tim Robert's drivers has lots of quirks for strange
> hardware that were partially missing in the S3/Via code drop and the
> code drop had more problems on some hardware. Therefore we decided to
> base DRI support in DRI CVS on Tim Robert's 2D driver. Alex Deucher
> integrated code from the S3/Via code drop for DRI support and improved
> Xv support. This approach got rid of the mode setting problem mentioned
> above and fixed other problems as well. Seeing that bug again in current
> Xorg CVS makes me worried about the stability and compatibility of the
> code. Can someone fill me in on the history of the Savage driver in Xorg
> CVS and maybe dispel my concerns?
When I ported the S3 code drop to DRI cvs I used Tim's latest code
drop on his web site. Xorg was based on the code in xfree86 cvs which
was slightly different from Tim's code. Eric Anholt merged the DRI
tree into Xorg, but only added the new files (savage_hwmc.c and
savage_dri.c); he didn't actually merge the changes to the other
files. I merged the changes (my xorg patch), but it was too late to
commit at that point. In retrospect I probably should have used the
driver from xfree86 cvs when I initially did the port, however, the
differences were pretty minimal. I'm planning a major clean up of the
savage DDX once I finish up and stablize the dualhead stuff. Hopefully
then I can fix the mode problems you have as well as the Xv problems
people have been reporting. It's all kind of on hold pending xorg
6.8.0 and my available free time.
Alex
>
> Best regards,
> Felix
>
From ralpht at gmail.com Mon Aug 30 13:42:23 2004
From: ralpht at gmail.com (Ralph Thomas)
Date: Mon Aug 30 15:29:42 2004
In-Reply-To: <200408300854.15612.ntt@control.uchicago.edu>
References: <200408300854.15612.ntt@control.uchicago.edu>
Message-ID: <72fed370040830134247843784@mail.gmail.com>
Try:
setenv XLIB_SKIP_ARGB_VISUALS 1
or:
export XLIB_SKIP_ARGB_VISUALS=1
before running the program. I think GTK+ programs usually try to grab
the "best" visual (and in this case it seems like it's not compatible
with another visual the program decided to use somewhere...).
Ralph
On Mon, 30 Aug 2004 08:54:15 -0500, Nguyen The Toan
<ntt@control.uchicago.edu> wrote:
>
> Hi,
>
> I compile x.org cvs on my Suse 9.1 at home and get the error "gdk-ERROR:
> BadMatch ..." (I'm not at home so I could not be more accurate) when I run
> GTK+ 1.x applications such as xmms, vmware. They quit immediately after
> printing out the errors. Does anyone know how to fix this?
>
> Thanks,
>
> Toan
From rene at rocklinux-consulting.de Mon Aug 30 16:01:48 2004
Date: Mon Aug 30 16:02:12 2004
In-Reply-To: <72fed370040830134247843784@mail.gmail.com>
<72fed370040830134247843784@mail.gmail.com>
Message-ID: <4133B1DC.5060705@rocklinux-consulting.de>
Hi,
Ralph Thomas wrote:
> Try:
> setenv XLIB_SKIP_ARGB_VISUALS 1
> or:
> export XLIB_SKIP_ARGB_VISUALS=1
>
> before running the program. I think GTK+ programs usually try to grab
> the "best" visual (and in this case it seems like it's not compatible
> with another visual the program decided to use somewhere...).
Yes.
However only some gtk+ applications are affected. XMMS works fine here,
But other ugly stuff like e.g. xzgv (some ugly image viever) does manage
to hard freeze my iBook (Radeon, PowerPC obviously). I'm currently
writing something important on the box so I'll try later if the
environment variable does prevent X to hard freeze the machine. I'll
also review if the same happens on my IA-32 box (and so is a generic
issue e.g. in the radeon driver?).
Have fun,
Ren? Rebe
From saturn_vk at abv.bg Mon Aug 30 15:57:08 2004
Date: Mon Aug 30 16:19:43 2004
however, this doesn't seem to be a local configuration problem, since the exact
same setup has worked without a problem with the 6.7.0 release and previous xfre
e servers.
>-------- ?????????? ????? --------
>??: Keith Packard <keithp@keithp.com>
>???????: Re: Signal 11 with current xorg + nvidia drivers.
>??: Discuss issues related to the xorg tree <xorg@freedesktop.org>
>????????? ??: ??????????, 2004, ?????? 30 22:44:13 EEST
>----------------------------------
>
>
>Around 21 o'clock on Aug 30, Viktor Kojouharov wrote:
>
>> With the current cvs xorg and the latest nvidia drivers + an empty host.def
>> file, xorg freezes the whole machine whenever some opengl apps are started.
>
>It's important to note that you have both an nvidia card and an mga card
>connected to the same X server, and that these cards use incompatible
>implementations of the GLX extension. That's likely the cause of your
>crash.
>
>-keith
>
>
>
-----------------------------------------------------------------
From thelucas at directbox.com Mon Aug 30 16:15:18 2004
From: thelucas at directbox.com (Lucas)
Date: Mon Aug 30 16:37:31 2004
Subject: X11 and virtual screen resolution
Message-ID: <20040830231518.GA107796@wu-wien.ac.at>
Hi everybody,
I would like to ask whether it is possible to "instruct" the window
manager(KDE in my case) to maximize windows to the width of the visible
part of the screen and not to the width of the virtual screen. I
configured my X11 to set 1280x768 for virtual screen whereas the physical
resolution is 1024x768. Windows widen up all the way to the "1280" when
maximized, which is kind of disturbing. I was just wondering if it were
possible to change this behavior or not.
Thank you for your responses,
Lucas
From ntt at control.uchicago.edu Mon Aug 30 16:43:56 2004
From: ntt at control.uchicago.edu (Nguyen The Toan)
Date: Mon Aug 30 16:44:32 2004
In-Reply-To: <72fed370040830134247843784@mail.gmail.com>
Message-ID: <200408301843.57979.ntt@control.uchicago.edu>
On Monday 30 August 2004 3:42 pm, Ralph Thomas wrote:
> Try:
> or:
Thanks. It works.
And just for the sake of clarity, the original error was:
ntt@server:~> xmms
Gdk-ERROR **: BadMatch (invalid parameter attributes)
serial 258 error_code 8 request_code 2 minor_code 0
>
>
> Ralph
>
> On Mon, 30 Aug 2004 08:54:15 -0500, Nguyen The Toan
>
> <ntt@control.uchicago.edu> wrote:
> > Hi,
> >
> > I compile x.org cvs on my Suse 9.1 at home and get the error "gdk-ERROR:
> > BadMatch ..." (I'm not at home so I could not be more accurate) when I
> > run GTK+ 1.x applications such as xmms, vmware. They quit immediately
> > after printing out the errors. Does anyone know how to fix this?
> >
> > Thanks,
> >
> > Toan
>
Date: Mon Aug 30 21:50:46 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 3
Added yesterday: 3
-----------------------------
is off by default
- Possible solution by building without damage for servers using
rootless layer
- Torrey Lyons is checking if this will work
- Patch provided
- Solution provided
- Will check in tomorrow unless there are objections
- Torrey Lyons is finalizing a self-contained patch to aglGlx.c
patch
* Bug #1216: I810 color problem with DRI driver
- Colors are incorrect with glxgears with DRI enabled
- Is anyone else seeing this problem?
From airlied at linux.ie Mon Aug 30 23:11:08 2004
Date: Mon Aug 30 23:11:12 2004
In-Reply-To: <20040830184139.9E5CBA00B7@freedesktop.org>
References: <20040830184139.9E5CBA00B7@freedesktop.org>
> > > Someone suggested that I should try the fbdev driver
> > > on my Sony C1VFK Picturebook instead of the ati driver,
> > > but when I try that I get the error message:
> > > "/dev/fb0: No such device"
> > > although there are devices /dev/fb* created by
> > > "dev/MAKEDEV -v fb"
> > > creating eg
> > > =====================================
> > > [tim@william tim]$ ls -ls /dev/fb0
> > > 0 crw------- 1 root root 29, 0 Aug 29 04:32 /dev/fb0
> > > =====================================
> > >
> > > Where did I go wrong?
> >
> > No framebuffer support in the kernel? Try recompile the kernel with ati
> > variants or the vesa one. You can also try the x vesa driver on the box
> > directly.
>
> I think I included all relevant options when compiling linux-2.6.8.1 .
> I noticed that the atyfb module was not loaded,
> but modprob-ing it (and restarting X) made no difference;
> I still get the error message
> "/dev/fb0: no such device".
>
The mach64 fb driver in the kernel is pretty crap at supporting mobility
chipsets, so you probably won't get any joy going this route.. have you an
Xorg bug logged for your issue.. it sounds like a blocker X not working
on something it used to ..
Dave.
--
From spyderous at gentoo.org Tue Aug 31 00:13:52 2004
Date: Tue Aug 31 00:21:06 2004
Subject: DMX docs want sgmlfmt
I think this is wrong.
The doc-related defines used are:
BuildLinuxDocText
BuildLinuxDocHtml
BuildLinuxDocPS
BuildSpecsDocs
BuildHtmlManPages
Nothing else in the tree wants sgmlfmt with these defines. It seems that
some sort of generated docs may be missing.
Here's a log excerpt:
making all in programs/Xserver/hw/dmx/doc...
make[6]: Entering directory `/var/tmp/portage/xorg-x11-6.7.99.2/work/xc/programs
/Xserver/hw/dmx/doc'
rm -f dmx*.html
sgmlfmt -f html dmx.sgml || rm -f dmx.html
/bin/sh: line 1: sgmlfmt: command not found
rm -f _dmx.ps dmx.ps
+ rm -f dmx.ps
+ sgmlfmt -f ps dmx.sgml
/bin/sh: line 1: sgmlfmt: command not found
make[6]: *** [dmx.ps] Error 127
See http://bugs.gentoo.org/show_bug.cgi?id=60292#c24 to contact the
original reporter.
Thanks,
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/d184180a/attach
ment-0001.pgp
From damien.thebault at laposte.net Mon Aug 30 13:15:23 2004
From: damien.thebault at laposte.net (Damien "tuX" THEBAULT)
Date: Tue Aug 31 01:46:03 2004
Subject: shadow_opacity.patch
Message-ID: <41338ADB.8090604@laposte.net>
I just installed X.org 6.8-rc2 (6.7.99.902) few days ago and played with
composite : shadows and transparency.
But when I setted transparency to a window, the shadow wasn't modified,
so the result was not so cool it could have been :(
So I read the code of the two files : transset.c and xcompmgr.c and
modified the last one to do what I wanted.
This patch cause xcompmgr to modify the ("client") shadow when the
transparency is modified (by transset, for example).
The first modification was about the function "win_extents" : the
opacity is not fixed, but depend of the window. (the "OPAQUE" define is
the same that the one in transset)
The second one is the main function : drop the shadow and redo it.
---
-------------- next part --------------
An embedded message was scrubbed...
From: "Damien \"tuX\" THEBAULT" <damien.thebault@laposte.net>
Date: Mon, 30 Aug 2004 22:13:53 +0200
Size: 2710
Url: http://freedesktop.org/pipermail/xorg/attachments/20040830/fb7e877a/shadow_
opacity.mht
From biscani at pd.astro.it Tue Aug 31 01:46:02 2004
Date: Tue Aug 31 01:48:24 2004
On Monday 30 August 2004 15:02, Francesco Biscani wrote:
> Ok, thanks very much - that's good news :) Installing RC3 right now, will
> report here if someone is interested.
Another quirk: mergedFB does not detect a secondary montitor. The same setup
worked ok with xorg 6.7.0. Is this a known issue or should I open a bug on
bugzilla?
--
biscani@pd.astro.it
From zyne01 at gmail.com Tue Aug 31 01:41:41 2004
From: zyne01 at gmail.com (philip V)
Date: Tue Aug 31 02:41:43 2004
Subject: keyboard with keycodes > 255... What to do?
Message-ID: <c9830ee804083101412c7e5f2d@mail.gmail.com>
well... My multimedia keyboard has several keys that produce keycodes
> 255 (after running showkey in console)
The problem is that appearantly the kernel can't handle these, and
that's why it doesn't produce any scancodes (showkey -s)
I thought that I was going to be able to access those keys using the
evdev protocol, but sadly enought, that made things even worse...
My keyboard is a logitech Desktop MX Y-RJ20 connected to my USB port.
I already had to make some changes to
/usr/X11R6/lib/X11/xkb/symbols/inet to be able to use the
multimedia-keys that actually do produce a keycode.
for evdev protocol, I already tried this:
Identifier "Logitech Y-RJ20"
Driver "kbd"
Option "Protocol" "evdev"
Option "Dev Name" "Logitech USB Receiver"
Option "Dev Phys" "usb-*/input0"
Option "XkbRules" "xorg"
Option "XkbModel" "logiinkseusb"
Option "XkbLayout" "be"
EndSection
Any solutions for this?
Thanks in advance...
From grifis87 at virgilio.it Tue Aug 31 02:58:30 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Tue Aug 31 03:10:24 2004
Message-ID: <200408311158.30708.grifis87@virgilio.it>
it rejects it:
patching file xcompmgr.c
Hunk #2 FAILED at 715.
Hunk #3 succeeded at 1854 with fuzz 2.
1 out of 3 hunks FAILED -- saving rejects to file xcompmgr.c.rej
patch unexpectedly ends in middle of line
xcompmgr.c.rej
GNU nano 1.3.2 File:
xcompmgr.c.rej
***************
*** 715,721 ****
{
double opacity = SHADOW_OPACITY;
if (w->mode == WINDOW_TRANS)
- opacity = opacity * TRANS_OPACITY;
w->shadow = shadow_picture (dpy, opacity,
w->a.width + w->a.border_width * 2,
w->a.height + w->a.border_width * 2,
--- 715,721 ----
{
+ opacity = opacity * ((double)w->opacity)/((double)OPAQUE);
w->a.width + w->a.border_width * 2,
w->a.height + w->a.border_width * 2,
From damien.thebault at laposte.net Tue Aug 31 03:33:26 2004
From: damien.thebault at laposte.net (Damien "tuX" Thebault)
Date: Tue Aug 31 03:33:14 2004
In-Reply-To: <200408311158.30708.grifis87@virgilio.it>
References: <200408311158.30708.grifis87@virgilio.it>
Message-ID: <413453F6.8000204@laposte.net>
Giovanni wrote:
> it rejects it:
>
>
> patching file xcompmgr.c
> Hunk #2 FAILED at 715.
> Hunk #3 succeeded at 1854 with fuzz 2.
> 1 out of 3 hunks FAILED -- saving rejects to file xcompmgr.c.rej
> patch unexpectedly ends in middle of line
>
>
> xcompmgr.c.rej
>
> GNU nano 1.3.2 File:
> xcompmgr.c.rej
>
>
> ***************
> *** 715,721 ****
> {
> double opacity = SHADOW_OPACITY;
> if (w->mode == WINDOW_TRANS)
> - opacity = opacity * TRANS_OPACITY;
> w->shadow = shadow_picture (dpy, opacity,
> w->a.width + w->a.border_width * 2,
> w->a.height + w->a.border_width * 2,
> --- 715,721 ----
> {
> double opacity = SHADOW_OPACITY;
> if (w->mode == WINDOW_TRANS)
> + opacity = opacity * ((double)w->opacity)/((double)OPAQUE);
> w->shadow = shadow_picture (dpy, opacity,
> w->a.width + w->a.border_width * 2,
> w->a.height + w->a.border_width * 2,
Well, you'r right, it is about the html encoding of the mail...
I'm really sorry about that :(
I attached the patch with this mail so it must be good (plain text)
This patche applies just to cvs, and I checked it works :
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xapps login
cvs -d :pserver:anoncvs@pdx.freedesktop.org:/cvs/xapps co xcompmgr
cd xcompmgr
patch -p0 <shadow_opacity.patch
./autogen.sh
./configure
make
--- so this is the patch
--- xcompmgr.ori.c 2004-08-30 21:40:15.755197856 +0200
+++ xcompmgr.c 2004-08-30 22:03:22.103440888 +0200
@@ -141,7 +141,7 @@
#define WINDOW_TRANS 1
#define WINDOW_ARGB 2
-#define TRANS_OPACITY 0.75
+#define OPAQUE 0xffffffff
#define DEBUG_REPAINT 0
#define DEBUG_EVENTS 0
@@ -715,7 +715,7 @@
{
- opacity = opacity * TRANS_OPACITY;
+ opacity = opacity *
((double)w->opacity)/((double)OPAQUE);
w->a.width +
w->a.border_width * 2,
w->a.height +
w->a.border_width * 2,
@@ -1854,6 +1854,8 @@
{
w->opacity = get_opacity_prop(dpy, w, OPAQUE);
determine_mode(dpy, w);
+ w->shadow = None;
+ w->extents = win_extents(dpy, w);
}
}
break;
From hamish at travellingkiwi.com Tue Aug 31 03:17:25 2004
From: hamish at travellingkiwi.com (Hamie)
Date: Tue Aug 31 03:43:41 2004
Subject: Radeon DRI for FireGL T2
Message-ID: <41345035.8040805@travellingkiwi.com>
This may be a FAQ already... But owning an IBM Thinkpad r50p with a
FireGL-T2 and 128MB plus 1600x1200 LCD, I'm very interested in getting
the max performance out of my graphics. But not willing to put up with
the very bad limitations of the fglrx drivers (i.e. not being able to
switch to text mode - ALT_CTRL-Fx or suspend). Plus I don't perticularly
like tainting the kernel...
But with the XOrg drivers (X Window System Version 6.7.99.902 (6.8.0 RC
2)) I only get 300 fps in glxgears at 16bpp vs about 2000-3000fps with
the fglrx drivers because the XOrg ones don't do DRI 3D for the 'newer'
chipsets...
Question is, whats the status of support for the 3D acceleration of the
FireGL-T2... Will it be never? Will it be when some bright spark decodes
what the closed-source drivers do? Are the docs available, and it's just
a question of someone finding the time? Or are ATI being their usual
'it's a secret & the world will fall apart if someone else knows how to
program the chipset'?
Is there any way I could help? (I haven't done a lot with the X servers
since the early 90's, but I could get involved again if it would help).
TIA
Hamish Marson.
From toelen at gmail.com Tue Aug 31 00:26:31 2004
From: toelen at gmail.com (Leen Toelen)
Date: Tue Aug 31 05:53:17 2004
Subject: NoMachine/FreeNX article at osnews.com
Message-ID: <a494a0bc0408310026755f9013@mail.gmail.com>
Hi all,
for whoever is interested, there is an article running at osnews about
a new kde client for nomachine, using the freeNX libraries (GPL)
provided by nomachine.
http://osnews.com/story.php?news_id=8139&page=1
Best regards,
Leen Toelen
From alexdeucher at gmail.com Tue Aug 31 06:09:37 2004
Date: Tue Aug 31 06:09:41 2004
Subject: X11 and virtual screen resolution
In-Reply-To: <20040830231518.GA107796@wu-wien.ac.at>
References: <20040830231518.GA107796@wu-wien.ac.at>
Message-ID: <a728f9f9040831060933a4689c@mail.gmail.com>
On Tue, 31 Aug 2004 01:15:18 +0200, Lucas <thelucas@directbox.com> wrote:
> Hi everybody,
>
> I would like to ask whether it is possible to "instruct" the window
> manager(KDE in my case) to maximize windows to the width of the visible
> part of the screen and not to the width of the virtual screen. I
> configured my X11 to set 1280x768 for virtual screen whereas the physical
> resolution is 1024x768. Windows widen up all the way to the "1280" when
> maximized, which is kind of disturbing. I was just wondering if it were
> possible to change this behavior or not.
Nope. not at the moment. perhaps in xinerama 2.0, but I haven't yet
looked into that. What would be useful is a maximize to frame
function in xinerama.
Alex
>
> Thank you for your responses,
>
> Lucas
>
Date: Tue Aug 31 06:22:30 2004
Message-ID: <a728f9f9040831062263c26e58@mail.gmail.com>
On Tue, 31 Aug 2004 10:46:02 +0200, Francesco Biscani
<biscani@pd.astro.it> wrote:
> On Monday 30 August 2004 15:02, Francesco Biscani wrote:
> > Ok, thanks very much - that's good news :) Installing RC3 right now, will
> > report here if someone is interested.
>
> Another quirk: mergedFB does not detect a secondary montitor. The same setup
> worked ok with xorg 6.7.0. Is this a known issue or should I open a bug on
> bugzilla?
I suspect it's probably a bug. Perhaps something broke for IGPs when
r400 support was added since some of the display code was rearranged,
. If I get a chance this week, I'll take a look.
Alex
Date: Tue Aug 31 06:35:02 2004
In-Reply-To: <41345035.8040805@travellingkiwi.com>
References: <41345035.8040805@travellingkiwi.com>
Message-ID: <a728f9f9040831063426891c1a@mail.gmail.com>
On Tue, 31 Aug 2004 11:17:25 +0100, Hamie <hamish@travellingkiwi.com> wrote:
>
> This may be a FAQ already... But owning an IBM Thinkpad r50p with a
> FireGL-T2 and 128MB plus 1600x1200 LCD, I'm very interested in getting
> the max performance out of my graphics. But not willing to put up with
> the very bad limitations of the fglrx drivers (i.e. not being able to
> switch to text mode - ALT_CTRL-Fx or suspend). Plus I don't perticularly
> like tainting the kernel...
>
> But with the XOrg drivers (X Window System Version 6.7.99.902 (6.8.0 RC
> 2)) I only get 300 fps in glxgears at 16bpp vs about 2000-3000fps with
> the fglrx drivers because the XOrg ones don't do DRI 3D for the 'newer'
> chipsets...
>
> Question is, whats the status of support for the 3D acceleration of the
> FireGL-T2... Will it be never? Will it be when some bright spark decodes
> what the closed-source drivers do? Are the docs available, and it's just
> a question of someone finding the time? Or are ATI being their usual
> 'it's a secret & the world will fall apart if someone else knows how to
> program the chipset'?
>
> Is there any way I could help? (I haven't done a lot with the X servers
> since the early 90's, but I could get involved again if it would help).
Right now the xorg drivers only have 2D support for r300/r400
chipsets. The only databooks available for r300 are for 2D. At one
point Vladimir did some work to figure out the r300 3D core. If you
are interested in r300 support you may want to help him:
http://volodya-project.sourceforge.net/R300.php
Alex
>
> TIA
>
> Hamish Marson.
>
From m.hearn at signal.QinetiQ.com Tue Aug 31 07:36:33 2004
From: m.hearn at signal.QinetiQ.com (Mike Hearn)
Date: Tue Aug 31 07:43:51 2004
Subject: Composite and application compatibility
Message-ID: <41348CF1.6080105@signal.qinetiq.com>
Hi guys,
I've been reading the archives of this list and am a bit concerned that
the introduction of X compositing will break backwards compatibility
with some important software.
The first thread about this seems to have been the Flash/Mozilla issue.
The second suggests that some GTK 1.x apps can be broken.
This is a serious amount of breakage, similar in scope to the problems
caused by the introduction of NPTL which mangled RealPlayer, the JVM and
Wine amongst many other high profile, popular applications.
The recommended workaround seems to be to set an environment variable,
but I have severe reservations about this approach. It's been used
before, to disable NPTL for apps that didn't work with it, and has
several serious disadvantages:
1) You have to know about the environment variable in order to use it.
LD_ASSUME_KERNEL was never well documented until long after the fact.
Even if XLIB_SKIP_ARGB_VISUALS is well documented in man pages,
release notes etc, the vast majority of users will still be unaware
of it just through the nature of the thing.
2) You have to be able to diagnose the problem in order to use it.
For somebody who is not a programmer, this can be impossible. Often
I've only thought of using LD_ASSUME_KERNEL after putting gdb to work
on mysterious deadlocks and crashes. This is far beyond
the abilities of most Linux users who these days are usually not
developers. Even if the user *is* able to use a debugger there's no
guarantee that they will correlate BadMatch errors/crashes in Xlib
with the introduction of ARGB visuals much as many people could not
correlate crashes and deadlocks inside libpthreads with NPTL.
3) It's a pain in the ass to use. You have to write a wrapper script
for each program affected.
4) The vast majority of people can't or don't use them. Go read any
popular Linux (or even *BSD) tech support forum to see endless
threads full of people suffering through needless breakage.
From my understanding of the technology clients have to be specifically
written to use ARGB visuals anyway, so there's no harm in hiding them
from applications entirely unless they opt in. What is the problem with
having the developer do:
XCompositeEnableARGBVisuals();
before doing an XOpenDisplay or similar to prevent widespread breakage?
In the Flash/Mozilla thread, this seemed to be the original intention
but was hard to implement because of bad interactions between XRENDER
and magically hidden visuals. If the visuals were simply ignored
entirely unless enabled before connect (ie even the composite APIs
couldn't see them) would this still cause a problem?
This opt-in API could then be propogated up through the toolkits so ARGB
visuals are enabled on an app by app basis.
What are peoples thoughts on this?
thanks -mike
From biscani at pd.astro.it Tue Aug 31 07:59:03 2004
Date: Tue Aug 31 08:01:29 2004
In-Reply-To: <a728f9f9040831062263c26e58@mail.gmail.com>
<a728f9f9040831062263c26e58@mail.gmail.com>
On Tuesday 31 August 2004 15:22, Alex Deucher wrote:
> I suspect it's probably a bug. Perhaps something broke for IGPs when
> r400 support was added since some of the display code was rearranged,
> . If I get a chance this week, I'll take a look.
>
> Alex
Thanks for that. I can paste my xorg.conf and/or logs if even remotely useful.
BTW, what are the projects regarding the radeon driver with respect to render
acceleration and other eye-candy goodies? I've tested on RC3 with xcompmgr
and transset; while shadows seem to be working good (performance-wise),
transparency is still unusable. I may have made mistakes in configuration,
but everything seems ok. I'm asking because the nvidia folks seem to get
great performance out of lower-end cards thanks to RenderAccel. Is there any
hope to see something like that also in the open-source radeon driver? Please
do not take this a request, I just would like to know if we can expect or not
improvements in the future on this side.
Thanks,
--
biscani@pd.astro.it
From mharris at www.linux.org.uk Tue Aug 31 08:47:02 2004
Date: Tue Aug 31 09:18:30 2004
In-Reply-To: <41345035.8040805@travellingkiwi.com>
Message-ID: <41349D76.90900@www.linux.org.uk>
Hamie wrote:
> Question is, whats the status of support for the 3D acceleration of the
> FireGL-T2...
The status of 3D acceleration for R300 and newer chipsets, is that there
isn't any. There is nobody working on them, and there are currently no
specifications available for the 3D part of the chip.
> Will it be never?
It would require a time machine, remote viewer, or clairvoyant to answer
that non-speculatively.
> Will it be when some bright spark decodes what the closed-source
> drivers do?
That is incredibly unlikely. Good luck to writing GPU microcode without
any knowledge of the microcode instructions to whomever tries to do so.
> Are the docs available, and it's just a question of someone finding
> the time?
No.
> Or are ATI being their usual
> 'it's a secret & the world will fall apart if someone else knows how
> to program the chipset'?
Access to the hardware specifications is only one of several factors
that would be required to have 3D support for the newer chips. In my
own personal opinion, and it's just that, and opinion, the other thing
required would be a funded contract between ATI and a third party to
develop the necessary driver contractually and on a time schedule.
Developing 3D drivers is basically a full time, time consuming task that
requires dedication and many man hours to complete. To date, the
majority of the successfully completed OSS drivers have been implemented
via funded contracts. The funding is what keeps the developers hacking
on completing the driver rather than looking for employment, or working
a full time job and spending only a few hours here and there hacking on
drivers. Without funding, it basically isn't going to happen,
specifications or not.
Nobody out there is likely to put out funding to develop such driver
support, unless they have a financial or corporate interest in doing so
for some reason or another. In the case of the R200 3D support, it was
graciously developed under funding from The Weather Channel, who
presumeably are using a lot of Radeon R200 based hardware and wanted
open source driver support for their hardware enough that it was
financially viable for them to fund the project. That's not any
official story, just my own educated guess.
Aside from funding, permission from the hardware vendor to do the work
and access to the necessary hardware documentation, contractual
obligations for the work to be completed within a certain timeframe, and
financial motivation for doing so, it isn't likely to happen unless a
given hardware vendor takes on the task themselves and then contributes
their code to the open source community.
ATI has been fantastic for years now in providing open source driver
support for their hardware, and continues to do so, even though we do
not currently have R300 3D acceleration support.
I'm sure if the right conditions become present in the market, as
outlined above, that there is a possibility of open source 3D drivers
existing some day, if it is beneficial to justify the costs involved
with developing them in house, or paying someone else to do the work.
> Is there any way I could help? (I haven't done a lot with the X servers
> since the early 90's, but I could get involved again if it would help).
Probably not, unless you can reverse engineer GPU microcode. I'm not
aware of anyone who's done that successfully to date on any modern video
hardware, or at least not within a timeframe where the hardware is still
relevant. If you start now however, who knows, maybe it'll draw
triangles by 2009 or so. ;o)
From idr at us.ibm.com Tue Aug 31 09:12:05 2004
Date: Tue Aug 31 09:38:52 2004
In-Reply-To: <413103B1.8000202@rocklinux-consulting.de>
References: <413103B1.8000202@rocklinux-consulting.de>
Message-ID: <4134A355.5040807@us.ibm.com>
Ren? Rebe wrote:
> just a quick note (not a full conformance test run), that X.Org HEAD
> runs well on PowerPC and UltraSPARC Linux (both yet unreleased ROCK
> Linux forks). Since Eric Anholt's Bug #1101 PaintWindow I also do not
> yet had any screen corruptions anymore.
>
> PowerPC:
> G3, iBook2, Ati/Radeon Mobility M7 LW, Linux 2.6.8.1, gcc-3.2.3
>
> XRender ok, Xv: ok, dri: ok, MergedFB: ok
You were able to build on that system without hitting bug #905? If so,
that means the bug probably only occurs on G4 based systems. Interesting...
From rene at rocklinux-consulting.de Tue Aug 31 10:41:05 2004
Date: Tue Aug 31 10:41:18 2004
In-Reply-To: <4133B1DC.5060705@rocklinux-consulting.de>
References: <200408300854.15612.ntt@control.uchicago.edu> <72fed3700408301
34247843784@mail.gmail.com>
<4133B1DC.5060705@rocklinux-consulting.de>
Message-ID: <4134B831.4070404@rocklinux-consulting.de>
Hi,
Ren? Rebe wrote:
> Ralph Thomas wrote:
>
>> Try:
>> setenv XLIB_SKIP_ARGB_VISUALS 1
>> or:
>> export XLIB_SKIP_ARGB_VISUALS=1
>>
>> before running the program. I think GTK+ programs usually try to grab
>> the "best" visual (and in this case it seems like it's not compatible
>> with another visual the program decided to use somewhere...).
>
>
> Yes.
>
> However only some gtk+ applications are affected. XMMS works fine here,
> But other ugly stuff like e.g. xzgv (some ugly image viever) does manage
> to hard freeze my iBook (Radeon, PowerPC obviously). I'm currently
> writing something important on the box so I'll try later if the
> environment variable does prevent X to hard freeze the machine. I'll
> also review if the same happens on my IA-32 box (and so is a generic
> issue e.g. in the radeon driver?).
Ok, the update: exporting XLIB_SKIP_ARGB_VISUALS on the iBook does
prevent the X server from freezing the machine. Xzgv works then.
However, on the IA-32 box it also works without exporting the variable -
it is just slower but does not freeze the box.
Have fun,
Ren?
Date: Tue Aug 31 10:51:18 2004
Message-ID: <4134BA7D.AD1ED83E@nrubsig.org>
Ralph Thomas wrote:
> > I compile x.org cvs on my Suse 9.1 at home and get the error "gdk-ERROR:
> > BadMatch ..." (I'm not at home so I could not be more accurate) when I run
> > GTK+ 1.x applications such as xmms, vmware. They quit immediately after
> > printing out the errors. Does anyone know how to fix this?
>
> Try:
> or:
>
Keith:
Is it possible to reoder the ARGB visuals in a way on the server side
that they appear at the end of the list of visuals (e.g. after the
normal RGB (or better: non-ARGB) visuals) ? Maybe that can prevent such
things (crashes etc.) from happening...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From tee0 at mbnet.fi Tue Aug 31 10:53:19 2004
From: tee0 at mbnet.fi (Tero Karvinen tero _dot_ karvinen atta iki _dot_ fi)
Date: Tue Aug 31 10:53:22 2004
Subject: hostname change breaks X - how to connect 127.0.0.1 ?
Message-ID: <20040831205319.7e34e18b.tee0@mbnet.fi>
When hostname is changed, X can no longer open windows. I think
this could be fixed by making X connect to 127.0.0.1, but I don't
know how to do this.
To repeat the problem:
$ xterm
(xterm opens normally)
# hostame xbreaker
$ xterm
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xterm Xt error: Can't open display: :0.0
(xterm does not open)
XFree86 has the same problem. I have seen this on Redhat 8, Redhat 9,
Fedora Core 1 and Fedora Core 2 on different computers and networks.
Searching google, groups2, gmane and asking in #xorg, #freedeesktop and
#xwin did not help. I have found bubble gum solutions, such as restarting
X and setting hostname to localhost, but they interrupt work and cause
other problems.
How can I make X work normally when hostname keeps changing?
--
Tero Karvinen http://iki.fi/karvinen tero karvinen atta iki fi
From saturn_vk at abv.bg Tue Aug 31 11:08:47 2004
Date: Tue Aug 31 11:08:53 2004
It's the exact same story without the mga card. still whenever xcompmgr is activ
ated, the computer freezes on more intense opengl programs. if xcompmgr isn't st
arted, they run fine.
>-------- ?????????? ????? --------
>??: Keith Packard <keithp@keithp.com>
>???????: Re: Signal 11 with current xorg + nvidia drivers.
>??: Discuss issues related to the xorg tree <xorg@freedesktop.org>
>????????? ??: ??????????, 2004, ?????? 30 22:44:13 EEST
>----------------------------------
>
>
>Around 21 o'clock on Aug 30, Viktor Kojouharov wrote:
>
>> With the current cvs xorg and the latest nvidia drivers + an empty host.def
>> file, xorg freezes the whole machine whenever some opengl apps are started.
>
>It's important to note that you have both an nvidia card and an mga card
>connected to the same X server, and that these cards use incompatible
>implementations of the GLX extension. That's likely the cause of your
>crash.
>
>-keith
>
>
>
-----------------------------------------------------------------
From tee0 at mbnet.fi Tue Aug 31 10:37:11 2004
From: tee0 at mbnet.fi (Tero Karvinen tero _dot_ karvinen atta iki _dot_ fi)
Date: Tue Aug 31 11:09:31 2004
Message-ID: <20040831203711.7c5e73aa.tee0@mbnet.fi>
When hostname is changed, X can no longer open windows. I think
this could be fixed by making X connect to 127.0.0.1, but I don't
know how to do this.
To repeat the problem:
$ xterm
(xterm opens normally)
# hostame xbreaker
$ xterm
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xterm Xt error: Can't open display: :0.0
(xterm does not open)
XFree86 has the same problem. I have seen this on Redhat 8, Redhat 9,
Fedora Core 1 and Fedora Core 2 on different computers and networks.
Searching google, groups2, gmane and asking in #xorg, #freedeesktop and
#xwin did not help. I have found bubble gum solutions, such as restarting
X and setting hostname to localhost, but they interrupt work and cause
other problems.
How can I make X work normally when hostname keeps changing?
--
Tero Karvinen http://iki.fi/karvinen tero karvinen atta iki fi
Date: Tue Aug 31 11:11:03 2004
<4134BA7D.AD1ED83E@nrubsig.org>
Message-ID: <E1C2D5e-00021J-19@evo.keithp.com>
Around 19 o'clock on Aug 31, Roland Mainz wrote:
> Is it possible to reoder the ARGB visuals in a way on the server side
> that they appear at the end of the list of visuals (e.g. after the
> normal RGB (or better: non-ARGB) visuals) ? Maybe that can prevent such
> things (crashes etc.) from happening...
If you'll check your xdpyinfo output, that's already the case.
The problem here is that applications are careless about visual matching
and often use slightly different algorithms in different parts of the
code. When both algorithms end up matching the same visual, there's no
problem. But, introduce a new visual into the X server and you'll see
applications breaking. There's no real fix we can put into the X server,
unfortunately the burden of this problem lies on the application
developers. It's not really the fault of the Composite extension itself;
I did some testing with adding a simple depth-24 RGB visual to my
nominally 16-bit X server and found all of the same issues.
I did try to move these new visuals to the Composite extension itself so
that existing applications would never see them, but the troubles with
that approach were even worse than when these new visuals were just
presented in the normal list (many applications segfaulted quite
spectacularly).
I also considered a more 'clever' test for 'broken' applications inside
xlib -- placing a test around code which only the flash plugin was using,
but we rejected that as too difficult to document and explain to people.
The current environment variable is easy to understand (at least by
developers), and also easy to demonstrate (just use xdpyinfo).
If we can come up with a better method for making this all work, we'll
certainly want to use it. This is, of course, one of the primary reasons
that Composite is disabled by default in the Xorg server.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/7f55aa6d/attach
ment-0001.pgp
From volodya at mindspring.com Tue Aug 31 11:44:26 2004
Date: Tue Aug 31 11:44:31 2004
In-Reply-To: <41349D76.90900@www.linux.org.uk>
<41349D76.90900@www.linux.org.uk>
On Tue, 31 Aug 2004, Mike A. Harris wrote:
> Hamie wrote:
>> Question is, whats the status of support for the 3D acceleration of the
>> FireGL-T2...
>
> The status of 3D acceleration for R300 and newer chipsets, is that there
> isn't any. There is nobody working on them, and there are currently no
> specifications available for the 3D part of the chip.
Small correction: I am trying to figure out how to use R300 3d pipeline
(http://volodya-project.sf.net/R300.php) but the progress has been slow so
far.
>> Will it be when some bright spark decodes what the closed-source
>> drivers do?
>
> That is incredibly unlikely. Good luck to writing GPU microcode without any
> knowledge of the microcode instructions to whomever tries to do so.
CP engine microcode is available at the link above (provided by ATI), so
the remaining task is to figure out how to use 3d accelerator
(and which registers it uses).
The GPU vertex and texture engine instructions would be harder to figure
out, but not impossible as we know what to expect - and it is possible to
compile user-mode programs with different code to see what different
instructions do.
best
Vladimir Dergachev
Date: Tue Aug 31 12:24:10 2004
Message-ID: <4134CAD5.5050709@www.linux.org.uk>
>
>
> On Tue, 31 Aug 2004, Mike A. Harris wrote:
>
>> Hamie wrote:
>>
>>> Question is, whats the status of support for the 3D acceleration of
>>> the FireGL-T2...
>>
>>
>> The status of 3D acceleration for R300 and newer chipsets, is that
>> there isn't any. There is nobody working on them, and there are
>> currently no specifications available for the 3D part of the chip.
>
>
> Small correction: I am trying to figure out how to use R300 3d pipeline
> (http://volodya-project.sf.net/R300.php) but the progress has been slow
> so far.
Yeah, it's good that you've taken an interest in this, and started it
off. The core problem I think though, which I attempted to state in the
first message, is just how complicated the problem can be to solve, and
just how many man hours may be involved. Without funding, and without
knowledge of the hardware from specs, it's more or less a very long
windy road, and only then if someone has the time to dedicate to doing
it more or less full time. ;o/
It'd be great to see something come out of the above work, but does
anyone have that much time to dedicate to it? I can see many people
having vim and vigour to start trying to figure out such chips operation
and/or reverse engineer them, but personally, I think the further
someone delves into the problem, the more complicated they realize the
problem is, and how much time it would take to make even small progress,
and they lose interest in doing it, or just don't have the time to
dedicate to it due to real job, or other matters in life.
So, while I applaud anyone and everyone who tries to do such an uphill
task, I still think it near impossible that we'll see a fully
functioning OSS R300 driver without help from ATI (microcode, PRG, DDK),
and funding from someone to see it through completion within a timeframe
that the hardware is still considered relevant. The R4xx cards are
current now however, and by the time such drivers might be completed
under proper funding though and get the kinks worked out, a new
generation of hardware is likely to be out, and the R300 work will be 2
or more generations old.
I'd desperately like to be wrong, and to see an OSS R300 driver before
then, but I just don't think the manpower is available in the community
to dedicate to reverse engineering the hardware and doing the necessary
work in a reasonable timeframe. People who have the level of skill who
could pull it off, would probably be hired by a video vendor or other
hardware vendor before they completed such a complex task, and would
likely not have the time to dedicate to completing the work.
Again though, I hope I'm wrong, and look forward to being so. ;o)
Date: Tue Aug 31 12:24:19 2004
In-Reply-To: <20040831203711.7c5e73aa.tee0@mbnet.fi>
References: <20040831203711.7c5e73aa.tee0@mbnet.fi>
Message-ID: <4134CB55.4040104@www.linux.org.uk>
Tero Karvinen tero _dot_ karvinen atta iki _dot_ fi wrote:
> When hostname is changed, X can no longer open windows. I think
> this could be fixed by making X connect to 127.0.0.1, but I don't
> know how to do this.
>
> To repeat the problem:
> $ xterm
> (xterm opens normally)
> # hostame xbreaker
> $ xterm
> Xlib: connection to ":0.0" refused by server
> Xlib: No protocol specified
> xterm Xt error: Can't open display: :0.0
> (xterm does not open)
>
> XFree86 has the same problem. I have seen this on Redhat 8, Redhat 9,
> Fedora Core 1 and Fedora Core 2 on different computers and networks.
> Searching google, groups2, gmane and asking in #xorg, #freedeesktop and
> #xwin did not help. I have found bubble gum solutions, such as restarting
> X and setting hostname to localhost, but they interrupt work and cause
> other problems.
>
> How can I make X work normally when hostname keeps changing?
To my knowledge, there's no way to do that currently. You'd have to
hack up something in the X server authentication code to handle hostname
changes, but I don't think anyone's ever done that. We've got a feature
request for this in Red Hat bugzilla, but it's more of a general problem
than a distribution specific one.
I'm interested in hearing what other people might propose as solutions
to this problem though also.
TIA
Date: Tue Aug 31 12:44:42 2004
<4134CB55.4040104@www.linux.org.uk>
Message-ID: <4134D511.B5024DB2@nrubsig.org>
"Mike A. Harris" wrote:
[snip]
> > How can I make X work normally when hostname keeps changing?
>
> To my knowledge, there's no way to do that currently. You'd have to
> hack up something in the X server authentication code to handle hostname
> changes, but I don't think anyone's ever done that. We've got a feature
> request for this in Red Hat bugzilla, but it's more of a general problem
> than a distribution specific one.
>
> I'm interested in hearing what other people might propose as solutions
> to this problem though also.
One option is to avoid hostname-based authetification and use one of the
user-to-user authentification schemes like SUN-DES-1 or MIT-KERBEROS-5
...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From ajax at nwnk.net Tue Aug 31 11:42:16 2004
Date: Tue Aug 31 12:49:01 2004
In-Reply-To: <4134CB55.4040104@www.linux.org.uk>
Hash: SHA1
On Tuesday 31 August 2004 15:02, Mike A. Harris wrote:
> Tero Karvinen tero _dot_ karvinen atta iki _dot_ fi wrote:
> > When hostname is changed, X can no longer open windows. I think
> > this could be fixed by making X connect to 127.0.0.1, but I don't
> > know how to do this.
> >
> > To repeat the problem:
> > $ xterm
> > (xterm opens normally)
> > # hostame xbreaker
> > $ xterm
> > Xlib: connection to ":0.0" refused by server
> > Xlib: No protocol specified
> > xterm Xt error: Can't open display: :0.0
> > (xterm does not open)
> >
> > XFree86 has the same problem. I have seen this on Redhat 8, Redhat 9,
> > Fedora Core 1 and Fedora Core 2 on different computers and networks.
> > Searching google, groups2, gmane and asking in #xorg, #freedeesktop and
> > #xwin did not help. I have found bubble gum solutions, such as restarting
> > X and setting hostname to localhost, but they interrupt work and cause
> > other problems.
> >
>
>
> I'm interested in hearing what other people might propose as solutions
> to this problem though also.
I propose not changing the hostname. Give the machine a name, bind it to
127.0.0.1 or ::1 in /etc/hosts, and never ever call hostname(1) even if you
switch networks. The machine's idea of its own canonical name should not
change just because your dhcp server wants to call you
dyn-3-1-33-7.erewhon.dom.
Alternatively you could hack the auth code to call gethostname(3) on every
client connection, but I'd consider that to be suboptimal.
- - ajax
iD8DBQFBNMaIW4otUKDs0NMRAhypAJwMkOU6HigoUmVUx+3S+HMw9URTlACfQKxp
VX2uC0MXc14X1CYJ/Sz28MQ=
=+1D+
Date: Tue Aug 31 12:59:50 2004
In-Reply-To: <4133B1DC.5060705@rocklinux-consulting.de>
<4133B1DC.5060705@rocklinux-consulting.de>
On Mon, 2004-08-30 at 19:01, Ren? Rebe wrote:
> Hi,
>
> Ralph Thomas wrote:
> > Try:
> > setenv XLIB_SKIP_ARGB_VISUALS 1
> > or:
> > export XLIB_SKIP_ARGB_VISUALS=1
> >
> > before running the program. I think GTK+ programs usually try to grab
> > the "best" visual (and in this case it seems like it's not compatible
> > with another visual the program decided to use somewhere...).
>
> Yes.
>
> However only some gtk+ applications are affected. XMMS works fine here,
> But other ugly stuff like e.g. xzgv (some ugly image viever) does manage
> to hard freeze my iBook (Radeon, PowerPC obviously). I'm currently
> writing something important on the box so I'll try later if the
> environment variable does prevent X to hard freeze the machine. I'll
> also review if the same happens on my IA-32 box (and so is a generic
> issue e.g. in the radeon driver?).
If I had to guess, my guess is that it's probably applications that
either assume:
- The system visual is the same as the GdkRGB visual (this breaks
on dual 8bit/24bit systems, etc, but was a common GTK+-1.x
programming mistake.)
- The GdkRGB visual is the same as imlib's visual. (probably would
work on most "normal" systems.)
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/4788c1de/attach
ment.pgp
Date: Tue Aug 31 13:03:56 2004
On Tue, 2004-08-31 at 15:02, Mike A. Harris wrote:
> Tero Karvinen tero _dot_ karvinen atta iki _dot_ fi wrote:
> > When hostname is changed, X can no longer open windows. I think
> > this could be fixed by making X connect to 127.0.0.1, but I don't
> > know how to do this.
> >
> > To repeat the problem:
> > $ xterm
> > (xterm opens normally)
> > # hostame xbreaker
> > $ xterm
> > Xlib: connection to ":0.0" refused by server
> > Xlib: No protocol specified
> > xterm Xt error: Can't open display: :0.0
> > (xterm does not open)
> >
> > Fedora Core 1 and Fedora Core 2 on different computers and networks.
> > Searching google, groups2, gmane and asking in #xorg, #freedeesktop and
> > #xwin did not help. I have found bubble gum solutions, such as restarting
> > X and setting hostname to localhost, but they interrupt work and cause
> > other problems.
> >
>
The suggestion that I think is probably in that bugzilla entry (Havoc
keeps pushing it) is to add a new "magic cookie" authentication scheme
where the lookup key in the xauth file isn't the hostname, but rather
a unique string provided by the server during authentication
negotiation.
So, basically you replace the private cookie with a public
cookie:private cookie pair.
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/1d7b4f15/attach
ment.pgp
Date: Tue Aug 31 13:05:06 2004
On Maw, 2004-08-31 at 20:02, Mike A. Harris wrote:
Kerberos keys have this property. Really X needs a proper hostkey not
hostname based keying. Especially since DNS is not trustable so
hostnames are not trustable so X host based auth is worth rather less
than you might think (ie near zilch).
Alan
Date: Tue Aug 31 14:08:57 2004
Subject: X performance on mini-itx boards
Message-ID: <4134E2E4.80901@travellingkiwi.com>
What sort of performance on the VIA mini-itx boards can be expected with
XOrg? Is there hardware acceleration available for these boards? WHat
sort of fps can you get with glxgears at default size?
TIA
Hamish Marson.,
From rlrevell at joe-job.com Tue Aug 31 14:30:24 2004
From: rlrevell at joe-job.com (Lee Revell)
Date: Tue Aug 31 14:30:27 2004
Subject: X performance on mini-itx boards
In-Reply-To: <4134E2E4.80901@travellingkiwi.com>
References: <4134E2E4.80901@travellingkiwi.com>
Message-ID: <1093987823.3404.3.camel@krustophenia.net>
On Tue, 2004-08-31 at 16:43, Hamie wrote:
> What sort of performance on the VIA mini-itx boards can be expected with
> XOrg? Is there hardware acceleration available for these boards? WHat
> sort of fps can you get with glxgears at default size?
>
Currently, it sucks. The "hardware acceleration" does not seem to
work. I get the exact same framerate with glxgears regardless of
whether the via.o kernel module is installed:
408 frames in 7.0 seconds = 58.286 FPS
The DRI is definitely enabled, I can see it in the logs.
This is on an EPIA M-6000.
I have been meaning to report this as a bug but have not had the
bandwidth. I would imagine this is related to why the via DRI module is
still not in the mainstream kernel, but has to be installed from xorg
CVS.
Lee
Date: Tue Aug 31 14:30:50 2004
Subject: XOrg - Cards & their Performance...
Message-ID: <4134EE11.9080007@travellingkiwi.com>
What's the chance of having a page on the XOrg (Or freedesktop.org)
websites that lists the different cards supported by the XOrg server and
their performance with glxgears or some easy to run benchmark under Linux?
That way people getting burnt by lackluster support from vendors should
possibly be lessened...
TIA
Hamish.
Date: Tue Aug 31 14:35:08 2004
In-Reply-To: Your message of "Tue, 31 Aug 2004 14:42:16 EDT."
<200408311442.18391.ajax@nwnk.net>
Message-ID: <E1C2GHN-00029v-31@evo.keithp.com>
Around 14 o'clock on Aug 31, Adam Jackson wrote:
> Alternatively you could hack the auth code to call gethostname(3) on every
> client connection, but I'd consider that to be suboptimal.
That's actually the reason things do break. The problem is that Xauth
encodes the hostname in the .Xauthority file so that a single .Xauthority
file can be shared among multiple hosts (via SMB or NFS). In today's
world, that's patently stupid as transmitting the contents of that file
over the network obviates the utility of any of the supported host-based
authorization schemes. (feel free to guess the author of the original
.Xauthority file scheme...)
One trivial fix here would be to have an option in the display manager
which generates this key to place an empty hostname in the file.
XauGetBestAuthByAddr will match this for any hostname.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
ment.pgp
Date: Tue Aug 31 14:39:16 2004
In-Reply-To: Your message of "Tue, 31 Aug 2004 20:03:02 BST."
Message-ID: <E1C2GLN-0002Aa-N5@evo.keithp.com>
> Especially since DNS is not trustable so hostnames are not trustable so X
> host based auth is worth rather less than you might think (ie near zilch).
We're not discussing the (obviously insecure) host based auth scheme here,
but rather the local hostname-based keying of the shared secret key auth
schemes (MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1). The database of
avaialble secrets is keyed off of the local hostname so that multiple
hosts can share the same key file. The database is *also* keyed off of
the display number, so multiple displays on the same machine are supported.
If the database contains an entry with an empty hostname, it will match
any hostname, so a .Xauthority file which is used only on a single host
could use this method quite reliably.
Not that MIT-MAGIC-COOKIE-1 is secure when used across a bare X network
connection, but it is fine when tunneled over ssh.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/81effcac/attach
ment.pgp
Date: Tue Aug 31 15:50:59 2004
Subject: xcompmgr and transset shadow management.
Message-ID: <4134FBF8.9010305@laposte.net>
I worked a little more on xcompmgr and transset, and managed to do what
I wanted :
->The ("client") shadow and the window opacity are linked, so when the
window's opacity is low, it is (I think) better.
->The shadow's opacity can be modified. This allowed the use of programs
like "gDesklets" on the desktop without seeing the shadows.
I know that xcompmgr and transset were designed just as an example for
the "composite" extension, but I think it can be usable on a desktop...
Damien
-------------- next part --------------
Name: signature.asc
Size: 252 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040901/31f4c7a4/signat
ure.pgp
Date: Tue Aug 31 16:09:20 2004
In-Reply-To: <4134FBF8.9010305@laposte.net>
References: <4134FBF8.9010305@laposte.net>
> ->The shadow's opacity can be modified. This allowed the use of programs
> like "gDesklets" on the desktop without seeing the shadows.
>
You should be able to run 'gdesklets start --translucent' for gdesklets
to use an actual alpha channel, and no shadows. This worked quite well
for me until recently, when the alpha channel is replaced by black, and
shadows appear. I'm not entirely sure what caused this to stop
working. Does anybody have any ideas?
From morphie at unravel-music.nl Tue Aug 31 16:24:49 2004
Date: Tue Aug 31 16:22:54 2004
In-Reply-To: <4134FBF8.9010305@laposte.net>
On Wednesday 01 September 2004 00:30, Damien "tuX" Thebault wrote:
> ->The shadow's opacity can be modified. This allowed the use of programs
> like "gDesklets" on the desktop without seeing the shadows.
Changing the opacity of a shadow to hide it isn't the prettiest way of doing
that, don't you think? ;-)
> I know that xcompmgr and transset were designed just as an example for
> the "composite" extension, but I think it can be usable on a desktop...
The windowmanager should manage Xcomposite. (Some patches for metacity even do
that right now). As far as windowmanagers will go is up to them, but an
XWindow contains properties of the type of window we're dealing with. On
those properties the windowmanager should (and should be able to) decide
whether or not to display eye-candy (and the type of eye-candy).
By using xcompmgr for other things than testing and previewing, is functional
decomposition, because it's the job of the WM, not a parallel executable.
- Dennie
Date: Tue Aug 31 16:34:23 2004
Message-ID: <41350B05.80201@laposte.net>
Dennie Bastiaan wrote:
> By using xcompmgr for other things than testing and previewing, is functional
> decomposition, because it's the job of the WM, not a parallel executable.
Ok, I fully undestand now... sorry about all this...
Damien
-------------- next part --------------
Name: signature.asc
Size: 252 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040901/2509ff41/signat
ure.pgp
From nemesis-lists at icequake.net Tue Aug 31 17:14:16 2004
From: nemesis-lists at icequake.net (Ryan Underwood)
Date: Tue Aug 31 17:14:20 2004
In-Reply-To: <4134CAD5.5050709@www.linux.org.uk>
<4134CAD5.5050709@www.linux.org.uk>
Message-ID: <20040901001416.GC10195@dbz.icequake.net>
On Tue, Aug 31, 2004 at 03:00:37PM -0400, Mike A. Harris wrote:
> that the hardware is still considered relevant. The R4xx cards are
> current now however, and by the time such drivers might be completed
> under proper funding though and get the kinks worked out, a new
> generation of hardware is likely to be out, and the R300 work will be 2
> or more generations old.
Of course, it's possible that we might see R300 docs once R4xx becomes
more mainstream... we can wish? :)
> work in a reasonable timeframe. People who have the level of skill who
> could pull it off, would probably be hired by a video vendor or other
> hardware vendor before they completed such a complex task, and would
> likely not have the time to dedicate to completing the work.
Funny you mention that. Just the other day I read about a company named
NeoCad who was producing EDA tools in the early 90's. When Xilinx
FPGAs became more popular, they underwent the painstaking process of
reverse engineering the bitstream format that Xilinx's EDA software
created, so that they could target Xilinx parts with their own EDA
software. The long and the short of it is that Xilinx bought NeoCad as
a defensive measure.
Nobody since then has managed to figure out the bitstreams that the big
FPGA vendors use, so it's impossible for us to produce free EDA
toolchains (VHDL/Verilog -> netlist -> encrypted bitstream) for them
unless someone else reproduces the effort. If anyone did such a thing
today (10 years since NeoCad's effort) in the US, they'll either get
hired, bought out, or sued. My money would be on the latter.
--
Ryan Underwood, <nemesis@icequake.net>
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040831/2fa0fc31/attach
ment.pgp
From michel at daenzer.net Tue Aug 31 13:38:52 2004
Date: Tue Aug 31 17:41:54 2004
In-Reply-To: <4134A355.5040807@us.ibm.com>
References: <413103B1.8000202@rocklinux-consulting.de>
<4134A355.5040807@us.ibm.com>
On Tue, 2004-08-31 at 09:12 -0700, Ian Romanick wrote:
> Ren? Rebe wrote:
>
> > just a quick note (not a full conformance test run), that X.Org HEAD
> > runs well on PowerPC and UltraSPARC Linux (both yet unreleased ROCK
> > Linux forks). Since Eric Anholt's Bug #1101 PaintWindow I also do not
> > yet had any screen corruptions anymore.
> >
> > PowerPC:
> > G3, iBook2, Ati/Radeon Mobility M7 LW, Linux 2.6.8.1, gcc-3.2.3
> >
> > XRender ok, Xv: ok, dri: ok, MergedFB: ok
>
> You were able to build on that system without hitting bug #905? If so,
> that means the bug probably only occurs on G4 based systems. Interesting...
I'd rather expect it to depend on the version of FreeType or something
along those lines...
--
From pocm at netvisao.pt Tue Aug 31 17:44:11 2004
From: pocm at netvisao.pt (Paulo Jorge O. C. Matos)
Date: Tue Aug 31 17:50:56 2004
In-Reply-To: <4134EE11.9080007@travellingkiwi.com>
References: <4134EE11.9080007@travellingkiwi.com>
Message-ID: <41351B5B.5050401@netvisao.pt>
Hamie wrote:
>
> What's the chance of having a page on the XOrg (Or freedesktop.org)
> websites that lists the different cards supported by the XOrg server and
> their performance with glxgears or some easy to run benchmark under Linux?
>
That would be extremely nice, however, it would be hard to
benchmark correctly all video cards supported. AFAIK glxgears
FPSs also depends on the CPU and available RAM so, you'd have to
test all the cards on a single PC to have a nice and correct
benchmark.
Correct if I'm wrong.
Cheers,
Paulo J. Matos
> That way people getting burnt by lackluster support from vendors should
> possibly be lessened...
>
> TIA
>
> Hamish.
>
> _______________________________________________
> xorg mailing list
>
--
Paulo J. Matos : pocm [_at_] mega . ist . utl . pt
Instituto Superior Tecnico - Lisbon
Computer and Software Eng. - A.I.
- > http://mega.ist.utl.pt/~pocm
---
-> God had a deadline...
So, he wrote it all in Lisp!
Date: Tue Aug 31 18:48:10 2004
<41351B5B.5050401@netvisao.pt>
Message-ID: <5e7701c48fc5$e55dde40$1e01a8c0@cnt496>
> > What's the chance of having a page on the XOrg (Or freedesktop.org)
> > websites that lists the different cards supported by the XOrg server and
> > their performance with glxgears or some easy to run benchmark under Linux?
> >
>
> That would be extremely nice, however, it would be hard to
> benchmark correctly all video cards supported. AFAIK glxgears
> FPSs also depends on the CPU and available RAM so, you'd have to
> test all the cards on a single PC to have a nice and correct
> benchmark.
>
It shouldn't be too hard to collect the hardware stats to make meaningful
comparisons:
CPU type, speed, amount and speed of cache, video and main memory. It shouldn't
be too hard for a program to gather the stats and submit to a server
automatically. Perhaps even make it an option of the install program, or
something that makes it super simple for 1000's of installations to submit
stats.
Then a vehix.com like site where a person can enter what they do have and see
what configurations will give them a speedy system. For instance, if have a
P2-400, 128 meg, S3 Savage 4, I would like to see what the stats would be for a
(P3-550, 128, S3), or upgrade the memory, or just the card. Wouldn't be too
hard to add in some price factors and I could figure out what the best way to
spend $100.
OK, that seems like a good start of a spec. Is this something that could be
given a wiki page so it can be fleshed out?
Carl K
Date: Tue Aug 31 21:03:18 2004
night.
listed below.
Update:
-------
Blocker bug stats:
------------------
Fixed yesterday: 4
Added yesterday: 5
-----------------------------
* Bug #905: mkfontscale crashes on G4
- Patch needed
- Documentation has begun
is off by default
- Needs patches to config files for systems that require it to be off
* Bug #1155: IEEE_ONE undefined
- Bug reopened to add ARM
- Does this need to be __arm__ or just __arm32__?
- New workaround patch proposed
- Needs review/testing
- Patch provided
- Torrey Lyons is finalizing a self-contained patch to aglGlx.c
patch
* Bug #1216: I810 color problem with DRI driver
- Colors are incorrect with glxgears with DRI enabled
- Is anyone else seeing this problem?
* Bug #1257: Slash key broken on br abnt2 keyboards
From hiryu at audioseek.net Tue Aug 31 21:39:30 2004
Date: Tue Aug 31 21:26:28 2004
In-Reply-To: <5e7701c48fc5$e55dde40$1e01a8c0@cnt496>
<41351B5B.5050401@netvisao.pt> <5e7701c48fc5$e55dde40$1e01a8c0@cnt496>
Hello,
I don't believe that glxgears itself is necessarily a meaningful
benchmark. How about the Unreal Tournament 2004 demo? Or perhaps Enemy
Territory. Clearly, this would only work for PC users though I still
think we would get an excellent idea of where certain video cards stand
under Linux and X.org in general.
I recently found out how to benchmark unreal 2004 in Linux on a gentoo
forum (ran into it through google). Mostly it requires a simple script.
Both unreal tournament 2004 demo and enemy territory are free to
download/use.
Of course, we could still use glxgears additionally.
Just an idea.
-Cameron
On Tue, 2004-08-31 at 18:49, Carl Karsten wrote:
> > > What's the chance of having a page on the XOrg (Or freedesktop.org)
> > > websites that lists the different cards supported by the XOrg server and
> > > their performance with glxgears or some easy to run benchmark under Linux?
> > >
> >
> > That would be extremely nice, however, it would be hard to
> > benchmark correctly all video cards supported. AFAIK glxgears
> > FPSs also depends on the CPU and available RAM so, you'd have to
> > test all the cards on a single PC to have a nice and correct
> > benchmark.
> >
>
> It shouldn't be too hard to collect the hardware stats to make meaningful
> comparisons:
>
> CPU type, speed, amount and speed of cache, video and main memory. It shouldn
't
> be too hard for a program to gather the stats and submit to a server
> automatically. Perhaps even make it an option of the install program, or
> something that makes it super simple for 1000's of installations to submit
> stats.
>
> Then a vehix.com like site where a person can enter what they do have and see
> what configurations will give them a speedy system. For instance, if have a
> P2-400, 128 meg, S3 Savage 4, I would like to see what the stats would be for
a
> (P3-550, 128, S3), or upgrade the memory, or just the card. Wouldn't be too
> hard to add in some price factors and I could figure out what the best way to
> spend $100.
>
> OK, that seems like a good start of a spec. Is this something that could be
> given a wiki page so it can be fleshed out?
>
> Carl K
>
> _______________________________________________
> xorg mailing list
From michel at daenzer.net Tue Aug 31 21:36:12 2004
Date: Tue Aug 31 21:36:05 2004
Message-ID: <1094013373.31459.69.camel@admin.tel.thor.asgaard.local>
On Mon, 2004-08-30 at 18:04 +0200, Francesco Biscani wrote:
>
> - displaying of fonts on screen seems much faster. I tried to do "find /" on a

> console with aa fonts and seemed faster than prevoius version (is this
> because of RenderAccel?)
Yes.
> - transparencies and shadows are still dead slow. Better with RenderAccel, but

> still quite unusable. Is this because the lack of support for component alpha
> rendering in the "radeon" driver?
No. The problem is that the current XAA Render acceleration hook is
inadequate for this usage scenario. Apparently, the plan is to integrate
kaa from kdrive after the release.
--
From ARatnaweera at virtusa.com Tue Aug 31 23:11:13 2004
From: ARatnaweera at virtusa.com (Anuradha Ratnaweera)
Date: Tue Aug 31 23:09:33 2004
Subject: Adding si_LK locale
(Sorry if you got this twice, forgot the attachment last time.)
Hi x.org,
Please apply the following [trivial] patch to the locale/ directory, so that we
can use the si_LK locale without having to patch every box.
This comes from the Sinhala GNU/Linux project: http://sinhala.linux.lk. Current
ly, we run a shell script whenever we install Sinhala on a new box:
http://cvs.linux.lk/cgi-bin/cvsweb/sinhala/locale/install.sh
Thanks.
Anuradha
--
http://www.linux.lk/~anuradha/
--------------------------------------------------------------------------------
------------------
This message, including any attachments, contains confidential information inten
ded for a specific individual and purpose, and is intended for the addressee onl
y. Any unauthorized disclosure, use, dissemination, copying, or distribution of
this message or any of its attachments or the information contained in this e-m
ail, or the taking of any action based on it, is strictly prohibited. If you ar
e not the intended recipient, please notify the sender immediately by return e-m
ail and delete this message.
-------------- next part --------------
Name: si_LK.patch
Type: text/x-patch
Size: 1834 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040901/160a1295/si_LK.
bin
From ARatnaweera at virtusa.com Tue Aug 31 23:06:02 2004
From: ARatnaweera at virtusa.com (Anuradha Ratnaweera)
Date: Tue Aug 31 23:26:49 2004
Subject: Adding si_LK locale
Hi all,
Please add the following [trivial] patch to the locale/ directory, so
that we can use the si_LK locale without having to patch every box.
This comes from the Sinhala GNU/Linux project at
http://sinhala.linux.lk. Currently, we use ed inside a shell script to
patch it:
Thanks.
Anuradha
--
http://www.linux.lk/~anuradha/
--------------------------------------------------------------------------------
------------------
This message, including any attachments, contains confidential information inten
ded for a specific individual and purpose, and is intended for the addressee onl
y. Any unauthorized disclosure, use, dissemination, copying, or distribution of
this message or any of its attachments or the information contained in this e-m
ail, or the taking of any action based on it, is strictly prohibited. If you ar
e not the intended recipient, please notify the sender immediately by return e-m
ail and delete this message.

Xorg Mailing List 2004 August

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xorg Mailing List 2004 August

Uploaded by

Copyright:

Available Formats

From Stuart.Kreitman at Sun.

COM Sun Aug 1 08:49:19 2004

You might also like