From saynte at gmail.com Fri Apr 1 05:14:08 2005 From: saynte at gmail.com (Scott West) Date: Fri, 1 Apr 2005 08:14:08 -0500 Subject: Radeon AIW 9700 functionality In-Reply-To:
On Mar 31, 2005 11:06 PM, Vladimir Dergachev
From ajax at nwnk.net Fri Apr 1 08:17:54 2005 From: ajax at nwnk.net (Adam Jackson) Date: Fri, 1 Apr 2005 11:17:54 -0500 Subject: New X.Org mailing lists are created: xorg-arch and xorg-foundation In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Thursday 17 February 2005 07:10, Mike A. Harris wrote: > Two new mailing lists have recently been created for the X.Org > project, on the lists.freedesktop.org mailman server: > > X.Org Architecture Board discussion > xorg-arch at lists.freedesktop.org > > General (non-technical) X.Org Foundation discussion > xorg-foundation at lists.freedesktop.org > > These lists were recently created on freedesktop.org in order > to migrate the xorg_arch, and xorg_foundation mailing lists > hosted at x.org by TOG to a modern GNU mailman setup which is > widely used by most OSS projects. These were created on February 17, over six weeks ago. The old xorg_arch at x.org list still exists, and is apparently still accepting subscriptions, because people have been posting technical support questions there. Could someone with write access to the x.org web site please change the Subscribe links on http://www.x.org/XOrg_Foundation_Join_OpenLists.html for xorg_arch and xorg_foundation to point to http://lists.x.org/mailman/listinfo/xorg-arch and http://lists.x.org/mailman/listinfo/xorg-foundation ? It would also be nice if the list descriptions were updated slightly to reflect that xorg-arch is for architectural issues concerning the future direction of Xorg and that technical support questions should go to xorg at fd.o. Thanks, - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From cerdiogenes at yahoo.com.br Fri Apr 1 08:46:29 2005 From: cerdiogenes at yahoo.com.br (=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3 genes?=) Date: Fri, 01 Apr 2005 13:46:29 -0300 Subject: where is the virtual screen code? In-Reply-To: <200504011203.25761@sachin> References: <200503311012.11638@sachin> <[email protected] u> <200504011203.25761@sachin> Message-ID: <[email protected]> Hi, I search in the source code of x.org the code where is implemented the virtual screen, but I couldn't find it? Someone knows where it's implemented? Maybe it's not very clear, but the code that I want to see is the one that manage the screen when you press
From alexdeucher at gmail.com Fri Apr 1 12:23:11 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 1 Apr 2005 15:23:11 -0500 Subject: where is the virtual screen code? In-Reply-To: <[email protected]> References: <200503311012.11638@sachin> <[email protected]> <200504011203.25761@sachin> <[email protected]> Message-ID:
From otaylor at redhat.com Fri Apr 1 13:13:15 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 01 Apr 2005 16:13:15 -0500 Subject: finding process id of a window In-Reply-To:
> because it implies that it's a pre-6.8.2 version. It needs to be bumped to > 6.8.99.x to indicate that it's approaching 6.9. Agreed. > I'd like to suggest automatically tagging CVS every two weeks or so with > incremental version numbers, and also generating snapshot tarballs based on > these tags. I'd be happy to set up a cron job to do this automatically if > people think it's a good idea. I don't have a strong opinion either way on automatic tagging and generating tarballs, but it would be nice to verify that the tree is in a buildable state before tagging. However, this would require much more work. Perhaps if we find that a tag is known to be bad, we could just pull the tarballs. I wonder if there is a way to hook this process into tinderbox to have the tarballs test built before they are made available for download. > I'll tag CVS as 6.8.99.1 this weekend. Sounds good. Kevin
From alan at lxorguk.ukuu.org.uk Sat Apr 2 00:46:01 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Sat, 02 Apr 2005 09:46:01 +0100 Subject: finding process id of a window In-Reply-To: <[email protected]> References:
From matthieu.herrb at laas.fr Sat Apr 2 09:01:43 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sat, 02 Apr 2005 19:01:43 +0200 Subject: New X.Org mailing lists are created: xorg-arch and xorg-foundation In-Reply-To: <[email protected]> References: <[email protected]> <[email protected] t> <[email protected]> Message-ID: <[email protected]> Daniel Stone wrote: > On Fri, Apr 01, 2005 at 11:17:54AM -0500, Adam Jackson wrote: > >>It would also be nice if the list descriptions were updated slightly to >>reflect that xorg-arch is for architectural issues concerning the future >>direction of Xorg and that technical support questions should go to >>xorg at fd.o. > > ^^^^^^^^^ > xorg at l.fd.o http://www.freedesktop.org/Software/xorg mentions xorg at fd.o Moreover http://xorg.freedesktop.org/wiki/XorgMailingLists still points to the old lists on x.org (and doesn't mention xorg-modular either). -- Matthieu
From ajax at nwnk.net Sat Apr 2 10:00:18 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sat, 2 Apr 2005 13:00:18 -0500 Subject: New X.Org mailing lists are created: xorg-arch and xorg-foundation In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Saturday 02 April 2005 12:01, Matthieu Herrb wrote: > Daniel Stone wrote: > > On Fri, Apr 01, 2005 at 11:17:54AM -0500, Adam Jackson wrote: > >>It would also be nice if the list descriptions were updated slightly to > >>reflect that xorg-arch is for architectural issues concerning the future > >>direction of Xorg and that technical support questions should go to > >>xorg at fd.o. > > > > ^^^^^^^^^ > > xorg at l.fd.o > > http://www.freedesktop.org/Software/xorg mentions xorg at fd.o > > Moreover http://xorg.freedesktop.org/wiki/XorgMailingLists still points > to the old lists on x.org (and doesn't mention xorg-modular either). Fixed. Yay for wikis. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
I have created Window with XCreateSimpleWindow. I don't want to display title bar for this window. Just like splash screen.
How to achieve this ? Thanks in advance .
-Sachin Programmer Analyst, KamatSoft Pvt. Ltd. www.kamatsoft.com
From roland.mainz at nrubsig.org Sat Apr 2 11:25:37 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat, 02 Apr 2005 21:25:37 +0200 Subject: Using |inline| in X.org codebase / was: Re: Usage of ANSI-C |const| in X11 code... References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Thomas Dickey wrote: > On Thu, Mar 31, 2005 at 02:34:31AM +0200, Roland Mainz wrote: > > I would prefer if the X.org codebase could be compiled with strict > > ANSI-C89 to gurantee maximum portability. If we let it slip now we may > > That would be nice, except that the unusal interpretation of "strict" > makes it not compile with unistd.h What exactly breaks here ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
From dickey at radix.net Sat Apr 2 11:29:39 2005 From: dickey at radix.net (Thomas Dickey) Date: Sat, 2 Apr 2005 14:29:39 -0500 Subject: Using |inline| in X.org codebase / was: Re: Usage of ANSI-C |const| in X11 code... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sat, Apr 02, 2005 at 09:25:37PM +0200, Roland Mainz wrote: > Thomas Dickey wrote: > > On Thu, Mar 31, 2005 at 02:34:31AM +0200, Roland Mainz wrote: > > > I would prefer if the X.org codebase could be compiled with strict > > > ANSI-C89 to gurantee maximum portability. If we let it slip now we may > > > > That would be nice, except that the unusal interpretation of "strict" > > makes it not compile with unistd.h > > What exactly breaks here ? My point was that (lacking additional #define's to turn on features), "strict" ANSI-C89 (or C99, etc), turn off the POSIX features. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL:
Is Xaw3d still maintained? By whom? Can someone put me in touch with the maintainer? Thank you,
Stefan
From ajax at nwnk.net Sat Apr 2 12:37:33 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sat, 2 Apr 2005 15:37:33 -0500 Subject: Looking for the maintainer of Xaw3d In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Saturday 02 April 2005 15:15, Stefan Monnier wrote: > Is Xaw3d still maintained? By whom? Can someone put me in touch with > the maintainer? Thank you, I believe D. J. Hawkey Jr. is still the current maintainer. http://www.visi.com/~hawkeyd/xaw3d.html - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
On Fri, 1 Apr 2005, Adam Jackson wrote: > Currently CVS checkouts report themselves as 6.8.1.99. This is clearly wrong, > because it implies that it's a pre-6.8.2 version. It needs to be bumped to > 6.8.99.x to indicate that it's approaching 6.9. My fault - I changed the number so it does not report as 4.3.99.1, back when 6.8.1 was the only version. > > I'd like to suggest automatically tagging CVS every two weeks or so with > incremental version numbers, and also generating snapshot tarballs based on > these tags. I'd be happy to set up a cron job to do this automatically if > people think it's a good idea. > > I'll tag CVS as 6.8.99.1 this weekend. Great ! Vladimir Dergachev > > - ajax >
From rpetrick at gmail.com Sat Apr 2 13:23:32 2005 From: rpetrick at gmail.com (Ron Petrick) Date: Sat, 2 Apr 2005 16:23:32 -0500 Subject: AIW 9600XT and TV tuner Message-ID:
From ajax at nwnk.net Sat Apr 2 16:12:31 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sat, 2 Apr 2005 19:12:31 -0500 Subject: Looking for the maintainer of Xaw3d In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Saturday 02 April 2005 17:25, Stefan Monnier wrote: > >> Is Xaw3d still maintained? By whom? Can someone put me in touch with > >> the maintainer? Thank you, > > > > I believe D. J. Hawkey Jr. is still the current maintainer. > > > > http://www.visi.com/~hawkeyd/xaw3d.html > > That's also what I expect, but the email address doesn't work > any more. And I can't seem to find any other email address I could use. > Is he still around? Is there a better place to ask this question? This is as good a place as any to ask about it, though Xaw3d isn't really part of Xorg proper. Since he seems to have dropped off the net (last mailing post on 2004-05-12 according to MARC) you'd be welcome to take up maintainership for it. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From eich at freedesktop.org Sun Apr 3 00:45:35 2005 From: eich at freedesktop.org (Egbert Eich) Date: Sun, 3 Apr 2005 10:45:35 +0200 Subject: Building 32-bit server on 64-bit system? In-Reply-To: [email protected] wrote on Wednesday, 30 March 2005 at 18:06:56 -0800 References: <[email protected]> Message-ID: <[email protected]> Ian Romanick writes: > Is there a known incantation, short of using a cross-compiler, to build > a 32-bit i386 server on an 64-bit x86-64 system? > > I tried setting CcCmd (and CplusplusCmd) to "gcc -m32", adding #undef > AMD64Architecture, and adding #define i386Architecture to my hosts.def. > After copying libfl.a from a 32-bit system to /usr/lib, I can get > things most of the way built. However, I'm now hitting problems with > the freetype2 and fontconfig libraries. > > I figure that *someone* must have already gone through this exercise > once by now. You need to do 'make World BOOTSTARAPCFLAGS=-m32' that will build everything 32bit. Likewise on Systems that build everything 32bit by default (like PPC64) you must specify -m64. Egbert.
From bersace03 at free.fr Sun Apr 3 06:11:02 2005 From: bersace03 at free.fr (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Sun, 03 Apr 2005 15:11:02 +0200 Subject: submit a new keymap In-Reply-To:
From roland.mainz at nrubsig.org Sun Apr 3 08:49:19 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 03 Apr 2005 17:49:19 +0200 Subject: submit a new keymap References: <[email protected]>
From ajax at nwnk.net Sun Apr 3 10:28:54 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sun, 3 Apr 2005 13:28:54 -0400 Subject: Heads up on CVS version numbers (bug #2854) In-Reply-To: <1112542347.790.4.camel@bastov> References: <[email protected]> <1112542347.790.4.camel@bastov> Message-ID: <[email protected]> On Sunday 03 April 2005 11:32, Sergio Monteiro Basto wrote: > Great ! > Sorry if it is a dummy question, but where I can find those snapshots ? > > thanks, http://xorg.freedesktop.org/snapshots/xorg-x11-6.8.99.1.tar.bz2 - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
-- Kim Schulz | Keen of Fundanemt? Want to share experieces with Geek by nature | other users? join The Fundanemt User Group NOW! schulz.dk | http://www.fundausers.org
From b_diaconescu at yahoo.com Sun Apr 3 13:18:53 2005 From: b_diaconescu at yahoo.com (Bogdan Diaconescu) Date: Sun, 3 Apr 2005 13:18:53 -0700 (PDT) Subject: AIW 9600XT and TV tuner In-Reply-To: 6667 Message-ID: <[email protected]> You may send the xorg log file. Bogdan --- Ron Petrick
______Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
From alanh at fairlite.demon.co.uk Sun Apr 3 14:02:14 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Sun, 3 Apr 2005 22:02:14 +0100 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Sun, Apr 03, 2005 at 09:03:18PM +0200, Kim Schulz wrote: > Hi, > I recently bought a Zepto Znote 2215w laptop (www.zepto.com), and I'm > how trying to install linux (in this case Mandrake cooker) on it. > When trying to setup X I get into problems. > The X server says: > .... > (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810- > dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G > (II) Primary Device is: PCI 00:02:0 > (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) > found (EE) No devices detected. Kim, This is Intel's latest laptop chipset and X.Org have not yet released a version that supports this chip. The current CVS of X.Org does support it though. So if you can build from source you'll get support for your chip. Alan.
From Alan.Coopersmith at Sun.COM Sun Apr 3 16:03:18 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 03 Apr 2005 16:03:18 -0700 Subject: Using |inline| in X.org codebase / was: Re: Usage of ANSI-C |const| in X11 code... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Thomas Dickey wrote: > On Sat, Apr 02, 2005 at 09:25:37PM +0200, Roland Mainz wrote: > >>Thomas Dickey wrote: >> >>>On Thu, Mar 31, 2005 at 02:34:31AM +0200, Roland Mainz wrote: >>> >>>>I would prefer if the X.org codebase could be compiled with strict >>>>ANSI-C89 to gurantee maximum portability. If we let it slip now we may >>> >>>That would be nice, except that the unusal interpretation of "strict" >>>makes it not compile with unistd.h >> >>What exactly breaks here ? > > > My point was that (lacking additional #define's to turn on features), > "strict" ANSI-C89 (or C99, etc), turn off the POSIX features. And it turns off features like large-file support which require extended types such as 64-bit ints on 32-bit OS'es. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From Alan.Coopersmith at Sun.COM Sun Apr 3 17:30:32 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 03 Apr 2005 17:30:32 -0700 Subject: submit a new keymap In-Reply-To: <[email protected]> References: <[email protected]>
From benh at kernel.crashing.org Sun Apr 3 17:54:53 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 04 Apr 2005 10:54:53 +1000 Subject: [PATCH] radeon: Release DDC i2c lines after probe Message-ID: <1112576093.31872.316.camel@gaston> (Hui: any comment on this one ?) This patch fixes support of recent Apple Cinema Display monitors. Previously, we used to keep the SDA and SDL lines of the i2c "asserted" after probing. This causes those monitor to shut down after a second or so. This patch makes us "release" the line back to hi-z state (and thus pulled high) after we are done probing a connector and fixes the problem with Apple displays. (This should probably be applied to the stable branch as well). Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c ======--- xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-04- 04 10:18:39.000000000 +1000 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-04-04 10:35 :07.000000000 +1000 @@ -1006,6 +1006,9 @@ MonType = MT_NONE; }
+ OUTREG(info->DDCReg, INREG(info->DDCReg) & + ~(RADEON_GPIO_EN_0 | RADEON_GPIO_EN_1)); + if (*MonInfo) { if ((*MonInfo)->rawData[0x14] & 0x80) { /* Note some laptops have a DVI output that uses internal TMDS,
From Yossi.Itzkovich at ecitele.com Sun Apr 3 22:35:11 2005 From: Yossi.Itzkovich at ecitele.com (Yossi.Itzkovich at ecitele.com) Date: Mon, 4 Apr 2005 07:35:11 +0200 Subject: finding process id of a window Message-ID:
From uchman at home.se Sun Apr 3 22:10:44 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 07:10:44 +0200 Subject: Multiple screens. Message-ID: <[email protected]> I have A laptop with an external screen. Is there any way to show two different resolutions on theese two screens at the same time or maybe a way for xorg to swtich automatically when I switch screen. Right now I can't switch at all when I'm in X. The laptop is a Compaq EVO N400c With ATI Rage Mobility. -- MVH Peter Ankerst?l.
From kim at schulz.dk Sun Apr 3 22:12:50 2005 From: kim at schulz.dk (Kim Schulz) Date: Mon, 04 Apr 2005 07:12:50 +0200 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sun, 3 Apr 2005 22:02:14 +0100 Alan Hourihane
Ahh that explains it. I thought that it was covered by the i915 kernel module and i810 xorg module combined. Is there any special parameters I need to add while compiling ?
-- Kim Schulz | Keen of Fundanemt? Want to share experieces with Geek by nature | other users? join The Fundanemt User Group NOW! schulz.dk | http://www.fundausers.org
From ms at suse.de Sun Apr 3 23:41:21 2005 From: ms at suse.de (Marcus =?iso-8859-15?Q?Sch=E4fer?=) Date: Mon, 4 Apr 2005 08:41:21 +0200 Subject: finding process id of a window In-Reply-To:
From volodya at mindspring.com Sun Apr 3 23:47:46 2005 From: volodya at mindspring.com (Vladimir Dergachev) Date: Mon, 4 Apr 2005 02:47:46 -0400 (EDT) Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
On Mon, 4 Apr 2005, Peter [ISO-8859-1] Ankerst?l wrote: > I have A laptop with an external screen. > Is there any way to show two different resolutions on theese two screens > at the same time or maybe a way for xorg to swtich automatically when I > switch screen. > Right now I can't switch at all when I'm in X. > > The laptop is a Compaq EVO N400c > With ATI Rage Mobility. Read up on "MergedFB" options. In particular, here is a snippet from my /etc/X11/xorg.conf : Option "MergedFB" "true" Option "CRT2HSync" "30-80" Option "CRT2VRefresh" "60" Option "CRT2Position" "RightOf" Option "MetaModes" "1920x1200 1280x1024-1280x1024 960x600_60-800x600" (this goes into the "Device" section). best Vladimir Dergachev
> > -- > MVH > Peter Ankerst?l. > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From alanh at fairlite.demon.co.uk Mon Apr 4 01:34:12 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 4 Apr 2005 09:34:12 +0100 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 04, 2005 at 07:12:50AM +0200, Kim Schulz wrote: > On Sun, 3 Apr 2005 22:02:14 +0100 > Alan Hourihane
From kim at schulz.dk Mon Apr 4 03:08:45 2005 From: kim at schulz.dk (Kim Schulz) Date: Mon, 04 Apr 2005 12:08:45 +0200 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> [snip] > > > This is Intel's latest laptop chipset and X.Org have not yet > > > released a version that supports this chip. The current CVS of > > > X.Org does support it though. So if you can build from source > > > you'll get support for your chip. > > > > > > Ahh that explains it. I thought that it was covered by the i915 > > kernel module and i810 xorg module combined. > > It is covered by the same modules, but they've been updated to support > the i915GM. > > > Is there any special parameters I need to add while compiling ? > > Nope. so now I got it to compile (missed the libpng3-devel package) but the output is the same. See my new Xorg.0.log here: http://www.cs.aau.dk/~kim/Xorg.0.log Any ideas of what is wrong now? The xorg.conf is the same as mentioned earlier. -- Kim Schulz | Linux - Your Choice! Your Opinion! Your life! Geek by nature | schulz.dk |
From alanh at fairlite.demon.co.uk Mon Apr 4 03:12:22 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 4 Apr 2005 11:12:22 +0100 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 04, 2005 at 12:08:45PM +0200, Kim Schulz wrote: > [snip] > > > > This is Intel's latest laptop chipset and X.Org have not yet > > > > released a version that supports this chip. The current CVS of > > > > X.Org does support it though. So if you can build from source > > > > you'll get support for your chip. > > > > > > > > > Ahh that explains it. I thought that it was covered by the i915 > > > kernel module and i810 xorg module combined. > > > > It is covered by the same modules, but they've been updated to support > > the i915GM. > > > > > Is there any special parameters I need to add while compiling ? > > > > Nope. > > > so now I got it to compile (missed the libpng3-devel package) but the > output is the same. > > See my new Xorg.0.log here: > http://www.cs.aau.dk/~kim/Xorg.0.log > > Any ideas of what is wrong now? > > The xorg.conf is the same as mentioned earlier. You've not done a 'make install' after building the CVS as a lot of your modules are still saying they are '6.8.2' and shouldn't if it's the CVS - especially the i810_drv.o. Alan.
From michel at daenzer.net Mon Apr 4 07:32:12 2005 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Mon, 04 Apr 2005 10:32:12 -0400 Subject: does i915 support have a problem with screens In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <1112625132.5665.115.camel@localhost> On Mon, 2005-04-04 at 11:12 +0100, Alan Hourihane wrote: > On Mon, Apr 04, 2005 at 12:08:45PM +0200, Kim Schulz wrote: > > > > so now I got it to compile (missed the libpng3-devel package) but the > > output is the same. > > > > See my new Xorg.0.log here: > > http://www.cs.aau.dk/~kim/Xorg.0.log > > > > Any ideas of what is wrong now? > > > > The xorg.conf is the same as mentioned earlier. > > You've not done a 'make install' after building the CVS as a lot of > your modules are still saying they are '6.8.2' and shouldn't if it's > the CVS - especially the i810_drv.o. HEAD defaults to dlloader (*.so) modules and you have to move any *.o *.a modules out of the way due to https://bugs.freedesktop.org/show_bug.cgi?id=2138 .
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From alexdeucher at gmail.com Mon Apr 4 09:12:16 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 12:12:16 -0400 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From uchman at home.se Mon Apr 4 10:34:48 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 19:34:48 +0200 Subject: Multiple screens. In-Reply-To:
> > which rage mobility do you have (mach64, r128, radeon)? dualhead is > not supported on teh mach64 based chips yet. > > Alex > I dont really know. But google tells me ATI Rage Mobility M1. And in windows I used the Rage 128 / 128 PRO drivers. -- MVH Peter Ankerst?l.
From uchman at home.se Mon Apr 4 11:13:20 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 20:13:20 +0200 Subject: Multiple screens. In-Reply-To:
> > which rage mobility do you have (mach64, r128, radeon)? dualhead is > not supported on teh mach64 based chips yet. > > Alex > The manual says: ATI Mobility M1, 8-MB SDRAM. -- MVH Peter Ankerst?l.
From alexdeucher at gmail.com Mon Apr 4 11:56:53 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 14:56:53 -0400 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]>
From lehmann at ans-netz.de Mon Apr 4 12:31:29 2005 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Mon, 4 Apr 2005 21:31:29 +0200 Subject: nvidia 6200TC + nv + dualhead? Message-ID: <[email protected]> Hi, I want to buy an amd64 board with ePCI in the near future. I'm not able to use my old Matrox 400-DH anyway with amd64 since matrox only hands out a 32bit driver which I need to get DualHead to work. I need to buy a new graphic card, and I want to buy a card which gives me my lovly DualHead back, and doesn't disturbs my environment with a fan. I think nvidia's 6200TC chipset will give me all this. So all I need to know now is - will a 6200TC card work with xorg's nv driver in dualhead mode on amd64 (an FreeBSD if that matters)? If not - is someone aware of another ePCI card which gives me those 2 "features", is ePCI and on the market?
Greetings, Oliver -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/
From uchman at home.se Mon Apr 4 12:40:16 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 21:40:16 +0200 Subject: Multiple screens. In-Reply-To:
From lennox at cs.columbia.edu Mon Apr 4 12:51:13 2005 From: lennox at cs.columbia.edu (Jonathan Lennox) Date: Mon, 4 Apr 2005 15:51:13 -0400 Subject: X[Shm]GetImage is slow; what can I do about this? Message-ID: <[email protected]> As I've mentioned before on this list, I'm working on an X-based server for the protocol defined in the Internet-Draft
From alexdeucher at gmail.com Mon Apr 4 12:56:32 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 15:56:32 -0400 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]>
From alexdeucher at gmail.com Mon Apr 4 13:00:40 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 16:00:40 -0400 Subject: nvidia 6200TC + nv + dualhead? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From uchman at home.se Mon Apr 4 13:21:47 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 22:21:47 +0200 Subject: Multiple screens. In-Reply-To:
> doesn't matter. dualhead and clone work the same way. The only > difference is the framebuffer offsets for the crtcs. They are either > the same (clone) or different (dualhead). > > Alex > I can run both screens in 1024x768 (max for the interna screen) if I start X wit h the laptop lid(?) open. But I want to be able to switch to the external screen without restarting X.
-- MVH Peter Ankerst?l.
From alexdeucher at gmail.com Mon Apr 4 13:37:03 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 16:37:03 -0400 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]>
From uchman at home.se Mon Apr 4 13:53:27 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 22:53:27 +0200 Subject: Multiple screens. In-Reply-To:
> > Yes, crtc1 is driving both displays. both the LCD and the VGA port > are getting the same mode, probably 1024x768 at 60hz. If you want to run > the LCD at say 1024x768 at 60hz and the VGA port at say 1280x1024 at 75hz, > you will need to program both crtcs (crt/display controllers); one for > each output. if you just want to use one crtc to drive either the vga > port or the lcd, there's not really an easy way to use modes beyond > the capabilites of the attached monitors after X is started. > If i start two x-sessions I can run one on each screen. The one i run in 1024x768 Is on both screens because both screens support it. And the other sessi on runs 1280x1024 And is only displayed on the external screen. (1280x1024 is not supported by the internal screen). It must be a way to do this but with only one x-session.
-- MVH Peter Ankerst?l.
From alexdeucher at gmail.com Mon Apr 4 14:05:38 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 4 Apr 2005 17:05:38 -0400 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]>
From uchman at home.se Mon Apr 4 14:13:40 2005 From: uchman at home.se (Peter =?ISO-8859-1?Q?Ankerst=E5l?=) Date: Mon, 4 Apr 2005 23:13:40 +0200 Subject: Multiple screens. In-Reply-To:
From ajax at nwnk.net Mon Apr 4 15:28:06 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 4 Apr 2005 18:28:06 -0400 Subject: Change list from 6.8 to HEAD, and 7.0 plans Message-ID: <[email protected]> One of the complaints I've heard from people is that it's hard to get a feel for what's been happening in X, for people who aren't brave enough to read ChangeLogs directly. I found myself reviewing the ChangeLog for patches that had made it into 6.8.2 but not head (and found a few, unfortunately), so I wrote a quickie overview of the major changes between 6.8 and HEAD: http://xorg.freedesktop.org/wiki/ChangesSince68 If you do something major - or have done something major that's not listed - please add it to the list. Ideally we can write this as we go for the next and future releases, so we don't have as much of a documentation task doing the release notes. I'd like people to start thinking about (and preferably announcing) the features they're working to get into 7.0, so users and vendors have an idea of what to expect besides "bugfixes and better build system". Obviously these aren't necessarily commitments, but they should give us and the community a better idea of what we're doing and where we're going. In the spirit of fairness, I'll start: - Altix platform support - Multiseat support - DRI-based indirect GLX (probably software-only for now) This brings up the question of release date. Anyone have strong feelings about this? We've already missed the six month mark from 6.8.0 given the massive 6.8.2 effort. I would suggest August at the latest, and preferably July. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From dicej at mailsnare.net Mon Apr 4 16:24:54 2005 From: dicej at mailsnare.net (Joel Dice) Date: Mon, 4 Apr 2005 17:24:54 -0600 (MDT) Subject: X[Shm]GetImage is slow; what can I do about this? In-Reply-To:
On Mon, 4 Apr 2005, Joel Dice wrote: > On Mon, 4 Apr 2005, Jonathan Lennox wrote: > >> As I've mentioned before on this list, I'm working on an X-based server for >> the protocol defined in the Internet-Draft >>
From ajax at nwnk.net Mon Apr 4 18:25:40 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 4 Apr 2005 21:25:40 -0400 Subject: Change list from 6.8 to HEAD, and 7.0 plans In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Monday 04 April 2005 18:58, Daniel Stone wrote: > On Mon, Apr 04, 2005 at 06:28:06PM -0400, Adam Jackson wrote: > > This brings up the question of release date. Anyone have strong feelings > > about this? We've already missed the six month mark from 6.8.0 given the > > massive 6.8.2 effort. I would suggest August at the latest, and > > preferably July. > > I don't think July is realistic, given it's now April and we're still > sitting here, with a whole bunch of work to do, talking about when to > try to release. Fair enough. Here's a strawman, targetted at August 19, which is just over 19 weeks out: June 10: Code slush. Any big changes should start stabilizing. June 24: Feature freeze. Patches should be bugfix only and preferably through subsystem maintainers where they exist. Begin writing release notes and doc updates. July 8: RC1. Code freeze for all but approved patches, fairly open approval stance. July 22: RC2. Patch approval for crashes, correctness, regressions, build fixes only. Docs should be basically done. August 5: RC3. Approval for showstoppers only. August 19: 6.9 / 7.0. 6.9 enters immediate maintenance mode, HEAD in xc/ is for 6.9.x releases only. 7.0 modules open for new development. That's two weeks for each cycle, which I think is reasonable. It also allows about two weeks of slip before we hit September, and 10-12 weeks of open commits before we start serious release mode. The modular tree's time frame is somewhat dependent on the exact schedule we aim for, but I would like to see it at about 90% completion by the code slush point for all the major platforms, where "major" is: Linux, Solaris, at least one BSD, OSX, and Win32. (Other platforms are welcome and encouraged to shoot for completion by that date too, of course.) The development plan for modular is basically the bootstrap order: protocol headers, libs, server, apps. I would expect these to proceed in rough order for each platform, but that different platforms could be at different stages in the process. Given that, and the above timeline, I would say the following would be worst-case dates for finishing each step: (note that platform-specific fixes can go in during the release cycle) May 13: headers May 27: libs June 10: server June 24: apps That's just over five weeks to have all the headers filled in, which sounds quick. Balancing this is that it's a fairly mechanical process, we have quite a few hands to do it, and that we have a lot of this already done in the existing proof-of-concept. I'm up for the challenge, I'm just waiting for the arch group to give me the green light ;). Unfortunately since the modular trees will host new development going forward, there's really no way to make a development branch early, where I'd like to do it at about the RC1 mark. I'm willing to pay that price for what it buys us. It sounds rapid, but it's also almost five months. If we can't go from open tree to released in five months we're doing something wrong. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
Thanks Marcus, How can I know (in advance) that my window manager supports this property ? I use dtwm (wich CDE). Thanks Yossi
Marcus Sch?fer
Hi, > I have few X applications, started from the command line with identical > command line, but each has a different DISPLAY environment variable. > Is there a way to get the process id of a process from its window ? > > Using xlsclients I can get the command line of the application, but since > all of them use same command line, I can't find unique process id. > > Thanks for your help. maybe the _NET_WM_PID property can help here: ...... please note this will only work if the _NET_WM_PID property can be accessed and thus a windowmanager doing this is required. Regards Marcus From michel at daenzer.net Mon Apr 4 21:09:51 2005 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Tue, 05 Apr 2005 00:09:51 -0400 Subject: X[Shm]GetImage is slow; what can I do about this? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1112674192.5665.139.camel@localhost> On Mon, 2005-04-04 at 15:51 -0400, Jonathan Lennox wrote: > > Some Googling seems to indicate that XGetImage slowness comes about because > the X server keeps screen images in video RAM, not main memory, and video > cards don't tend to be optimized for uploading images to the CPU. > > So my questions are: > 1. Is this true? And is my experience typical? Yes, this is true in the absence of hardware acceleration for GetImage, which only few drivers provide. > 2. Is there anything that can be done about this, for instance some way to > convince the X server to keep a mirrored copy of a window in main memory? > (Could XComposite be of use here?) For now maybe, but eventually the window contents will live in video RAM as well with composite. ShadowFB or backing store might be other ways to achieve an improvement, but they both need to be enabled in the X server configuration.
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From lehmann at ans-netz.de Mon Apr 4 23:18:27 2005 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Tue, 5 Apr 2005 08:18:27 +0200 Subject: nvidia 6200TC + nv + dualhead? In-Reply-To:
-- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/
From mark.carey at gmail.com Mon Apr 4 23:28:00 2005 From: mark.carey at gmail.com (Mark Carey) Date: Tue, 5 Apr 2005 18:28:00 +1200 Subject: Building X.org 6.8.2 freetype related question ..... Message-ID: <[email protected]> Hi, Possibly related to bug #2061, https://bugs.freedesktop.org/show_bug.cgi?id=2061 I am trying to build X.org 6.8.2 and am getting erors related to what my c experience tells me are missing header files, rm -f xrender.pc sh ../Xcursor/config-subst prefix="/usr/local/X11R6" exec_prefix="/usr/local/X11R6/bin" libdir="/usr/local/X11R6/lib" includedir="/usr/local/X11R6/include" VERSION="0.8.4" X_REQUIRES="" RENDER_CFLAGS="" X_NON_PKG_CFLAGS="" X_NON_PKG_LIBS="-lX11 -lXext" < xrender.pc.in > xrender.pc make[4]: Leaving directory `/sources/xcbuild/lib/Xrender' making all in lib/Xft1... make[4]: Entering directory `/sources/xcbuild/lib/Xft1' rm -f xftcfg.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -march=i686 -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 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DFREETYPE2 -DXFREE86_FT2 -fPIC xftcfg.c In file included from XftFreetype.h:29, from xftint.h:31, from xftcfg.c:28: /usr/local/include/ft2build.h:56:38: freetype/config/ftheader.h: No such file or directory In file included from xftint.h:31, from xftcfg.c:28: XftFreetype.h:30:10: #include expects "FILENAME" or
From ms at suse.de Tue Apr 5 00:03:57 2005 From: ms at suse.de (Marcus =?iso-8859-15?Q?Sch=E4fer?=) Date: Tue, 5 Apr 2005 09:03:57 +0200 Subject: finding process id of a window In-Reply-To:
From dusty at qwer.tk Tue Apr 5 00:40:30 2005 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Tue, 5 Apr 2005 09:40:30 +0200 Subject: Memory leak in xorg-6.8.1? Message-ID: <[email protected]> Hi, I am using SuSE 9.2 with the contributed xorg-6.8.1-15. When running the new Adobe Reader 7beta, the process "X" starts to eat up all available memory and also the swap space. I have a NVidia Geforce-4600 Graphic card with the driver version "1.0-7174" from the NVidia Web Site. "ps" outputs this: root 5815 8.7 46.3 726484 359404 ? SL 07:21 11:23 /usr/X11R6/bin/X When opening some .pdf-files the RSS-size increases: root 5815 8.7 47.5 726484 368724 ? SL 07:21 11:33 /usr/X11R6/bin/X When heavily working with the Adobe Reader the swap space gets filled up and the machine is getting very slow. When closing the Adobe Reader the RSS-size stays roughly the same. It seems that also other applications, like Firefox trigger this problem, when surfing a lot, the XOrg memory usage is getting high, although when closing Firefox there is also memory freed - but not all. Maybe that there are some bugs in the Adobe Reader/Firefox but to my mind this is also a XOrg problem. Are there any known fixes to my problem? Best Regards, Hermann -- x1 at aon.at GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
From l.lunak at suse.cz Tue Apr 5 00:47:02 2005 From: l.lunak at suse.cz (Lubos Lunak) Date: Tue, 5 Apr 2005 09:47:02 +0200 Subject: finding process id of a window In-Reply-To: <[email protected]> References:
From dusty at qwer.tk Tue Apr 5 00:55:10 2005 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Tue, 5 Apr 2005 09:55:10 +0200 Subject: Slow scrolling with Firefox -> maybe a XOrg problem? Message-ID: <[email protected]> Hi, I am experiencing very slow scrolling with Mozilla/Firefox (both Mozilla and Firefox, all recent versions) on specific web sites. My System is SuSE 9.2 with XOrg 6.8.1-15 and the nvidia driver "1.0-7174". My System is a Athlon XP 1600+. I am not sure if this is an Xorg or Firefox/Mozilla/Gecko issue, but to my mind XOrg is behaving strange. On specific sites (also very simple ones, like this): http://www.w3.org/TR/soap/ Scrolling is very, very slow. When scrolling and looking at "top", it shows that the firefox binary is nearly idle but the process "X" is consuming the whole CPU time.: Tasks: 92 total, 2 running, 90 sleeping, 0 stopped, 0 zombie Cpu(s): 92.4% us, 1.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 1.0% hi, 5.6% si Mem: 775684k total, 647640k used, 128044k free, 19676k buffers Swap: 1052248k total, 73332k used, 978916k free, 216932k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5815 root 25 0 619m 279m 332m R 95.6 36.9 12:55.04 X 7132 dusty 15 0 75232 40m 42m S 2.3 5.3 0:10.70 firefox-bin When shutting off the CSS-Stylesheet, the situation changes: Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie Cpu(s): 86.0% us, 2.0% sy, 0.0% ni, 10.4% id, 0.0% wa, 1.3% hi, 0.3% si Mem: 775684k total, 649228k used, 126456k free, 19968k buffers Swap: 1052248k total, 73332k used, 978916k free, 216932k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5815 root 16 0 619m 281m 332m S 59.4 37.1 13:11.20 X 7132 dusty 16 0 75668 40m 42m S 23.2 5.3 0:13.86 firefox-bin X is consuming far less of the CPU and the scrolling is very fast. I tried many things like enabling/disabling Firefox smooth scrolling, dropping all Firefox preferences and restarting it with it's default profile, using Firefox without a windowmanager (just start X11 and Firefox, no Window manager) and so on. Do you have any clue? Best Regards, Hermann -- x1 at aon.at GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
From daniel at fooishbar.org Tue Apr 5 00:50:49 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 5 Apr 2005 17:50:49 +1000 Subject: Xdmx COPYING,1.1,1.2 In-Reply-To: <1108841664.878.2.camel@leguin> References: <[email protected]> <1108841664.878.2.camel@leguin> Message-ID: <[email protected]> On Sat, Feb 19, 2005 at 11:34:24AM -0800, Eric Anholt wrote: > On Sat, 2005-02-19 at 10:23 -0800, Chris Lee wrote: > > Committed by: clee > > > > Update of /cvs/xlibs/Xdmx > > In directory gabe:/tmp/cvs-serv10797 > > > > Modified Files: > > COPYING > > Log Message: > > Altered the COPYING file to reflect the proper license of the source. Still > > unsure as to exactly how the GPL ended up in that file. > > Our good friend automake will spam your source with a GPL in COPYING if > you don't explicitly tell it not to, or place your own there beforehand. > I have no idea how they can try to justify that. Because it's a GNU project, and GNU aim to be rather viral in nature (witness, for example, the GNU/Linux crusade). It's designed out of the box for GNU projects; if you set AUTOMAKE_OPTIONS=foreign (as you should anyway) in Makefile.am, it won't do this. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
Ah, yes you are right it's an application specific property sorry my fault Regards Marcus -- Public Key available ------Marcus Sch?fer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 N?rnberg http://www.suse.de Germany ------
From jogall at gmail.com Tue Apr 5 02:24:29 2005 From: jogall at gmail.com (Jonas Gall) Date: Tue, 5 Apr 2005 11:24:29 +0200 Subject: finding process id of a window In-Reply-To:
From ulrichml at norbisrath.de Tue Apr 5 02:53:30 2005 From: ulrichml at norbisrath.de (Ulrich Norbisrath) Date: Tue, 5 Apr 2005 11:53:30 +0200 Subject: starting points for implementing RANDR for Xvfb Message-ID: <[email protected]> Hi again, I hope, this question is easier to answer. For implementing a persistent resizable Desktop, I need to implement xrandr into Xvfb. Are there any starting points/ short docs/ or tutorials how RANDR should be added to an X-Server? What has to be done? Even a rough guide would help. Thanks Uli
From dick at kniep.nl Tue Apr 5 06:56:18 2005 From: dick at kniep.nl (dick at kniep.nl) Date: Tue, 5 Apr 2005 13:56:18 +0000 Subject: Problems compiling with QT on Slackware 10.1 Message-ID: <[email protected]> Hi list, We have a problem compiling KDE (and other programs) with Qt on Slackware 10.1 ? Included is a part of config.log ?------//------?configure:29440: rm -rf SunWS_cache; g++ -o conftest -Wnon-virtual-dtor ?-Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align ?-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 ?-fno-exceptions -fno-check-new -fno-common -I/usr/lib/qt/include ?-I/usr/X11R6/include ?-DQT_THREAD_SUPPORT ?-D_REENTRANT ?-L/usr/lib/qt/lib ?-L/usr/X11R6/lib -Wl,--as-needed -Wl,--enable-new-dtags ? conftest.cc ? ?-lqt-mt -lpng -lz -lm -ljpeg -ldl ?-lXext -lX11 -lSM -lICE ?-lpthread 1>&5 ?/usr/X11R6/lib/libfontconfig.so.1: undefined reference to ?`FT_Get_BDF_Property' After this ./configure gets confused and says that Qt has not been compiled with thread support which is not true. It looks as if libfontconfig.so.1 is not compiled for this version. But I have made a clean install from the downloaded version of Slackware. So has anyone any idea what I should do to get rid of this problem? Cheers, D.Kniep
From Alan.Coopersmith at Sun.COM Tue Apr 5 07:59:03 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Tue, 05 Apr 2005 07:59:03 -0700 Subject: finding process id of a window In-Reply-To: <[email protected]> References:
From mcnichol at austin.ibm.com Tue Apr 5 08:19:55 2005 From: mcnichol at austin.ibm.com (mcnichol at austin.ibm.com) Date: Tue, 5 Apr 2005 10:19:55 -0500 Subject: finding process id of a window Message-ID: <[email protected]> > Date: Tue, 05 Apr 2005 07:59:03 -0700 > From: Alan Coopersmith
From ajax at nwnk.net Tue Apr 5 08:55:45 2005 From: ajax at nwnk.net (Adam Jackson) Date: Tue, 5 Apr 2005 11:55:45 -0400 Subject: Building X.org 6.8.2 freetype related question ..... In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Tuesday 05 April 2005 02:28, Mark Carey wrote: > My system already has freetype installed...... > > [root at jersey:/sources]# which freetype-config > /usr/local/bin/freetype-config > > [root at jersey:/sources]# freetype-config --cflags > -I/usr/local/include/freetype2 -I/usr/local/include > > [root at jersey:/sources]# pkg-config --cflags freetype2 > -I/usr/local/include/freetype2 It's a shame Xorg doesn't look at pkg-config flags yet. > However looking at the above build output (make World after a make > distclean in a lndir'ed directory) it would appear gcc has been > instructed to look for freetype in /usr rather than /usr/local. > > My host.def contains > > #define HasFreetype2 YES > > Why isnt the imake system finding freetype? Does the build system > assume freetype installed in /usr? Yes. Hooray for imake. As a workaround, add this to your host.def: #define Freetype2Dir /usr/local - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From adao-listas at lesc.ufc.br Tue Apr 5 11:21:36 2005 From: adao-listas at lesc.ufc.br (Adao Henrique) Date: Tue, 05 Apr 2005 15:21:36 -0300 Subject: Radeon Dual Head Message-ID: <[email protected]> Hi, I'm trying to use a dual-head card with two diferent Xservers, but I can't make the driver init only the secondary head. It just inits the primary head or both heads. Is there anyway to init just the secondary head?? Thanks, Adao Henrique
From adao-listas at lesc.ufc.br Tue Apr 5 11:27:25 2005 From: adao-listas at lesc.ufc.br (Adao Henrique) Date: Tue, 05 Apr 2005 15:27:25 -0300 Subject: Error loading external library Message-ID: <[email protected]> Hi, I'm trying to modify RAC source so it can work with multiple Xservers. But I'm having some trouble compiling it. I need to use pthreads and some socket, but I just don't how to make it work, it's not loading libpthread.so. Can anyone give some hint about it? Thanks, Adao Henrique
From ateixeira at insignesoftware.com Tue Apr 5 12:26:08 2005 From: ateixeira at insignesoftware.com (Alexandre Teixeira) Date: Tue, 05 Apr 2005 16:26:08 -0300 Subject: Radeon Dual Head In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1112729168.26198.24.camel@srbug> Em Ter, 2005-04-05 ?s 15:21 -0300, Adao Henrique escreveu: Hi Ad?o and Members, > Hi, > > I'm trying to use a dual-head card with two diferent Xservers, Your card is dual-head or you have two card's independently ? I have one project in Brasil with six-head (six nvidia card's independently). Look this URL: http://www.insignesoftware.com/produtos/sixsystem.php Packages download: http://oraculo.insignesoftware.com/current/Six- System/
> but I > can't make the driver init only the secondary head. It just inits the > primary head or both heads. > > Is there anyway to init just the secondary head?? If your project is similar get packages src and good luck.
[]'s Alexandre Penasso Teixeira > > Thanks, > Adao Henrique > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > >
From lennox at cs.columbia.edu Tue Apr 5 12:50:32 2005 From: lennox at cs.columbia.edu (Jonathan Lennox) Date: Tue, 5 Apr 2005 15:50:32 -0400 Subject: X[Shm]GetImage is slow; what can I do about this? In-Reply-To:
From petekarl at student.chalmers.se Tue Apr 5 13:04:32 2005 From: petekarl at student.chalmers.se (Peter Karlsson) Date: Tue, 5 Apr 2005 22:04:32 +0200 (MEST) Subject: Change list from 6.8 to HEAD, and 7.0 plans In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From anton at truxtar.com Tue Apr 5 15:04:05 2005 From: anton at truxtar.com (Anton Markov) Date: Tue, 05 Apr 2005 18:04:05 -0400 Subject: Memory leak in xorg-6.8.1? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Hermann Himmelbauer wrote: > Hi, > I am using SuSE 9.2 with the contributed xorg-6.8.1-15. When running the new > Adobe Reader 7beta, the process "X" starts to eat up all available memory and > also the swap space. I have a NVidia Geforce-4600 Graphic card with the > driver version "1.0-7174" from the NVidia Web Site. > > "ps" outputs this: > > root 5815 8.7 46.3 726484 359404 ? SL 07:21 > 11:23 /usr/X11R6/bin/X > > When opening some .pdf-files the RSS-size increases: > > root 5815 8.7 47.5 726484 368724 ? SL 07:21 > 11:33 /usr/X11R6/bin/X > > When heavily working with the Adobe Reader the swap space gets filled up and > the machine is getting very slow. > > When closing the Adobe Reader the RSS-size stays roughly the same. > > It seems that also other applications, like Firefox trigger this problem, when
> surfing a lot, the XOrg memory usage is getting high, although when closing > Firefox there is also memory freed - but not all. > > Maybe that there are some bugs in the Adobe Reader/Firefox but to my mind this
> is also a XOrg problem. > > Are there any known fixes to my problem? > > Best Regards, > Hermann > It's caused by using a cursor theme with animated cursors :( See:
-- Anton Markov <("anton" + "@" + "truxtar" + "." + "com")> GnuPG Key fingerprint = 5546 A6E2 1FFB 9BB8 15C3 CE34 46B7 8D93 3AD1 44B4 *** LINUX - MAY THE SOURCE BE WITH YOU! ***
From jaymz at artificial-stupidity.net Tue Apr 5 16:31:31 2005 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Wed, 6 Apr 2005 09:31:31 +1000 Subject: finding process id of a window In-Reply-To: <[email protected]>; from [email protected] on Mon, Apr 04, 2005 at 08:41:21AM +0200 References:
From lachlan at lkla.dhs.org Tue Apr 5 20:14:42 2005 From: lachlan at lkla.dhs.org (Lachlan Michael) Date: Wed, 6 Apr 2005 12:14:42 +0900 (JST) Subject: nv driver fails with Xorg 6.8.2 (GeForce FX 5200/FreeBSD) Message-ID: <[email protected]> Dear All, After an upgrade from Xorg 6.8.2 to Xorg 6.8.2 on FreeBSD 5.3 (Stable) I have been unable to get the X server to start. The card (NVidia GeForce FX 5200) seems to be detected correctly, but the X server core dumps with no useful message (to me, anyway). I want to use the native nv driver. Please see the attached log and configuration file. The files are also at http://lachlan.lkla.dhs.org/xorg_problems/ in case they are stripped from this mail. The driver and card worked fine with 6.8.0 and 6.8.1 (and with XFree86 4.x before that) so I suspect that something has changed with the recent changes to the nv driver as mentioned in the Release Notes. The problem began to occur after a routine portupgrade on FreeBSD (which I assume included that 6.8.2 files). The machine in question also has Windows 200 installed dual-boot, so hardware problems can probably be ruled out. Is there some setting that I have missed or that I should try? I'd be grateful for any help. Thanks. Lachlan ------next part ------A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 26352 bytes Desc: not available URL:
-- Kim Schulz | Keen of Fundanemt? Want to share experieces with Geek by nature | other users? join The Fundanemt User Group NOW! schulz.dk | http://www.fundausers.org
From alanh at fairlite.demon.co.uk Wed Apr 6 04:11:01 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Wed, 6 Apr 2005 12:11:01 +0100 Subject: dri and the 915GM chipset In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Wed, Apr 06, 2005 at 12:51:29PM +0200, Kim Schulz wrote: > I have xorg CVS version (3 days old) up and running with the i915GM > chipset in my laptop. > however it trows alot of errors about DRI and I was wondering wether > there is support for this or not at this moment? You need to make sure you are using a kernel with i915GM support too. >From the error messages you're not. Alan.
From dicej at mailsnare.net Wed Apr 6 08:25:46 2005 From: dicej at mailsnare.net (Joel Dice) Date: Wed, 6 Apr 2005 09:25:46 -0600 (MDT) Subject: X[Shm]GetImage is slow; what can I do about this? In-Reply-To: <[email protected]> References: <[email protected]>
From alexdeucher at gmail.com Wed Apr 6 10:37:17 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Wed, 6 Apr 2005 13:37:17 -0400 Subject: Radeon Dual Head In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From clee at freedesktop.org Wed Apr 6 14:57:00 2005 From: clee at freedesktop.org (Chris Lee) Date: Wed, 06 Apr 2005 17:57:00 -0400 Subject: Change list from 6.8 to HEAD, and 7.0 plans In-Reply-To: <[email protected]> References: <[email protected]> <[email protected] oishbar.org> <[email protected]> Message-ID: <[email protected]> Adam Jackson wrote: > On Monday 04 April 2005 18:58, Daniel Stone wrote: > >>On Mon, Apr 04, 2005 at 06:28:06PM -0400, Adam Jackson wrote: >> >>>This brings up the question of release date. Anyone have strong feelings >>>about this? We've already missed the six month mark from 6.8.0 given the >>>massive 6.8.2 effort. I would suggest August at the latest, and >>>preferably July. >> >>I don't think July is realistic, given it's now April and we're still >>sitting here, with a whole bunch of work to do, talking about when to >>try to release. > > > Fair enough. Here's a strawman, targetted at August 19, which is just over 19
> weeks out: > > June 10: Code slush. Any big changes should start stabilizing. > June 24: Feature freeze. Patches should be bugfix only and preferably > through subsystem maintainers where they exist. Begin writing > release notes and doc updates. > July 8: RC1. Code freeze for all but approved patches, fairly open > approval stance. > July 22: RC2. Patch approval for crashes, correctness, regressions, build > fixes only. Docs should be basically done. > August 5: RC3. Approval for showstoppers only. > August 19: 6.9 / 7.0. 6.9 enters immediate maintenance mode, HEAD in xc/ is > for 6.9.x releases only. 7.0 modules open for new development. > > That's two weeks for each cycle, which I think is reasonable. It also allows > about two weeks of slip before we hit September, and 10-12 weeks of open > commits before we start serious release mode. > > The modular tree's time frame is somewhat dependent on the exact schedule we > aim for, but I would like to see it at about 90% completion by the code slush > point for all the major platforms, where "major" is: Linux, Solaris, at least > one BSD, OSX, and Win32. (Other platforms are welcome and encouraged to > shoot for completion by that date too, of course.) > > The development plan for modular is basically the bootstrap order: protocol > headers, libs, server, apps. I would expect these to proceed in rough order > for each platform, but that different platforms could be at different stages > in the process. Given that, and the above timeline, I would say the > following would be worst-case dates for finishing each step: (note that > platform-specific fixes can go in during the release cycle) > > May 13: headers > May 27: libs > June 10: server > June 24: apps > > That's just over five weeks to have all the headers filled in, which sounds > quick. Balancing this is that it's a fairly mechanical process, we have > quite a few hands to do it, and that we have a lot of this already done in > the existing proof-of-concept. I'm up for the challenge, I'm just waiting > for the arch group to give me the green light ;). > > Unfortunately since the modular trees will host new development going forward,
> there's really no way to make a development branch early, where I'd like to > do it at about the RC1 mark. I'm willing to pay that price for what it buys > us. > > It sounds rapid, but it's also almost five months. If we can't go from open > tree to released in five months we're doing something wrong. I'd have to agree with that. This schedule looks good to me. I can help with modularization. -- Chris Lee
From mark.carey at gmail.com Wed Apr 6 23:25:57 2005 From: mark.carey at gmail.com (Mark Carey) Date: Thu, 7 Apr 2005 18:25:57 +1200 Subject: Building X.org 6.8.2 freetype related question ..... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Apr 6, 2005 3:55 AM, Adam Jackson
From ajax at nwnk.net Thu Apr 7 07:33:28 2005 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 7 Apr 2005 10:33:28 -0400 Subject: Building X.org 6.8.2 freetype related question ..... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Thursday 07 April 2005 02:25, Mark Carey wrote: > On Apr 6, 2005 3:55 AM, Adam Jackson
______Do You Yahoo!? 150??MP3???????????? http://music.yisou.com/ ??????????????????? http://image.yisou.com 1G??1000??????????? http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ ______Do You Yahoo!? 150??MP3???????????? http://music.yisou.com/ ??????????????????? http://image.yisou.com 1G??1000??????????? http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
From kean at armory.com Thu Apr 7 23:18:14 2005 From: kean at armory.com (Kean Johnston) Date: Thu, 07 Apr 2005 23:18:14 -0700 Subject: Proposed change to xorgcfg Message-ID: <[email protected]> Hi everyone, I'd like to lobby for a change to xorgcfg. When you configure a monitor and select a given set of vert/horiz ranges, when the file is saved, those ranges you selected are neatly commented out! So the change I would like to make is two-fold: 1. When saving the config file, actually save the real values you selected, don't leave them commented out, and 2. Add to the list of possible choices the ability to explicitly enable DDC, and perhaps even wording on the screen to suggest it. Thoughts? Kean
From airlied at gmail.com Thu Apr 7 23:34:38 2005 From: airlied at gmail.com (Dave Airlie) Date: Fri, 8 Apr 2005 16:34:38 +1000 Subject: dynamic driver configuration idea... Message-ID: <[email protected]> I've been thinking about this and recently after using Thomas Winischhofer's sisctrl application wondered why we don't have a standard method for driver configuration... I'm thinking something like driconf does for DRI 3D drivers, but maybe a bit more network aware, (btw driconf just writes a local .drirc file, and it gets the config options from the actual driver binary and this is read by the 3D client library at startup so you can have differnet settings for different apps... etc..) it would probably be like a super xrandr, the driver could return an XML description of what if wants to offer, a GUI app could build a GUI from those options and could then send the results dynamically back to the driver to reconfigure itself.. as every driver would have different options I wouldn't feel the need to limit it through some interface hence XML or something like that... Mainly I would think of CRT configurations, desktop size, driver acceleration tweaks, like you see on Windows drivers .... also it might have the option to write the X config file but that may not be necessary... I can see security issues as well with what clients can access it .. btw I probably won't write this at all, just throwing the idea around as that sisctrl panel doth rock when messing with TV-OUT on an SIS laptop... Dave.
From dusty at qwer.tk Fri Apr 8 02:56:10 2005 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Fri, 8 Apr 2005 11:56:10 +0200 Subject: Memory leak in xorg-6.8.1? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Wednesday 06 April 2005 00:03, Anton Markov wrote: > Hermann Himmelbauer wrote: > > When heavily working with the Adobe Reader the swap space gets filled up > > and the machine is getting very slow. > > > > When closing the Adobe Reader the RSS-size stays roughly the same. > > > > It seems that also other applications, like Firefox trigger this problem, > > when surfing a lot, the XOrg memory usage is getting high, although when > > closing Firefox there is also memory freed - but not all. > > > > Maybe that there are some bugs in the Adobe Reader/Firefox but to my mind > > this is also a XOrg problem. > > It's caused by using a cursor theme with animated cursors :( > > See:
From libv at skynet.be Fri Apr 8 04:30:08 2005 From: libv at skynet.be (Luc Verhaegen) Date: Fri, 8 Apr 2005 13:30:08 +0200 Subject: dynamic driver configuration idea... In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Fri, Apr 08, 2005 at 04:34:38PM +1000, Dave Airlie wrote: > I've been thinking about this and recently after using Thomas > Winischhofer's sisctrl application wondered why we don't have a > standard method for driver configuration... > > I'm thinking something like driconf does for DRI 3D drivers, but maybe > a bit more network aware, (btw driconf just writes a local .drirc > file, and it gets the config options from the actual driver binary and > this is read by the 3D client library at startup so you can have > differnet settings for different apps... etc..) > > it would probably be like a super xrandr, the driver could return an > XML description of what if wants to offer, a GUI app could build a GUI > from those options and could then send the results dynamically back to > the driver to reconfigure itself.. as every driver would have > different options I wouldn't feel the need to limit it through some > interface hence XML or something like that... > > Mainly I would think of CRT configurations, desktop size, driver > acceleration tweaks, like you see on Windows drivers .... also it > might have the option to write the X config file but that may not be > necessary... > > I can see security issues as well with what clients can access it .. > > btw I probably won't write this at all, just throwing the idea around > as that sisctrl panel doth rock when messing with TV-OUT on an SIS > laptop... > > Dave. Doesn't sisctrl work over an Xv port? Altering attributes related to the tv encoder over the Xv port (VIA did this too, in its original driver). There has been some superficial conversation about a general xorg attribute system (of which Xv attributes can become a subset, or the general can become a superset, whatever :)) in #freedesktop late january (27th it seems - i'm not immediately able to find the gzipped online logs through google) Alex Deucher was very interested in it and i personally am too, although i am not currently devoting any time towards making it happen (yet?). Luc Verhaegen.
From thomas at winischhofer.net Fri Apr 8 06:02:14 2005 From: thomas at winischhofer.net (Thomas Winischhofer) Date: Fri, 08 Apr 2005 15:02:14 +0200 Subject: dynamic driver configuration idea... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luc Verhaegen wrote: > On Fri, Apr 08, 2005 at 04:34:38PM +1000, Dave Airlie wrote: > >>I've been thinking about this and recently after using Thomas >>Winischhofer's sisctrl application wondered why we don't have a >>standard method for driver configuration... >> >>I'm thinking something like driconf does for DRI 3D drivers, but maybe >>a bit more network aware, (btw driconf just writes a local .drirc >>file, and it gets the config options from the actual driver binary and >>this is read by the 3D client library at startup so you can have >>differnet settings for different apps... etc..) >> >>it would probably be like a super xrandr, the driver could return an >>XML description of what if wants to offer, a GUI app could build a GUI >>from those options and could then send the results dynamically back to >>the driver to reconfigure itself.. as every driver would have >>different options I wouldn't feel the need to limit it through some >>interface hence XML or something like that... >> >>Mainly I would think of CRT configurations, desktop size, driver >>acceleration tweaks, like you see on Windows drivers .... also it >>might have the option to write the X config file but that may not be >>necessary... >> >>I can see security issues as well with what clients can access it .. >> >>btw I probably won't write this at all, just throwing the idea around >>as that sisctrl panel doth rock when messing with TV-OUT on an SIS >>laptop... >> >>Dave. > > Doesn't sisctrl work over an Xv port?
Not any longer. I ditched this because of its lack of bi-directional communication. The new driver implements a dedicated SISCTRL extension. (Available only on my website, not yet in CVS.. but soon.)
> There has been some superficial conversation about a general xorg > attribute system (of which Xv attributes can become a subset, or the > general can become a superset, whatever :)) in #freedesktop late january > (27th it seems - i'm not immediately able to find the gzipped online > logs through google) > > Alex Deucher was very interested in it and i personally am too, although > i am not currently devoting any time towards making it happen (yet?). Two years ago I tried to write down a universal concept for such run-time driver configuration but I gave up on my universality intentions after a while because of the widely totally different features, needs and - last but in no way least - interactions between those two for different cards. Since there was serious immediate demand for run-time config (mainly for embedded devices and laptops for which SiS chips are often used), I went the proprietary road. The only possible way to do this at that time (without changes in the server core) was the Xv attribute interface. As mentioned, this had (and has) the disadvantage that there is no ordered bi-directional communication (for cases such as: Is a certain display mode supported for a certain output device?). Also, it didn't allow to talk to the (server internal) screens forming a Xinerama screen. Later the HandleMessage() stuff was added to the Misc extension; but this is not ideal because it is limited to text messages (and parsing this is slow and a pain...). Now I ended up with a dedicated server extension, solving all the above disadvantages the "works for me and my users" way. I have somewhat mixed feelings as regards the XML idea. The generation and parsing of XML is not only slow, it also looks like requiring a huge amount of work on the server side (security issues left aside for now). Although, granted, its advantages are obvious, too: A simple generic GUI. But to make it short: I don't have a better solution to offer either. Perhaps there is a reason for this being vendor-specific in Windows as well? Thomas - -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVoDWzydIRAktyUcRAu57AJ97hgk2i+TflnMXM3vm0RZrSfF3CQCgkEfW Kneu8ItUPNOG+VaXA0TDyWs= =CBWm -----END PGP SIGNATURE-----
From ldelgass at gmail.com Fri Apr 8 08:38:42 2005 From: ldelgass at gmail.com (Leif Delgass) Date: Fri, 8 Apr 2005 10:38:42 -0500 Subject: Multiple screens. In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]>
From rlynch at bway.net Fri Apr 8 10:17:58 2005 From: rlynch at bway.net (Ryan B. Lynch) Date: Fri, 08 Apr 2005 17:17:58 +0000 Subject: Client memory leak with XCopyArea() call? Message-ID: <[email protected]> I'm pretty new to Xlib programming, and I'm observing a behavior that seems like a memory leak. I'm using x11 6.7.0, right now, compiled from source on CRUX Linux. First, I create a window. Then, in a while(1) loop, I: - call XCreatePixmap() to instantiate a new pixmap, - draw some stuff on the pixmap, - call XCopyArea to copy the pixmap contents to the window, - call XFreePixmap to destroy the pixmap. When the program runs, I notice that the memory usage of my program starts climbing and climbing--eventually, it exhausts memory. Seems like a memory leak, right? I don't understand what's going on, though, because the XFreePixmap() call should free the memory that's being allocated by each new pixmap, right? Does XFreePixmap guarantee that the memory used by that pixmap is completely freed, or what? I noticed something strange, also: if I remove the call to XCopyArea(), the memory leak doesn't happen. If I just run the loop (uselessly) to do this: - call XCreatePixmap() to instantiate a new pixmap, - draw some stuff on the pixmap, - call XFreePixmap to destroy the pixmap, then the memory usage stays pretty constant. No memory leak. Any idea why calling XCopyArea causes this behavior? I can post some sample code to illustrate the problem, if need be. Thanks, Ryan B. Lynch
From otaylor at redhat.com Fri Apr 8 10:35:11 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 08 Apr 2005 13:35:11 -0400 Subject: Client memory leak with XCopyArea() call? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-08 at 17:17 +0000, Ryan B. Lynch wrote: > I'm pretty new to Xlib programming, and I'm observing a behavior that > seems like a memory leak. I'm using x11 6.7.0, right now, compiled from > source on CRUX Linux. > > First, I create a window. > > Then, in a while(1) loop, I: > - call XCreatePixmap() to instantiate a new pixmap, > - draw some stuff on the pixmap, > - call XCopyArea to copy the pixmap contents to the window, > - call XFreePixmap to destroy the pixmap. Most likely your XCopyArea calls are creating GraphicsExpose events (the default GC values have them on) and you aren't processing events, so the events accumulate in the event queue. Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From rlynch at bway.net Fri Apr 8 11:21:47 2005 From: rlynch at bway.net (Ryan B. Lynch) Date: Fri, 08 Apr 2005 18:21:47 +0000 Subject: Client memory leak with XCopyArea() call? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> Thanks! That was exactly it. I inserted a sub-loop into the main while() loop that checks the size of the event queue with QLength(), retrieves and throws away all the events on the queue, and then proceeds with the rest of the main loop. Works perfectly. This has been puzzling me for days, now. Thank you so much. -Ryan Owen Taylor wrote: >On Fri, 2005-04-08 at 17:17 +0000, Ryan B. Lynch wrote: > > >>I'm pretty new to Xlib programming, and I'm observing a behavior that >>seems like a memory leak. I'm using x11 6.7.0, right now, compiled from >>source on CRUX Linux. >> >>First, I create a window. >> >>Then, in a while(1) loop, I: >> - call XCreatePixmap() to instantiate a new pixmap, >> - draw some stuff on the pixmap, >> - call XCopyArea to copy the pixmap contents to the window, >> - call XFreePixmap to destroy the pixmap. >> >> > >Most likely your XCopyArea calls are creating GraphicsExpose events >(the default GC values have them on) and you aren't processing events, >so the events accumulate in the event queue. > >Regards, > Owen > > >
From Jay.Cotton at Sun.COM Fri Apr 8 11:20:21 2005 From: Jay.Cotton at Sun.COM (Jay Cotton) Date: Fri, 08 Apr 2005 11:20:21 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> A good call. Have you filed a bug ? I suspect (want to believe) that #1 is a bug. ... Maybe we are being 'very' careful not to fry a monitor...
Kean Johnston wrote: > Hi everyone, > > I'd like to lobby for a change to xorgcfg. When you configure a > monitor and select a given set of vert/horiz ranges, when the > file is saved, those ranges you selected are neatly commented > out! So the change I would like to make is two-fold: > 1. When saving the config file, actually save the real values > you selected, don't leave them commented out, and > 2. Add to the list of possible choices the ability to explicitly > enable DDC, and perhaps even wording on the screen to suggest > it. > > Thoughts? > > Kean > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
-- Jay Cotton Jay.Cotton at sun.com MPK17-2348 x80841 Sun Microsystems Inc. - X11 Server Group Operating Platform Group
From kean at armory.com Fri Apr 8 12:46:05 2005 From: kean at armory.com (Kean Johnston) Date: Fri, 08 Apr 2005 12:46:05 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> Jay Cotton wrote: > A good call. Have you filed a bug ? I hadn't yet. I wanted to understand why it is the way it is first :) I suspect at least one reason is this. When you run -configure, it still does the DDC probe and tries to ask your monitor what it supports. If then puts in the v/hsync ranges, but leaves them commented out so that it will always use the DDC values. Unfortunately, the same mechanism that used to write the config file by xorgcfg is used to write the values determined by -configure. I can see two ways of fixing this. The first I touched on briefly in my original mail. Something im the montor section like Option "PreferDDC"
From matthieu.herrb at laas.fr Fri Apr 8 13:13:04 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Fri, 08 Apr 2005 22:13:04 +0200 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Kean Johnston wrote: > Jay Cotton wrote: > >>A good call. Have you filed a bug ? > > I hadn't yet. I wanted to understand why it is the way it is > first :) The main reason is that not much time or energy has been invested in xf86cfg/xorgcfg since XFree86 has introduced DDC probes and autoconfiguration. Morevover most Linux distros ship their own configuration programs. -- Matthieu Herrb
From Jay.Cotton at Sun.COM Fri Apr 8 13:57:27 2005 From: Jay.Cotton at Sun.COM (Jay Cotton) Date: Fri, 08 Apr 2005 13:57:27 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> I think Matthieu Herrb nailed it. Neglect. File the bug, we (you and I) will work on it. JC
Kean Johnston wrote: > Jay Cotton wrote: > >>A good call. Have you filed a bug ? > > I hadn't yet. I wanted to understand why it is the way it is > first :) I suspect at least one reason is this. When you > run -configure, it still does the DDC probe and tries to > ask your monitor what it supports. If then puts in the > v/hsync ranges, but leaves them commented out so that it > will always use the DDC values. Unfortunately, the same > mechanism that used to write the config file by xorgcfg > is used to write the values determined by -configure. > > I can see two ways of fixing this. The first I touched > on briefly in my original mail. Something im the montor > section like Option "PreferDDC"
-- Jay Cotton Jay.Cotton at sun.com MPK17-2348 x80841 Sun Microsystems Inc. - X11 Server Group Operating Platform Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From anton at truxtar.com Fri Apr 8 15:41:18 2005 From: anton at truxtar.com (Anton Markov) Date: Fri, 8 Apr 2005 18:41:18 -0400 Subject: Memory leak in xorg-6.8.1? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On April 8, 2005 05:56, Hermann Himmelbauer wrote: > On Wednesday 06 April 2005 00:03, Anton Markov wrote: > > Hermann Himmelbauer wrote: > > > When heavily working with the Adobe Reader the swap space gets filled > > > up and the machine is getting very slow. > > > > > > When closing the Adobe Reader the RSS-size stays roughly the same. > > > > > > It seems that also other applications, like Firefox trigger this > > > problem, when surfing a lot, the XOrg memory usage is getting high, > > > although when closing Firefox there is also memory freed - but not all. > > > > > > Maybe that there are some bugs in the Adobe Reader/Firefox but to my > > > mind this is also a XOrg problem. > > > > It's caused by using a cursor theme with animated cursors :( > > > > See:
From kem at freedesktop.org Fri Apr 8 23:41:50 2005 From: kem at freedesktop.org (Kevin E Martin) Date: Sat, 9 Apr 2005 02:41:50 -0400 Subject: Change list from 6.8 to HEAD, and 7.0 plans In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 04, 2005 at 09:25:40PM -0400, Adam Jackson wrote: > Fair enough. Here's a strawman, targetted at August 19, which is just over 19
> weeks out: > > June 10: Code slush. Any big changes should start stabilizing. There are already many significant changes in xorg HEAD. See the following wiki page that ajax put together for details: http://wiki.x.org/wiki/ChangesSince68 What is the general consensus for how stable and well tested HEAD is? I'd really like to see everyone start stabilizing much sooner than June 10th. Perhaps this process should begin today? > June 24: Feature freeze. Patches should be bugfix only and preferably > through subsystem maintainers where they exist. Begin writing > release notes and doc updates. I agree that the feature freeze should coincide with the close of the initial modular development phase. The exact timing of this development phase is still TBD. > July 8: RC1. Code freeze for all but approved patches, fairly open > approval stance. > July 22: RC2. Patch approval for crashes, correctness, regressions, build > fixes only. Docs should be basically done. > August 5: RC3. Approval for showstoppers only. > August 19: 6.9 / 7.0. 6.9 enters immediate maintenance mode, HEAD in xc/ is > for 6.9.x releases only. 7.0 modules open for new development. > > That's two weeks for each cycle, which I think is reasonable. It also allows > about two weeks of slip before we hit September, and 10-12 weeks of open > commits before we start serious release mode. I think keeping the testing schedule tight is good since it keeps us focused; however, the amount of time required for testing depends on how quickly we get adequate coverage for the platforms we support. I would like to see us create another test grid similar to what was done for the 6.8.0 release, but this time, I'd like to see significantly better coverage. This will be a major release, and it deserves to be very well tested on all supported platforms. If we could start getting tinderbox clients set up for major platforms and distros now, I think we might be in good shape for a late summer release. It would also help us get a feel for how stable HEAD is today. > The modular tree's time frame is somewhat dependent on the exact schedule we > aim for, but I would like to see it at about 90% completion by the code slush > point for all the major platforms, where "major" is: Linux, Solaris, at least > one BSD, OSX, and Win32. (Other platforms are welcome and encouraged to > shoot for completion by that date too, of course.) Agreed. > The development plan for modular is basically the bootstrap order: protocol > headers, libs, server, apps. I would expect these to proceed in rough order > for each platform, but that different platforms could be at different stages > in the process. Given that, and the above timeline, I would say the > following would be worst-case dates for finishing each step: (note that > platform-specific fixes can go in during the release cycle) I'm still working on my modularization development schedule writeup, and I hope to finish it this weekend. The dependency ordering for the modules is proto -> lib -> app,xserver. The apps and various X servers can proceed in parallel after the proto and lib modules are complete. Also, the font, doc and util modules can be developed independently by bootstrapping from the monolithic tree as needed. I go into detail on these and other issues in my writeup. > May 13: headers > May 27: libs > June 10: server > June 24: apps > > That's just over five weeks to have all the headers filled in, which sounds > quick. Balancing this is that it's a fairly mechanical process, we have > quite a few hands to do it, and that we have a lot of this already done in > the existing proof-of-concept. I'm up for the challenge, I'm just waiting > for the arch group to give me the green light ;). I really hope that the proto module will take significantly less than 5 weeks since it only contains headers and the associated protocol specs. > Unfortunately since the modular trees will host new development going forward,
> there's really no way to make a development branch early, where I'd like to > do it at about the RC1 mark. I'm willing to pay that price for what it buys > us. Agreed. I think this is a small price to pay to get two releases out on an aggressive but still manageable schedule. Kevin
From barr.156 at osu.edu Sat Apr 9 09:23:21 2005 From: barr.156 at osu.edu (Andrew Barr) Date: Sat, 9 Apr 2005 12:23:21 -0400 Subject: Intel 855GM/Chrontel 7011A: S-Video on Xorg Message-ID: <[email protected]> Hi. I have an IBM ThinkPad R51 with an Intel 82855GM graphics chip. I am trying to get the S-Video out to work under X.org 6.8.2 (Gentoo Linux). The encoder chip (according to 'nvtv -P') is a Chrontel 7011A. I have tried two scenarios to get the TV-out port working: - the open-source i810 driver. The driver will not start at 800x600 (which is evidently what the encoder runs at). It says "no mode of this name". It will start at either 1024x768 or 640x480. So, although an image appears on the TV screen, it is constantly rolling, presumably from an incorrect resolution. I use: Option "MonitorLayout" "LFP,TV" to activate the TV-out. - the binary-only IEGD driver. Using: Option "PortDrivers" "ch7009 lvds" the following appears in the Xorg log: (II) LoadModule: "ch7009" (II) Loading /usr/lib/modules/ch7009.so (EE) INTEL(0): ==> Failed to load ch7009 port driver. Check the hardware for this port driver. ret = 7 (II) LoadModule: "lvds" (II) Loading /usr/lib/modules/lvds.so (II) INTEL(0): ==> lvds port driver started successfully. This driver does not even activate the TVout at all. Unfortunately, nvtv doesn't seem to support my encoder chip and development seems to have ceased on this project. Please find my X.org configuration files as well as resultant log files for both the i810 and IEGD drivers at the following location: http://home.columbus.rr.com/andrewbarr/i855tvout/ Thanks, Andrew
From alanh at fairlite.demon.co.uk Sat Apr 9 09:56:06 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Sat, 9 Apr 2005 17:56:06 +0100 Subject: Intel 855GM/Chrontel 7011A: S-Video on Xorg In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Sat, Apr 09, 2005 at 12:23:21PM -0400, Andrew Barr wrote: > Hi. > > I have an IBM ThinkPad R51 with an Intel 82855GM graphics chip. I am trying to
> get the S-Video out to work under X.org 6.8.2 (Gentoo Linux). The encoder > chip (according to 'nvtv -P') is a Chrontel 7011A. I have tried two scenarios > to get the TV-out port working: > > - the open-source i810 driver. The driver will not start at 800x600 (which is > evidently what the encoder runs at). It says "no mode of this name". It will > start at either 1024x768 or 640x480. So, although an image appears on the TV > screen, it is constantly rolling, presumably from an incorrect resolution. I > use: > > Option "MonitorLayout" "LFP,TV" > > to activate the TV-out.
O.k. First off your TVout interface doesn't support 1024x768, only 800x600 and 640x480. So I'm not sure why you think it's starting with 1024x768. As for the rolling picture, have you checked the BIOS to see if it's supporting NTSC or PAL or some other format and that your TV supports that ? > - the binary-only IEGD driver. Using: We can't help with the IEGD driver as that's Intel proprietary. Alan.
From barr.156 at osu.edu Sat Apr 9 11:23:55 2005 From: barr.156 at osu.edu (Andrew Barr) Date: Sat, 9 Apr 2005 14:23:55 -0400 Subject: Intel 855GM/Chrontel 7011A: S-Video on Xorg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Saturday 09 April 2005 12:56 pm, you wrote: > As for the rolling picture, have you checked the BIOS to > see if it's supporting NTSC or PAL or some other format and that your > TV supports that ? The picture is rolling black-and-white....it just might be in PAL mode now that you mention it. There are no BIOS settings that control the TV-out function of this laptop. So, is there any way to set the chip to NTSC in X? > We can't help with the IEGD driver as that's Intel proprietary. Do you know where I can get more information on the error codes it's returning, then? I can't tell whether it doesn't detect the TV chip or if it's just misconfigured. Andrew > Alan.
From alanh at fairlite.demon.co.uk Sat Apr 9 11:46:27 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Sat, 9 Apr 2005 19:46:27 +0100 Subject: Intel 855GM/Chrontel 7011A: S-Video on Xorg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sat, Apr 09, 2005 at 02:23:55PM -0400, Andrew Barr wrote: > On Saturday 09 April 2005 12:56 pm, you wrote: > > As for the rolling picture, have you checked the BIOS to > > see if it's supporting NTSC or PAL or some other format and that your > > TV supports that ? > > The picture is rolling black-and-white....it just might be in PAL mode now > that you mention it. There are no BIOS settings that control the TV-out > function of this laptop. So, is there any way to set the chip to NTSC in X?
No. It's whatever the BIOS has set. > > We can't help with the IEGD driver as that's Intel proprietary. > > Do you know where I can get more information on the error codes it's > returning, then? I can't tell whether it doesn't detect the TV chip or if > it's just misconfigured. Sorry, can't help at all here. You'd need to see where you got the IEGD driver from. Alan.
From kean at armory.com Sat Apr 9 12:38:09 2005 From: kean at armory.com (Kean Johnston) Date: Sat, 09 Apr 2005 12:38:09 -0700 Subject: What font is a window using? Message-ID: <[email protected]> Hi All, Is there any way I can tell exactly what font a given window is using? For example, the fonts used in the menu versus the fonts used in the actual app etc? Even more useful would be some way to tell what the app *asked* for, versus what it ended up with. For example, if its resource file only specifies "-adobe-helvetica-*-*-*-*" etc, which font was actual chosen? Any help at all would be very much appreciated. Kean
From ajax at nwnk.net Sat Apr 9 14:07:09 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sat, 9 Apr 2005 17:07:09 -0400 Subject: Change list from 6.8 to HEAD, and 7.0 plans In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Saturday 09 April 2005 02:41, Kevin E Martin wrote: > I think keeping the testing schedule tight is good since it keeps us > focused; however, the amount of time required for testing depends on how > quickly we get adequate coverage for the platforms we support. I would > like to see us create another test grid similar to what was done for the > 6.8.0 release, but this time, I'd like to see significantly better > coverage. This will be a major release, and it deserves to be very well > tested on all supported platforms. I don't know how you enforce this though. We can use the carrot of "wouldn't it be great if we had this release out by $DATE" or the stick of "we will be releasing on $DATE, if you care about your platform get a tinderclient going yesterday". The carrot model doesn't seem to be working thus far, because we all agreed during 6.8 that we needed to move to a regular six-month-ish release cycle and that hasn't happened yet. This tempts me to get out the stick. I don't disagree with longer testing cycles, not at all. But no one's going to _do_ them unless they have a little release date fear in them. As evidence, the 6.8.99.1 snapshot has had all of 32 downloads. I posit that no one is interested in making sure HEAD works because no one thinks a release is approaching. What I was hoping for with that proposed schedule was for someone to speak up with concrete suggestions like "we should do weekly RCs instead", or "start the freeze earlier", or "that's wholly unrealistic and ajax should put down the crack pipe". In a week, I got two responses, generally positive with the only objection being to start testing sooner. I interpret this as consensus. Therefore, dear reader: - basic outline of the strawman schedule is accepted - testing cycle should be started as soon as possible (this means you) - remaining major changes in by early June at the latest - release in mid-August Don't say you weren't warned. > If we could start getting tinderbox clients set up for major platforms > and distros now, I think we might be in good shape for a late summer > release. It would also help us get a feel for how stable HEAD is today. Personally I think HEAD is in decent shape, I run it for my daily server. I mentioned in my first email in this thread that there are a couple of features I still want to land in HEAD before the next release. Apparently I'm the only one, because a week has gone by and nobody else has mentioned anything they're working on for 7.0. I find this unsettling. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From airlied at gmail.com Sat Apr 9 20:33:09 2005 From: airlied at gmail.com (Dave Airlie) Date: Sun, 10 Apr 2005 13:33:09 +1000 Subject: Multiple screens. In-Reply-To:
From nadeem at gmail.com Sun Apr 10 03:26:25 2005 From: nadeem at gmail.com (Nadeem Bitar) Date: Sun, 10 Apr 2005 03:26:25 -0700 Subject: Urgent help needed Message-ID: <[email protected]> Hi, I hope someone can help me with this problem. My laptop's screen turned black and I can't figure out any way to fix it. When I reboot the bios doesn't appear, I even installed windows to try to fix it to no avail. This screen has been replaced three times already, I even got the video card and motherboard replaced the last time in order to get a new BIOS. I'm afraid that I can't just fix it anymore and keep "burning" my display when I use dualhead so my only choice is to never plug in my external LCD or get some help from someone knowledgeable :-) I opened bug 2628[1] last time I encountered this problem. I really appreciate any help I can get on this. Thanks.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=2628
From mharris at www.linux.org.uk Sun Apr 10 17:19:45 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sun, 10 Apr 2005 20:19:45 -0400 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Adam Jackson wrote: > CVSROOT: /cvs/xorg > Module name: xc > Changes by: ajax at gabe.freedesktop.org 05/04/02 11:07:53 > > Log message: > Bug #2884: Canonicalize BUILDERADDR to point to @lists.freedesktop.org. > > Modified files: > ./: > ChangeLog > xc/config/cf/: > xorg.tmpl > > Revision Changes Path > 1.854 +7 -1 xc/ChangeLog > 1.4 +2 -2 xc/config/cf/xorg.tmpl > > ______> xorg-commit mailing list > xorg-commit at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg-commit
Shouldn't BUILDERADDR point to @lists.x.org? From ajax at nwnk.net Sun Apr 10 17:26:22 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sun, 10 Apr 2005 20:26:22 -0400 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sunday 10 April 2005 20:19, Mike A. Harris wrote: > Adam Jackson wrote: > > CVSROOT: /cvs/xorg > > Module name: xc > > Changes by: ajax at gabe.freedesktop.org 05/04/02 11:07:53 > > > > Log message: > > Bug #2884: Canonicalize BUILDERADDR to point to @lists.freedesktop.org. > > > > Shouldn't BUILDERADDR point to @lists.x.org? No. xorg at lists.x.org isn't a valid email address. My spies tell me there are three mailing lists under the l.x.o banner: xorg-arch, xorg-mentors, xorg-modular. None of those are appropriate places for bug reports or build issues. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From mharris at www.linux.org.uk Sun Apr 10 20:03:07 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sun, 10 Apr 2005 23:03:07 -0400 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Adam Jackson wrote: > On Sunday 10 April 2005 20:19, Mike A. Harris wrote: > >>Adam Jackson wrote: >> >>>CVSROOT: /cvs/xorg >>>Module name: xc >>>Changes by: ajax at gabe.freedesktop.org 05/04/02 11:07:53 >>> >>>Log message: >>> Bug #2884: Canonicalize BUILDERADDR to point to @lists.freedesktop.org. >>> >> >>Shouldn't BUILDERADDR point to @lists.x.org? > > > No. > > xorg at lists.x.org isn't a valid email address. My spies tell me there are > three mailing lists under the l.x.o banner: xorg-arch, xorg-mentors, > xorg-modular. None of those are appropriate places for bug reports or build > issues. Sorry, I was implying xorg at lists.x.org, and moving the xorg list to lists.x.org. I should have been a bit more explicit. ;o)
From clemens.koller at anagramm.de Mon Apr 11 05:04:16 2005 From: clemens.koller at anagramm.de (Clemens Koller) Date: Mon, 11 Apr 2005 14:04:16 +0200 Subject: gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetypemacro (worksforme) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> Hello again! In the freetype-devel list, I got some suggestions: This bug/problem seems to concentrate on ppc32/64 and s390 architectures. Basically all Type1 fonts shipped with X11 are suspect to this problem. I made tests agains UTBI____.pfa The possible (temporary)fix: If I re-compile freetype with -fno-strict-aliasing I can get mkfontscale to work! It's still not clear whether this is a problem in freetype (2.1.7 to 2.1.9 at least), the macros there, or in gcc. Please see the following links for more information on this problem (also referred as 'aliasing issues in freetype macros'): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118021 http://rpm.sh-linux.org/rpm-index-2004/sh4/freetype-utils-2.1.7-4.sh4.html http://lists.freedesktop.org/pipermail/x-packagers/2004-March/000010.html https://svn.uludag.org.tr/paketler/trunk/media-libs/freetype/freetype-2.1.9-r1.e build http://archives.devshed.com/a/ml/200408-12273/strange-compilation-on-PowerPC And my thread in freetype-devel: [ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index Currently don't feel confortable to deal with the freetype-type1-driver code which seems pretty nasty. (I am not into font-writing at all). Possible fixes might get discussed at the freetype-devel list. Suggestions are welcome to further track down the problem. But I first need to get X working on my platform... Best greets, Clemens Koller ______R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Clemens Koller wrote: > Hello, Dan! > > I did some more debugging on that problem. > This bug was also reported on this list: > http://gcc.gnu.org/ml/gcc/2004-07/msg00861.html > > To isolate it for the first step it's sufficient to only build > mkfontscale within <...>/xc/programs/mkfontscale > and then call it with mkfontscale Type1 (as mentioned below) > > And then, the fun starts: (let me just recite the old mail) > > Compilation of mkfontscale is ok, but its execution is quite strange. > In the source code of mkfontscale, a call to a function of freetype-2.1.9 > is made : FT_Get_Name_Index() in freetype-2.1.9/src/base/ftobjs.c:3279 > > In the source code of this freetype function, a call to another function > of freetype is made : FT_FACE_LOOKUP_SERVICE() > > The full code of the function FT_Get_Name_Index() is : > > FT_EXPORT_DEF( FT_UInt ) > FT_Get_Name_Index( FT_Face face, > FT_String* glyph_name ) > { > FT_UInt result = 0; > if ( face && FT_HAS_GLYPH_NAMES( face ) ) > { > FT_Service_GlyphDict service; > FT_FACE_LOOKUP_SERVICE( face, > service, > GLYPH_DICT ); > if ( service && service->name_index ) > result = service->name_index( face, glyph_name ); /*CRASHES HERE*/ > } > return result; > } > > > I am not finished with anlysing the code... > but on my target it crashes on the same place after the > 0xff4a988
From mharris at www.linux.org.uk Mon Apr 11 07:30:28 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 10:30:28 -0400 Subject: Speedo fonts - Are they still supported? Message-ID: <[email protected]> Someone just caught me in IRC with this, and I couldn't quickly determine the answer, and don't use speedo fonts myself so I thought I'd pass the question on here: I've been getting some bug reports about speedo fonts not working. The speedo module was removed from Xorg, presumeably because freetype handles speedo fonts now (unless I am mistaken). Can someone state canonically wether speedo fonts are still supported or not, and wether that depends on particular freetype releases or not? Should it work both with the server standalone, as well as using xfs? If speedo is not supported however, then we should not install the speedo font files anymore.
From mharris at www.linux.org.uk Mon Apr 11 08:33:21 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 11:33:21 -0400 Subject: [PATCH] radeon: Release DDC i2c lines after probe In-Reply-To: <1112576093.31872.316.camel@gaston> References: <1112576093.31872.316.camel@gaston> Message-ID: <[email protected]> Benjamin Herrenschmidt wrote: > (Hui: any comment on this one ?) > > This patch fixes support of recent Apple Cinema Display monitors. > Previously, we used to keep the SDA and SDL lines of the i2c "asserted" > after probing. This causes those monitor to shut down after a second or > so. This patch makes us "release" the line back to hi-z state (and thus > pulled high) after we are done probing a connector and fixes the problem > with Apple displays. (This should probably be applied to the stable > branch as well). > > Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c > ======> --- xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-04- 04 10:18:39.000000000 +1000 > +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2005-04- 04 10:35:07.000000000 +1000 > @@ -1006,6 +1006,9 @@ > MonType = MT_NONE; > } > > + OUTREG(info->DDCReg, INREG(info->DDCReg) & > + ~(RADEON_GPIO_EN_0 | RADEON_GPIO_EN_1)); > + > if (*MonInfo) { > if ((*MonInfo)->rawData[0x14] & 0x80) { > /* Note some laptops have a DVI output that uses internal TMDS, We've had several people report this bug. ;o) Please make sure this gets filed in bugzilla if it isn't in CVS already. ;o)
From mharris at www.linux.org.uk Mon Apr 11 08:47:47 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 11:47:47 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Kean Johnston wrote: > Hi everyone, > > I'd like to lobby for a change to xorgcfg. When you configure a > monitor and select a given set of vert/horiz ranges, when the > file is saved, those ranges you selected are neatly commented > out! So the change I would like to make is two-fold: > 1. When saving the config file, actually save the real values > you selected, don't leave them commented out, and The way that is worded is kindof confusing, but after reading it several times I understand what you're requesting and I agree with it. In case anyone else was confused too, let me try to restate it. By default, when the horz/vert frequencies get written to the config file using libxf86config, the library takes the liberty of commenting them out by default. This is not only annoying, it is just plain broken. The library should provide MECHANISM, but it should NOT enforcing a POLICY. I have filed a bug report about this in xorg bugzilla a while back, and last I remember the bug was blown off. It is perfectly reasonable for the application linking to this library to decide to comment the lines out if the author chooses, however the library itself should NOT do this. We have no alternative in our OS but to patch this library to not comment these lines out by default, in order for our user's setups to work. The reason it is the way it is, is because some people seem to be of the illusion that: 1) DDC probing is always available on every piece of video hardware, with every display type. 2) The drivers actually support DDC in all circumstances 3) Users do not use KVM switches that block the DDC signal The bare fact is, that there are a multitude of reasons why DDC may not work, and forcing the end user to hand edit their config file is unacceptable. The config library should be a parser and nothing else. It should not enforce a policy one way or the other.
> 2. Add to the list of possible choices the ability to explicitly > enable DDC, and perhaps even wording on the screen to suggest > it. I agree, the config tool itself should have an option as to wether to use DDC or not. If you select "use DDC" then the config tool writes out the config file either without putting the freq ranges, or by putting the ranges in commented out. If you do not choose "use DDC", then it writes out the horiz/vert ranges ready to use, and NOT commented out. Config tools are supposed to make life easier, not force people to hand edit the config file after (assuming they have a remote clue what the problem is and how to fix it). And libraries should not enforce policy that could and should be done in the applications that use that library, in particular something of this nature. Now that we're an army of 2 with similar thoughts, perhaps we can cause libxf86config to finally get fixed in CVS. ;o)
From daniel at fooishbar.org Mon Apr 11 08:50:26 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 12 Apr 2005 01:50:26 +1000 Subject: [PATCH] radeon: Release DDC i2c lines after probe In-Reply-To: <[email protected]> References: <1112576093.31872.316.camel@gaston> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 11, 2005 at 11:33:21AM -0400, Mike A. Harris wrote: > We've had several people report this bug. ;o) Please make sure > this gets filed in bugzilla if it isn't in CVS already. ;o) Me too, and it's seemed to work and have no negative side effects thus far. It's already in CVS HEAD. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
From mharris at www.linux.org.uk Mon Apr 11 08:51:25 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 11:51:25 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Matthieu Herrb wrote: > Kean Johnston wrote: > >> Jay Cotton wrote: >> >>> A good call. Have you filed a bug ? >> >> >> I hadn't yet. I wanted to understand why it is the way it is >> first :) > > > The main reason is that not much time or energy has been invested in > xf86cfg/xorgcfg since XFree86 has introduced DDC probes and > autoconfiguration. > Morevover most Linux distros ship their own configuration programs. Our config tool links to libxf86config however. We patch the library to fix this bug though, as X.Org rejected the patch previously for rather poor reason IMHO. The reason if I recall correctly, is that DDC should be used by default, and if you do not have a working DDC setup for any reason, then you should be forced to hand edit your config file, even if you're a dentist. ;o)
From mharris at www.linux.org.uk Mon Apr 11 08:56:58 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 11:56:58 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Jay Cotton wrote: > I think Matthieu Herrb nailed it. Neglect. > > File the bug, we (you and I) will work on it. I filed a report last August for this bug: https://bugs.freedesktop.org/show_bug.cgi?id=1223 The patch to fix the bug is attached to the report. It should be committed to CVS head and also to the stable branch. One less patch everyone needs to apply then. I've updated the report, and nominated the patch for stable branch. From Alan.Coopersmith at Sun.COM Mon Apr 11 09:02:22 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 11 Apr 2005 09:02:22 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> Mike A. Harris wrote: > I have filed a bug report about this in xorg bugzilla a while > back, and last I remember the bug was blown off. You mean https://bugs.freedesktop.org/show_bug.cgi?id=1223 ? It appears to be in the same state as many xorg bugs - too many bugs, too few people to tackle them all. The solution is to stop whining about it, get CVS access, and start helping to commit the bug fixes yourself. Otherwise, code sections like this, with no committed maintainer, only really get fixed when someone who does have CVS commit rights has an interest or need to fix it. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From sergio at sergiomb.no-ip.org Mon Apr 11 09:09:05 2005 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Mon, 11 Apr 2005 17:09:05 +0100 Subject: rpms for xorg-x11-6.8.99.2.tar.bz2 FC3 Message-ID: <1113235745.27037.27.camel@bastov> Hi Mike Harris, have you any plan to make rpms for RedHat/fedora based on http://xorg.freedesktop.org/snapshots/xorg-x11-6.8.99.2.tar.bz2 ?
Well, I want try it, but has we wrote some weeks ago rpms for FC3 comes with 26 patches, I would like to know of this 26 patches. which are RedHat customizes? or asking in other way what patches should be keeping to build the new RPMs ? Thanks, -- S?rgio M.B.
From zander at kde.org Mon Apr 11 09:17:14 2005 From: zander at kde.org (Thomas Zander) Date: Mon, 11 Apr 2005 18:17:14 +0200 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Monday 11 April 2005 17:47, Mike A. Harris wrote: > By default, when the horz/vert frequencies get written to the > config file using libxf86config, the library takes the liberty > of commenting them out by default. ... > The bare fact is, that there are a multitude of reasons why > DDC may not work, and forcing the end user to hand edit their > config file is unacceptable. ?The config library should be > a parser and nothing else. ?It should not enforce a policy > one way or the other. If I may provide a fresh perspective; the emails I read from this thread seem to point to a very different problem that is caused by the legacy of X itself. The implied usage of DDC by leaving out frequencies is not really a smart move, and certainly not one a designer would make right now it he were to redesign this parser. The new designer would correctly say that implying a configuration setting by leaving away some other settings is not just unintuitive; it basically makes for a lot harder debugging by configuration writers. A much better solution would be to have an extra option (which defaults to yes when omitted) like 'option autoprobeFrequencies'. Setting it to yes means any frequencies placed in the config file are not used unless the DDC fails. Much cleaner since nothing is implied and no user-entered values are ever lost due to them being commented out. This immidiately also means a similar option can be provided in the UI this thread seems to be spawned from making everything very clear. Cheers! -- Thomas Zander ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
When I filed the bug before, it was rejected via email or telephone discussion. That does not seem to have been reflected in the bug report, which I had never looked at again since then until now. I'm not in a habit of committing things to CVS that someone has explicitly rejected already. Having said that, if nobody is objecting now, I see no reason why the patch can't go into CVS now.
From mharris at www.linux.org.uk Mon Apr 11 09:18:03 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 12:18:03 -0400 Subject: rpms for xorg-x11-6.8.99.2.tar.bz2 FC3 In-Reply-To: <1113235745.27037.27.camel@bastov> References: <1113235745.27037.27.camel@bastov> Message-ID: <[email protected]> Sergio Monteiro Basto wrote: > Hi Mike Harris, > > have you any plan to make rpms for RedHat/fedora based on > http://xorg.freedesktop.org/snapshots/xorg-x11-6.8.99.2.tar.bz2 ? > > > Well, I want try it, but has we wrote some weeks ago rpms for FC3 comes > with 26 patches, I would like to know of this 26 patches. which are > RedHat customizes? or asking in other way what patches should be keeping > to build the new RPMs ? > > Thanks,
Yep, I have rpms I've been working on a bit on the side, however I need to update them to 6.8.99.2 and finish them off soon. I'll probably do that sometime in the next 2-3 weeks. If I do, I'll post a note here to let people know where to download them from. Thanks for bringing this up! It shows me people are interested. ;o)
From mharris at www.linux.org.uk Mon Apr 11 09:23:48 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 12:23:48 -0400 Subject: Speedo fonts - Are they still supported? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Mike A. Harris wrote: > Someone just caught me in IRC with this, and I couldn't quickly > determine the answer, and don't use speedo fonts myself so I thought > I'd pass the question on here: > > I've been getting some bug reports about speedo fonts not working. > The speedo module was removed from Xorg, presumeably because > freetype handles speedo fonts now (unless I am mistaken). > > Can someone state canonically wether speedo fonts are still supported > or not, and wether that depends on particular freetype releases or > not? Should it work both with the server standalone, as well as > using xfs? > > If speedo is not supported however, then we should not install > the speedo font files anymore. After chatting with others a bit, nobody seemed to know why speedo no longer works, so I dug into it deeper and discovered the following: https://bugs.freedesktop.org/show_bug.cgi?id=548 Date: Sun, 25 Apr 2004 15:34:12 -0700 From: Roland Mainz
Since we are seeing several people reporting bugs now, that fonts that previously worked fine, no longer work, this was kindof surprising because X.Org still supplies these fonts *and* installs them by default. I have no strong feelings either way as to wether this gets fixed by re-enabling speedo font support, or by preventing the speedo fonts from getting installed and/or removing them from CVS, as there have only been a few people file bug reports. I figured I would try to get concensus here first before opening a new bug report for this.
From davidr at novell.com Mon Apr 11 09:33:32 2005 From: davidr at novell.com (David Reveman) Date: Mon, 11 Apr 2005 18:33:32 +0200 Subject: GLX and Xgl Message-ID: <[email protected]> I've got GLX and indirect rendering working with Xgl. It's accelerated and works fine with Composite. There's of course a lot more work to be done but I don't plan on going much further until we're using framebuffer objects in Xgl as it would mean adding code that will be thrown away later. The glitz and Xgl code needed to get this working is in pretty good shape and it should land in CVS in a few days. But I had to do some pretty drastic changes to server side GLX code and I'm not sure that my current solutions are the best way to go. Here's what I've done: 1. Made glcore use MGL namespace. This allows me to always have software mesa available and this is currently necessary as there might not be enough resources to use the *real* GL stack with Composite. It might not be necessary when we're using framebuffer objects but I still think it's a good idea. This works fine when running Xgl on top of nvidia's GL stack or software mesa, but I haven't been able to get it running on top of mesa/DRI yet. 2. Made all GL calls in server side GLX go through another dispatch table. Allows me to switch between software mesa and *real* GL stack as I like. This is also necessary as extension function pointers might be different between contexts and we need to wrap some GL calls. e.g. glViewport needs an offset. Both these changes are available as patches from here: http://www.cs.umu.se/~c99drn/xgl-glx/ xserver-mesa.diff also include some changes required to get xserver compiling with mesa CVS and a few lines to support ARGB visuals. xserver-glx.diff modifies files that seem to be auto generated but I didn't find the source to that so I just made the changes directly. Most of these changes were done by running a regexp on all files in xserver/GL/glx directory. Does this seem like reasonable changes?
I had to add a 8A8R8G8B pixel format to XMesa for ARGB visuals to work properly. This patch should do that: http://www.cs.umu.se/~c99drn/xgl-glx/Mesa-PF_8A8R8G8B.diff With all the above changes in place I can run simple OpenGL applications accelerated while using a compositing manager, and by changing a few lines in the applications I can get them to use ARGB visuals as well.
The following is not working: - Context Sharing (all contexts are currently shared) - Drawing to front buffer - CopyPixels All contexts need to be shared inside Xgl so we're going to have to keep hash tables in Xgl to deal with GLX contexts. Getting front buffer drawing to work is a bit harder. We need to report damage and do pixel ownership test. Using the current scissor box when reporting damage is probably good enough but I don't have good solution for pixel ownership test. I guess we're going to have to do multiple drawing operations with different scissor boxes but that will make display lists much harder to handle... CopyPixels between different buffers is not working right now, but when we're using framebuffer objects this will work just fine.
My current plans for GLX support in Xgl and for Xgl in general are as follows: - Textures are used for pixmaps and framebuffer objects for drawing to them. No GL_EXT_framebuffer_object support, no accelerated offscreen drawing. - Windows that are not redirected to pixmaps will when attached to a GLX context use the back buffer, stencil bits and depth bits provided by the real framebuffer. For windows that are redirected we'll allocate back/depth/stencil buffers dynamically as needed. - The compositing manager will most likely be using indirect GLX for drawing the desktop. A double buffered GL visual can be used to efficiently draw the desktop even when GL_EXT_framebuffer_object isn't present and buffer flips can be used when redrawing the whole screen. - All visuals will be GL visuals and by reviving GL_ARB_render_texture and implementing it in Xgl we'll make it possible for GL applications to bind a X drawable to a texture id. This is what a GL compositing manager will do for all top level windows. This is just what I believe is the best way to go, it's not in any way set in stone, it's all open for discussion. Comments and suggestions are of course much appreciated. -David
From sergio at sergiomb.no-ip.org Mon Apr 11 09:36:47 2005 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Mon, 11 Apr 2005 17:36:47 +0100 Subject: rpms for xorg-x11-6.8.99.2.tar.bz2 FC3 In-Reply-To: <[email protected]> References: <1113235745.27037.27.camel@bastov> <[email protected]> Message-ID: <1113237407.27037.36.camel@bastov> On Mon, 2005-04-11 at 12:18 -0400, Mike A. Harris wrote: > Yep, I have rpms I've been working on a bit on the side, however > I need to update them to 6.8.99.2 and finish them off soon. If don't give much work, can you send me the spec and any extras patch if exists ? I like to begin to test DRI on my S3-savage that just work with the DDX of this versions :) .
> > I'll probably do that sometime in the next 2-3 weeks. If I do, I'll > post a note here to let people know where to download them from. > > Thanks for bringing this up! It shows me people are interested. ;o) Thanks, -- S?rgio M.B.
From kean at armory.com Mon Apr 11 10:03:21 2005 From: kean at armory.com (Kean Johnston) Date: Mon, 11 Apr 2005 10:03:21 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > It appears to be in the same state as many xorg bugs - too many > bugs, too few people to tackle them all. The solution is to > stop whining about it, get CVS access, and start helping to commit I recently acquired cvs write access. What are the commit policies? The patch mentioned in that attachment is great, although I'd leave out the reams of comments and just fix the bug. I'll happily commit a fix if that's OK with everyone. PS. Can someone point me to some form of procedures for checkin doc? I'd hate to have write access revoked because I didnt follow the right procedure :) Kean
From kean at armory.com Mon Apr 11 10:12:41 2005 From: kean at armory.com (Kean Johnston) Date: Mon, 11 Apr 2005 10:12:41 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > A much better solution would be to have an extra option (which defaults to > yes when omitted) like 'option autoprobeFrequencies'. That was exactly what I proposed in my original mail, except I used a slightly less verbose keyword 'UseDDC' or somesuch. So what I had in mind was: if (UseDDC is set AND we got DDC ranges) use DDC probed ranges else if ranges specified in the config file use those ranges else fall back to some pesimistic defaults endif endif Kean
From ajax at nwnk.net Mon Apr 11 10:18:07 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 11 Apr 2005 13:18:07 -0400 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Monday 11 April 2005 12:33, David Reveman wrote: > I've got GLX and indirect rendering working with Xgl. It's accelerated > and works fine with Composite. There's of course a lot more work to be > done but I don't plan on going much further until we're using > framebuffer objects in Xgl as it would mean adding code that will be > thrown away later. > > The glitz and Xgl code needed to get this working is in pretty good > shape and it should land in CVS in a few days. Way cool. > But I had to do some pretty drastic changes to server side GLX code and > I'm not sure that my current solutions are the best way to go. Here's > what I've done: > > 1. Made glcore use MGL namespace. This allows me to always have software > mesa available and this is currently necessary as there might not be > enough resources to use the *real* GL stack with Composite. It might not > be necessary when we're using framebuffer objects but I still think it's > a good idea. This works fine when running Xgl on top of nvidia's GL > stack or software mesa, but I haven't been able to get it running on top > of mesa/DRI yet. This is reasonable given that it's GLcore. DRI drivers are better for this, they have their own dispatch table built in so you don't have to worry about namespace mangling. I think all you'd have to do to make DRI drivers work is fill in glRenderTable{,EXT} from the driver's dispatch table. > 2. Made all GL calls in server side GLX go through another dispatch > table. Allows me to switch between software mesa and *real* GL stack as > I like. This is also necessary as extension function pointers might be > different between contexts and we need to wrap some GL calls. e.g. > glViewport needs an offset. Any function pointer you can query from glXGetProcAddress is explicitly context-independent. From the spec: # * Are function pointers context-independent? # # Yes. The pointer to an extension function can be used with any # context which supports the extension. I'm not quite clear yet on how you decide whether to use the software or hardware paths. Is it per context? Per client? Per drawable? I think you'll have major issues trying to use two rendering engines at once. > Both these changes are available as patches from here: > http://www.cs.umu.se/~c99drn/xgl-glx/ > > xserver-mesa.diff also include some changes required to get xserver > compiling with mesa CVS and a few lines to support ARGB visuals. > xserver-glx.diff modifies files that seem to be auto generated but I > didn't find the source to that so I just made the changes directly. Most of the server-side GLX code was (at one point) autogenerated from some scripts at SGI. We don't have those scripts though. > I had to add a 8A8R8G8B pixel format to XMesa for ARGB visuals to work > properly. This patch should do that: > http://www.cs.umu.se/~c99drn/xgl-glx/Mesa-PF_8A8R8G8B.diff This would actually be really cool to land on its own. > The following is not working: > - Context Sharing (all contexts are currently shared) > - Drawing to front buffer > - CopyPixels > > All contexts need to be shared inside Xgl so we're going to have to keep > hash tables in Xgl to deal with GLX contexts. Is this an artifact of using glitz, or is this something we'd see with other backends too? > This is just what I believe is the best way to go, it's not in any way > set in stone, it's all open for discussion. Comments and suggestions are > of course much appreciated. Sounds pretty sane, I'll think on it a bit. Very nice work! - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
-- Jay Cotton Jay.Cotton at sun.com MPK17-2348 x80841 Sun Microsystems Inc. - X11 Server Group Operating Platform Group
From ajax at nwnk.net Mon Apr 11 10:24:47 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 11 Apr 2005 13:24:47 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Monday 11 April 2005 13:03, Kean Johnston wrote: > > It appears to be in the same state as many xorg bugs - too many > > bugs, too few people to tackle them all. The solution is to > > stop whining about it, get CVS access, and start helping to commit > > I recently acquired cvs write access. What are the commit policies? > The patch mentioned in that attachment is great, although I'd leave > out the reams of comments and just fix the bug. > > I'll happily commit a fix if that's OK with everyone. > > PS. Can someone point me to some form of procedures for checkin > doc? I'd hate to have write access revoked because I didnt follow > the right procedure :) Patch review: - Open bug in bugzilla - Attach patch, preferably with commentary and diffstat - Wait reasonable amount of time for people to care (use your judgement) Commit procedure to HEAD: - cvs up - apply patch - edit xc/ChangeLog, add an entry for the change. Include at minimum the date, name, email address, files changed, bugzilla ID and change description. If the patch was written by someone else, give them credit. - cvs commit, with the change description from the ChangeLog as the commit message. - Close the bug. Having to manually edit the ChangeLog is the only really painful part. Anyone who wants to automate that? - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From mharris at www.linux.org.uk Mon Apr 11 10:58:45 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 13:58:45 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Adam Jackson wrote: > On Monday 11 April 2005 13:03, Kean Johnston wrote: > >>>It appears to be in the same state as many xorg bugs - too many >>>bugs, too few people to tackle them all. The solution is to >>>stop whining about it, get CVS access, and start helping to commit >> >>I recently acquired cvs write access. What are the commit policies? >>The patch mentioned in that attachment is great, although I'd leave >>out the reams of comments and just fix the bug. >> >>I'll happily commit a fix if that's OK with everyone. >> >>PS. Can someone point me to some form of procedures for checkin >>doc? I'd hate to have write access revoked because I didnt follow >>the right procedure :) > > > Patch review: > > - Open bug in bugzilla > - Attach patch, preferably with commentary and diffstat > - Wait reasonable amount of time for people to care (use your judgement) > > Commit procedure to HEAD: > > - cvs up > - apply patch > - edit xc/ChangeLog, add an entry for the change. Include at minimum the > date, name, email address, files changed, bugzilla ID and change > description. If the patch was written by someone else, give them credit. > - cvs commit, with the change description from the ChangeLog as the commit > message. > - Close the bug. > > Having to manually edit the ChangeLog is the only really painful part. Anyone
> who wants to automate that? Eric Anholt automated that already didn't he? Perhaps someone could drop a script in xc/ to do that. From kean at armory.com Mon Apr 11 11:04:07 2005 From: kean at armory.com (Kean Johnston) Date: Mon, 11 Apr 2005 11:04:07 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > This look good to me. Do you already have code? > I could patch up a test server and try it out.... I've got part of it done. I'll work on a test patch for you and get it to you in teh next day or two. Kean
From kean at armory.com Mon Apr 11 11:05:15 2005 From: kean at armory.com (Kean Johnston) Date: Mon, 11 Apr 2005 11:05:15 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> >> if (UseDDC is set AND we got DDC ranges) >> use DDC probed ranges >> else >> if ranges specified in the config file >> use those ranges >> else >> fall back to some pesimistic defaults >> endif >> endif By the way, do you (or anyone else) have an opinion on exactly what "pesimistic defaults" should be? Kean
From zander at kde.org Mon Apr 11 11:11:20 2005 From: zander at kde.org (Thomas Zander) Date: Mon, 11 Apr 2005 20:11:20 +0200 Subject: touchscreen driver. Message-ID: <[email protected]> Hi, 2 years ago I wrote a driver for my Paceblade-tablet to allow the touchscreen to work. I wrote it for X v4.1 or so.. Yesterday I upgraded and therefore I got CVS HEAD and added my driver there; with a little help on IRC I have my driver up and running again. What failed two years ago, I'd like to try again; are you interrested in placing the input driver in the Xorg repository for everyone to enjoy? I'm far from an experienced X11 hacker; the code is quite clean but it sure can do with some general code cleanup from an experienced x hacker. Is there interrest in doing this? Should I work in CVS directly? Please comment on how to proceed, thanks. -- Thomas Zander ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From Jay.Cotton at Sun.COM Mon Apr 11 11:29:18 2005 From: Jay.Cotton at Sun.COM (Jay Cotton) Date: Mon, 11 Apr 2005 11:29:18 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Kean Johnston wrote: >>>if (UseDDC is set AND we got DDC ranges) >>> use DDC probed ranges >>>else >>> if ranges specified in the config file >>> use those ranges >>> else >>> fall back to some pesimistic defaults As broken as it currently is, is pessimistic.... i.e. default to how it is now? >>> endif >>>endif > > > By the way, do you (or anyone else) have an opinion on exactly > what "pesimistic defaults" should be? > > Kean > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
-- Jay Cotton Jay.Cotton at sun.com MPK17-2348 x80841 Sun Microsystems Inc. - X11 Server Group Operating Platform Group
From mharris at www.linux.org.uk Mon Apr 11 11:47:18 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Mon, 11 Apr 2005 14:47:18 -0400 Subject: touchscreen driver. In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Thomas Zander wrote: > Hi, > > 2 years ago I wrote a driver for my Paceblade-tablet to allow the > touchscreen to work. I wrote it for X v4.1 or so.. > > Yesterday I upgraded and therefore I got CVS HEAD and added my driver there; > with a little help on IRC I have my driver up and running again. > > What failed two years ago, I'd like to try again; are you interrested in > placing the input driver in the Xorg repository for everyone to enjoy? > > I'm far from an experienced X11 hacker; the code is quite clean but it sure > can do with some general code cleanup from an experienced x hacker. > > Is there interrest in doing this? Should I work in CVS directly? > > Please comment on how to proceed, thanks. I just wanted to add a note on top of what others have suggested already. When you submit your driver to bugzilla, be sure to indicate the license terms for the driver. The X source code tree is made up mostly of "MIT" style license, and generally speaking that only MIT licensed code, or could with very similar license terms is permitted in the tree. Most people license driver modules as "MIT", so if you have done so also, there should probably not be any license hassles. ;o)
From idr at us.ibm.com Mon Apr 11 11:52:46 2005 From: idr at us.ibm.com (Ian Romanick) Date: Mon, 11 Apr 2005 11:52:46 -0700 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> David Reveman wrote: > 1. Made glcore use MGL namespace. This allows me to always have software > mesa available and this is currently necessary as there might not be > enough resources to use the *real* GL stack with Composite. It might not > be necessary when we're using framebuffer objects but I still think it's > a good idea. This works fine when running Xgl on top of nvidia's GL > stack or software mesa, but I haven't been able to get it running on top > of mesa/DRI yet. > > 2. Made all GL calls in server side GLX go through another dispatch > table. Allows me to switch between software mesa and *real* GL stack as > I like. This is also necessary as extension function pointers might be > different between contexts and we need to wrap some GL calls. e.g. > glViewport needs an offset. > > Both these changes are available as patches from here: > http://www.cs.umu.se/~c99drn/xgl-glx/ > > xserver-mesa.diff also include some changes required to get xserver > compiling with mesa CVS and a few lines to support ARGB visuals. > xserver-glx.diff modifies files that seem to be auto generated but I > didn't find the source to that so I just made the changes directly. Most > of these changes were done by running a regexp on all files in > xserver/GL/glx directory. > > Does this seem like reasonable changes? So, it turns out that I'm currently working on some similar stuff. Basically, I'm competely ripping up the interface between libglx ("the loader" hereafter) and libGLcore ("the driver" hereafter). The final goal is to get libglx to load a DRI driver. A big part of this is replacing the static dispatch functions (e.g., glVertex3fv) in libGLcore with a dispatch table, like is used on the client-side. The net result is that *all* the gl* functions are *gone* from the driver. The driver's bindContext function populates a dispatch table and calls _glapi_set_dispatch. Anything in the loader that wants to call glVertex3fv just does some flavor of 'dispatch->Vertex3fv(v)'. Another big part has been to replace all the "auto generated" code with new autogenerated code. The replacement code *will* have scripts available, and uses the gl_API.xml "stuff" in src/mesa/glapi in the Mesa tree. I haven't committed (or released as patches) any of this yet because it's pretty big, and I don't see a clear way to cherry-pick any parts of it out. Pretty much all of my changes end up breaking GLX for Darwin and cygwin. After looking at your xserver-glx.diff patch, I'll see if I can pull out my dispatch table changes. [snip] > - All visuals will be GL visuals and by reviving GL_ARB_render_texture > and implementing it in Xgl we'll make it possible for GL applications to > bind a X drawable to a texture id. This is what a GL compositing manager > will do for all top level windows. Can you elaborate on this more? The reason I'm asking is that, with the advent of EXT_framebuffer_object, there is almost no chance that there will ever be a GLX_ARB_render_texture extension. Even before EXT_framebuffer_object there were a few efforts to start a working group for that extension, and there just wasn't enough interest to get it going.
From zander at kde.org Mon Apr 11 11:57:40 2005 From: zander at kde.org (Thomas Zander) Date: Mon, 11 Apr 2005 20:57:40 +0200 Subject: touchscreen driver. In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Monday 11 April 2005 20:47, you wrote: > I just wanted to add a note on top of what others have suggested > already. ?When you submit your driver to bugzilla, be sure to > indicate the license terms for the driver. ? I based it on an existing driver's source, so I'll just use that license :) -- Thomas Zander ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From ciprian at zuavra.net Sun Apr 10 14:21:36 2005 From: ciprian at zuavra.net (Ciprian Popovici) Date: Mon, 11 Apr 2005 00:21:36 +0300 Subject: confirm 6b960f2ea72558875d921643a075a777fe1eceda In-Reply-To:
-- Ciprian Popovici
From eta at lclark.edu Mon Apr 11 14:13:59 2005 From: eta at lclark.edu (Eric Anholt) Date: Mon, 11 Apr 2005 14:13:59 -0700 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <1113254039.1450.9.camel@leguin> On Mon, 2005-04-11 at 13:58 -0400, Mike A. Harris wrote: > Adam Jackson wrote: > > On Monday 11 April 2005 13:03, Kean Johnston wrote: > > > >>>It appears to be in the same state as many xorg bugs - too many > >>>bugs, too few people to tackle them all. The solution is to > >>>stop whining about it, get CVS access, and start helping to commit > >> > >>I recently acquired cvs write access. What are the commit policies? > >>The patch mentioned in that attachment is great, although I'd leave > >>out the reams of comments and just fix the bug. > >> > >>I'll happily commit a fix if that's OK with everyone. > >> > >>PS. Can someone point me to some form of procedures for checkin > >>doc? I'd hate to have write access revoked because I didnt follow > >>the right procedure :) > > > > > > Patch review: > > > > - Open bug in bugzilla > > - Attach patch, preferably with commentary and diffstat > > - Wait reasonable amount of time for people to care (use your judgement) > > > > Commit procedure to HEAD: > > > > - cvs up > > - apply patch > > - edit xc/ChangeLog, add an entry for the change. Include at minimum the > > date, name, email address, files changed, bugzilla ID and change > > description. If the patch was written by someone else, give them credit. > > - cvs commit, with the change description from the ChangeLog as the commit > > message. > > - Close the bug. > > > > Having to manually edit the ChangeLog is the only really painful part. Anyo ne > > who wants to automate that? > > Eric Anholt automated that already didn't he? Perhaps someone could > drop a script in xc/ to do that. Wasn't me, but ~anholt/bin/prepare-ChangeLog.pl (among others) on pdx is a script that does it for you. It's nasty to run on a monolithic tree, but hopefully that won't be a problem for much longer.
From wirespot at zuavra.net Mon Apr 11 14:20:25 2005 From: wirespot at zuavra.net (WireSpot) Date: Tue, 12 Apr 2005 00:20:25 +0300 Subject: xorg 6.8.2 vs nvidia 7174 Message-ID: <20050412002025.3f4addd1@xxx> We're two people so far with this issue. Both have built xorg 6.8.2 on a rather non-standard system, from source. The nvidia module seems fine and loads, but X complains about (EE) not able to load the nvidia module. Further info and an attachment (nvidia-bug-report.zip) with all kinds of useful info about my environment, here: http://www.nvnews.net/vbulletin/showpost.php?p=585229&postcount=6 There seems to be no useful ideas from the nvidia crowd, so I thought I'd run this by you.
From ijs at txcorp.com Mon Apr 11 15:16:20 2005 From: ijs at txcorp.com (Irek Szczesniak) Date: Mon, 11 Apr 2005 16:16:20 -0600 (MDT) Subject: Xvfb & backing store: still not working Message-ID:
Best, Irek
From idr at us.ibm.com Mon Apr 11 15:43:22 2005 From: idr at us.ibm.com (Ian Romanick) Date: Mon, 11 Apr 2005 15:43:22 -0700 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To:
From benh at kernel.crashing.org Mon Apr 11 16:50:02 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 12 Apr 2005 09:50:02 +1000 Subject: [PATCH] radeon: Release DDC i2c lines after probe In-Reply-To: <[email protected]> References: <1112576093.31872.316.camel@gaston> <[email protected]> Message-ID: <1113263402.5387.3.camel@gaston> On Mon, 2005-04-11 at 11:33 -0400, Mike A. Harris wrote: > We've had several people report this bug. ;o) Please make sure > this gets filed in bugzilla if it isn't in CVS already. ;o) Daniels commited it to trunk. I plan to do some backport of a bunch of radeon patches to 2.6.2 today including this one as well. I'm not sure what Roland plans are for a 2.6.3 release, but at least the patches will be available for distros to pickup. Ben. From benh at kernel.crashing.org Mon Apr 11 16:57:56 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 12 Apr 2005 09:57:56 +1000 Subject: [PATCH] radeon: Release DDC i2c lines after probe In-Reply-To: <1113263402.5387.3.camel@gaston> References: <1112576093.31872.316.camel@gaston> <[email protected]> <1113263402.5387.3.camel@gaston> Message-ID: <1113263876.5388.11.camel@gaston> On Tue, 2005-04-12 at 09:50 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2005-04-11 at 11:33 -0400, Mike A. Harris wrote: > > > We've had several people report this bug. ;o) Please make sure > > this gets filed in bugzilla if it isn't in CVS already. ;o) > > Daniels commited it to trunk. I plan to do some backport of a bunch of > radeon patches to 2.6.2 today including this one as well. I'm not > sure what Roland plans are for a 2.6.3 release, but at least the patches > will be available for distros to pickup. As david noticed: 6.8.2 and 6.8.3, not 2.6.2 and 2.6.3, I'm mixing up with kernel releases now :) Ben.
From daniel at fooishbar.org Mon Apr 11 17:30:58 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 12 Apr 2005 10:30:58 +1000 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 11, 2005 at 01:24:47PM -0400, Adam Jackson wrote: > Commit procedure to HEAD: > > - cvs up > - apply patch > - edit xc/ChangeLog, add an entry for the change. Include at minimum the > date, name, email address, files changed, bugzilla ID and change > description. If the patch was written by someone else, give them credit. > - cvs commit, with the change description from the ChangeLog as the commit > message. > - Close the bug. > > Having to manually edit the ChangeLog is the only really painful part. Anyone
> who wants to automate that? There's a script called prepare-ChangeLog.pl or something which does part of this, but *complete* automation is really uncool. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
From davidr at novell.com Mon Apr 11 18:02:46 2005 From: davidr at novell.com (David Reveman) Date: Tue, 12 Apr 2005 03:02:46 +0200 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: > David Reveman wrote: > > > 1. Made glcore use MGL namespace. This allows me to always have software > > mesa available and this is currently necessary as there might not be > > enough resources to use the *real* GL stack with Composite. It might not > > be necessary when we're using framebuffer objects but I still think it's > > a good idea. This works fine when running Xgl on top of nvidia's GL > > stack or software mesa, but I haven't been able to get it running on top > > of mesa/DRI yet. > > > > 2. Made all GL calls in server side GLX go through another dispatch > > table. Allows me to switch between software mesa and *real* GL stack as > > I like. This is also necessary as extension function pointers might be > > different between contexts and we need to wrap some GL calls. e.g. > > glViewport needs an offset. > > > > Both these changes are available as patches from here: > > http://www.cs.umu.se/~c99drn/xgl-glx/ > > > > xserver-mesa.diff also include some changes required to get xserver > > compiling with mesa CVS and a few lines to support ARGB visuals. > > xserver-glx.diff modifies files that seem to be auto generated but I > > didn't find the source to that so I just made the changes directly. Most > > of these changes were done by running a regexp on all files in > > xserver/GL/glx directory. > > > > Does this seem like reasonable changes? > > So, it turns out that I'm currently working on some similar stuff. > Basically, I'm competely ripping up the interface between libglx ("the > loader" hereafter) and libGLcore ("the driver" hereafter). The final > goal is to get libglx to load a DRI driver. A big part of this is > replacing the static dispatch functions (e.g., glVertex3fv) in libGLcore > with a dispatch table, like is used on the client-side. Good, just what I need. > > The net result is that *all* the gl* functions are *gone* from the > driver. The driver's bindContext function populates a dispatch table > and calls _glapi_set_dispatch. Anything in the loader that wants to > call glVertex3fv just does some flavor of 'dispatch->Vertex3fv(v)'. Pretty much exactly what I'm doing in Xgl right now. > Another big part has been to replace all the "auto generated" code with > new autogenerated code. The replacement code *will* have scripts > available, and uses the gl_API.xml "stuff" in src/mesa/glapi in the Mesa > tree. > > I haven't committed (or released as patches) any of this yet because > it's pretty big, and I don't see a clear way to cherry-pick any parts of > it out. Pretty much all of my changes end up breaking GLX for Darwin > and cygwin. After looking at your xserver-glx.diff patch, I'll see if I > can pull out my dispatch table changes. > It would be nice for me if we can get something like that into CVS soon. Even if it's just some temporary solution that we'll use until you're finished with the real thing that's fine with me. > [snip] > > > - All visuals will be GL visuals and by reviving GL_ARB_render_texture > > and implementing it in Xgl we'll make it possible for GL applications to > > bind a X drawable to a texture id. This is what a GL compositing manager > > will do for all top level windows. > > Can you elaborate on this more? The reason I'm asking is that, with the > advent of EXT_framebuffer_object, there is almost no chance that there > will ever be a GLX_ARB_render_texture extension. Even before > EXT_framebuffer_object there were a few efforts to start a working group > for that extension, and there just wasn't enough interest to get it going. Sure. Using the Composite extension and a GL based compositing manager for drawing the desktop is what we want. What a GL based compositing manager needs to be able to draw the desktop is top level windows as textures. Xgl already stores top level windows as textures so this can be very efficient with Xgl. What we need is some way for the compositing manager to bind an X drawable to a texture id in it's GL context. So we need a new window system dependent GL extensions for this. Accidentally this happens to be almost exactly what GLX_ARB_render_texture is supposed to do, maybe we can just use that extension now that we found a use for it. I'm going to implement this in Xgl and we can then see what we want to do. New extension or use GLX_ARB_render_texture, doesn't really matter for me. But it's going to supply the functionality of GLX_ARB_render_texture either way. -David From roland.mainz at nrubsig.org Mon Apr 11 18:10:30 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Tue, 12 Apr 2005 03:10:30 +0200 Subject: Speedo fonts - Are they still supported? References: <[email protected]> <[email protected]> Message-ID: <[email protected]> "Mike A. Harris" wrote: > > Someone just caught me in IRC with this, and I couldn't quickly > > determine the answer, and don't use speedo fonts myself so I thought > > I'd pass the question on here: > > > > I've been getting some bug reports about speedo fonts not working. > > The speedo module was removed from Xorg, presumeably because > > freetype handles speedo fonts now (unless I am mistaken). > > > > Can someone state canonically wether speedo fonts are still supported > > or not, and wether that depends on particular freetype releases or > > not? Should it work both with the server standalone, as well as > > using xfs? > > > > If speedo is not supported however, then we should not install > > the speedo font files anymore. > > After chatting with others a bit, nobody seemed to know why > speedo no longer works, so I dug into it deeper and discovered > the following: > > https://bugs.freedesktop.org/show_bug.cgi?id=548 That issue was debated long long ago what we should do with the old rasterizers (Speedo, PS Type1 etc.). For Speedo the issue was that AFAIK no new fonts were made within the last 10 (or more) years, TrueType has AFAIK superset all of it's functionality, a couple of Unicies (AFAIK Solaris and AIX) dropped support for Speedo fonts and all the Speedo fonts distributed at X.org are available as PS Type1 fonts, too. So far it made sense to get rid of it to save some bytes in the Xserver code... > Date: Sun, 25 Apr 2004 15:34:12 -0700 > From: Roland Mainz
From brian.paul at tungstengraphics.com Mon Apr 11 18:44:00 2005 From: brian.paul at tungstengraphics.com (Brian Paul) Date: Mon, 11 Apr 2005 19:44:00 -0600 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected] t> <[email protected]> Message-ID: <[email protected]> David Reveman wrote: > On Mon, 2005-04-11 at 13:18 -0400, Adam Jackson wrote: >> On Monday 11 April 2005 12:33, David Reveman wrote: > >>>I had to add a 8A8R8G8B pixel format to XMesa for ARGB visuals to work >>>properly. This patch should do that: >>>http://www.cs.umu.se/~c99drn/xgl-glx/Mesa-PF_8A8R8G8B.diff >> >>This would actually be really cool to land on its own. > > > That patch is in good shape. Anyone with proper access to Mesa source > can commit it if they like. Done. -Brian
From ajax at nwnk.net Mon Apr 11 19:06:37 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 11 Apr 2005 22:06:37 -0400 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Monday 11 April 2005 20:56, David Reveman wrote: > On Mon, 2005-04-11 at 13:18 -0400, Adam Jackson wrote: > > I'm not quite clear yet on how you decide whether to use the software or > > hardware paths. Is it per context? Per client? Per drawable? > > I think it would have to be per context. > > The temporary solution I'm using right now is to make this decision when > the the client creates it's first buffer, if we can accelerate drawing > to the buffer a native context is used, otherwise a software context is > used. This is not a solid solution and it can't be used in the future. > > The problem is that with Composite extension present a drawable can at > any time be redirected to a pixmap. So what do we do if the native GL > stack can't handle this? With framebuffer objects available we can > probably always allocate another texture and redirect drawing to it, the > native GL stack will handle software fall-back if necessary. What do we > do when framebuffer objects are not available? > > 1. Don't support GLX at all? I think this would be a major drawback. > > 2. Use software GL. And possibly use native GL for root window as it > can't be redirected and it would make a compositing manager run > accelerated. This is what I hoped we could get working. > > 3. Move native context to software when a window is redirected. Seems > like a really bad idea to me. Don't think we could ever get this working > properly. I don't think we should be worrying too much about the case of not having fbo's available. I'd rather just have those drivers not be strictly conformant until they get fbo support added. Yes, this means DRI needs a lot of work. I'm willing to accept #2 for this case, 3 would be almost as hard to get right as just adding fbo's. > > I think you'll have major issues trying to use two rendering engines at > > once. > > That's bad as I think that not getting this working will mean that we > have to go with option 1 from above. > > I've had no trouble with using both GLcore and nvidia's GL stack in Xgl > so far... I think it could be worth investigate the possibilities for > getting this working with all GL stacks. Isn't there anyone with some > experience in this, seems like something someone would have tried > before... It'll work fine as long as they never need to share state. But if as you said all contexts are shared, and you try to use a read buffer from one engine and a draw buffer from another, you lose. Your only option there is to push the state to both engines, all the time. Whereas if you only have one GL engine that's capable enough for what you want to do, then all you're doing is fixing the libglx interface. > If we can get this working, GLX visuals that always use software could > also be available. I think that can be useful as well. That's a neat idea. Do we need to add some fields to the fbconfigs to expose this, maybe a new token for GLX_CAVEAT ? > > > All contexts need to be shared inside Xgl so we're going to have to > > > keep hash tables in Xgl to deal with GLX contexts. > > > > Is this an artifact of using glitz, or is this something we'd see with > > other backends too? > > As long as we're using textures for drawables all contexts will have to > be shared. We need to be able to render to a drawable using both the > client specific context and using Xgl's core drawing context used for > regular X11 drawing requests. This seems to be ignoring the idea that there might be direct-rendering clients involved. If every GL application talking to this X server is indirect, fine, which even makes sense when Xgl is nested like it is now. There's an alternative approach here. What you said is true, given GL stacks as they exist now contexts have to be shared to share drawables. It may be possible to write an extension such that GL doesn't have this limitation. If we're planning to support direct-rendering clients I think we'll have to. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
/* Make imake noisier. Note that this is ineffective for 3.0 <= GCC <= 3.2 */ #ifndef ImakeWarningFlags # ifdef Gcc28Warnings # define ImakeWarningFlags Gcc28Warnings # else # define ImakeWarningFlags /* */ # endif #endif
-#if ((GccMajorVersion == 3) && (GccMinorVersion >= 1)) || (GccMajorVersion > 3) +/* PPC and S390(x) always need -fno-strict-aliasing to avoid crash in in + * Freetype code and some other locations */ +#if (((GccMajorVersion == 3) && (GccMinorVersion >= 1)) || (GccMajorVersion > 3)) \ + || defined (PpcArchitecture) \ + || defined (s390Architecture) \ + || defined (s390xArchitecture) # define GccAliasingArgs -fno-strict-aliasing #else # define GccAliasingArgs /* */ #endif
#if HasGcc2 && defined(i386Architecture) # ifndef DefaultGcc2i386Opt # define DefaultGcc2i386Opt -O2 -fno-strength-reduce GccAliasingArgs # endif #endif
#if HasGcc2 && defined(AMD64Architecture) # ifndef DefaultGcc2AMD64Opt # define DefaultGcc2AMD64Opt -O2 -fno-strength-reduce GccAliasingArgs # endif #endif
#if HasGcc2 && defined(AlphaArchitecture) # ifndef DefaultGcc2AxpOpt # define DefaultGcc2AxpOpt -O2 GccAliasingArgs From benh at kernel.crashing.org Tue Apr 12 00:01:45 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 12 Apr 2005 17:01:45 +1000 Subject: Radeon patches against stable branch Message-ID: <1113289305.5387.53.camel@gaston> Hi ! I've spent today backporting a lot of my bug fixes from HEAD to the stable branch. I've intentionally not backported what I consider features like the whole ColorTiling stuff, or DMA Xv, and I may have missed a couple, but I hope this lot is enough to make the difference on PowerMacs as well. I will start opening Bugzilla entries tomorrow or later this week along with providing proper descriptions for the patches, but in the meantime, for those who are interested or packaging distros with 6.8.2, here is the whole lot. I just test compile, I've not actually had time to properly test yet, though I will hopefully do it as I create the Bugzilla entries. http://gate.crashing.org/~benh/xorg The "series" file is a the usual quilt series file containing the list of patch to apply in order. The only "missing" one in there (and not in HEAD neither) is the problem I have with the default TMDS PLL values for RV350. I need to slighlty change the table for correct result here on a G5 with an Apple 23" Cinema HD monitor, but the value currently in the driver is what the HW folks at ATI told Hui to use... so I'm not too sure what to do there. (Owen: Keep the modified value in YDL, the G5 card definitely need 155000 and not 150000) Enjoy! Ben.
From davidr at novell.com Tue Apr 12 01:03:39 2005 From: davidr at novell.com (David Reveman) Date: Tue, 12 Apr 2005 10:03:39 +0200 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, 2005-04-11 at 22:06 -0400, Adam Jackson wrote: > On Monday 11 April 2005 20:56, David Reveman wrote: > > On Mon, 2005-04-11 at 13:18 -0400, Adam Jackson wrote: > > > I'm not quite clear yet on how you decide whether to use the software or > > > hardware paths. Is it per context? Per client? Per drawable? > > > > I think it would have to be per context. > > > > The temporary solution I'm using right now is to make this decision when > > the the client creates it's first buffer, if we can accelerate drawing > > to the buffer a native context is used, otherwise a software context is > > used. This is not a solid solution and it can't be used in the future. > > > > The problem is that with Composite extension present a drawable can at > > any time be redirected to a pixmap. So what do we do if the native GL > > stack can't handle this? With framebuffer objects available we can > > probably always allocate another texture and redirect drawing to it, the > > native GL stack will handle software fall-back if necessary. What do we > > do when framebuffer objects are not available? > > > > 1. Don't support GLX at all? I think this would be a major drawback. > > > > 2. Use software GL. And possibly use native GL for root window as it > > can't be redirected and it would make a compositing manager run > > accelerated. This is what I hoped we could get working. > > > > 3. Move native context to software when a window is redirected. Seems > > like a really bad idea to me. Don't think we could ever get this working > > properly. > > I don't think we should be worrying too much about the case of not having > fbo's available. I'd rather just have those drivers not be strictly > conformant until they get fbo support added. Yes, this means DRI needs a lot > of work. I'm willing to accept #2 for this case, 3 would be almost as hard > to get right as just adding fbo's. > > > > I think you'll have major issues trying to use two rendering engines at > > > once. > > > > That's bad as I think that not getting this working will mean that we > > have to go with option 1 from above. > > > > I've had no trouble with using both GLcore and nvidia's GL stack in Xgl > > so far... I think it could be worth investigate the possibilities for > > getting this working with all GL stacks. Isn't there anyone with some > > experience in this, seems like something someone would have tried > > before... > > It'll work fine as long as they never need to share state. But if as you said
> all contexts are shared, and you try to use a read buffer from one engine and > a draw buffer from another, you lose. Your only option there is to push the > state to both engines, all the time. Oh, a software context and native context never needs to be shared. GLcore works just fine separately. All regular X drawing requests are done using the native stack, if software fall-back is required, that's always done by fb. Only the native contexts need to be shared. Except for when a software context likes to bind a drawable to a texture id, but that would be very rare and we can probably work around that with some special hook in GLcore if we even want to support it. So I should be able to get things working the way I planned then, right? Sorry for the confusion. As soon as I get my code into CVS I think it'll be much easier to see how this is supposed to work. > > Whereas if you only have one GL engine that's capable enough for what you want
> to do, then all you're doing is fixing the libglx interface. > > > If we can get this working, GLX visuals that always use software could > > also be available. I think that can be useful as well. > > That's a neat idea. Do we need to add some fields to the fbconfigs to expose > this, maybe a new token for GLX_CAVEAT ? Yes, something like that would be useful. We don't want clients to do: glXCreateContext, XCreateWindow, glXMakeCurrent, glGetString just to check if they're using a software or native renderer. > > > > > All contexts need to be shared inside Xgl so we're going to have to > > > > keep hash tables in Xgl to deal with GLX contexts. > > > > > > Is this an artifact of using glitz, or is this something we'd see with > > > other backends too? > > > > As long as we're using textures for drawables all contexts will have to > > be shared. We need to be able to render to a drawable using both the > > client specific context and using Xgl's core drawing context used for > > regular X11 drawing requests. > > This seems to be ignoring the idea that there might be direct-rendering > clients involved. If every GL application talking to this X server is > indirect, fine, which even makes sense when Xgl is nested like it is now. > > There's an alternative approach here. What you said is true, given GL stacks > as they exist now contexts have to be shared to share drawables. It may be > possible to write an extension such that GL doesn't have this limitation. If > we're planning to support direct-rendering clients I think we'll have to. I'm aware of this. If such an extension allows us to not use shared contexts that's just fine, we can easily switch to not using shared contexts when this is possible as it's only used for textures access right now. Back to the original question. Do we need to keep hash tables in Xgl for textures, display lists... ? We probably need this for textures anyway to deal with GLX_ARB_render_texture like functionality. To be able to use scissor boxes for pixel ownership test, we might also need some additional info from display lists so we'll have to wrap those... so I think we need hash tables in Xgl anyway. But I'll keep in mind that contexts will not necessarily be shared in the future. -David
From linlamer at cox.net Tue Apr 12 05:29:48 2005 From: linlamer at cox.net (drag sidious) Date: Tue, 12 Apr 2005 07:29:48 -0500 Subject: XGI and open source drivers. In-Reply-To:
From linlamer at cox.net Tue Apr 12 05:47:14 2005 From: linlamer at cox.net (drag sidious) Date: Tue, 12 Apr 2005 07:47:14 -0500 Subject: XGI and open source drivers. Message-ID: <[email protected]> (sorry. I re-sent this email because I didn't realise that the previous one would reference to another thread.)
I am very curious about this page: http://www.xgitech.com/about/about_press1.asp?CTID={C3FD7D03-6BE1-4BB9-9F34-1221 E723B87F} XGI is claiming that they released the source code for their cards. If they are not being misleading in their statements I think I found the video card I am going to buy next. I would love to replace my Nvidia card with something that actually used free drivers... But I am not very trustworthy of any company until I hear more about it. So does anybody have any news on this? They said in the page to search the bug reports page for more information so I looked for 'XGI' and I came up with this: https://bugs.freedesktop.org/show_bug.cgi?id=1905 https://bugs.freedesktop.org/show_bug.cgi?id=2761 This is a bit exciting if it's true..
From xavier.bestel at free.fr Tue Apr 12 06:04:16 2005 From: xavier.bestel at free.fr (Xavier Bestel) Date: Tue, 12 Apr 2005 15:04:16 +0200 Subject: XGI and open source drivers. In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1113311056.17538.109.camel@gonzales> Le mardi 12 avril 2005 ? 07:47 -0500, drag sidious a ?crit : > They said in the page to search the bug reports page for more > information so I looked for 'XGI' and I came up with this: > https://bugs.freedesktop.org/show_bug.cgi?id=1905 > https://bugs.freedesktop.org/show_bug.cgi?id=2761 > > This is a bit exciting if it's true.. In my understanding of what's written in these bugreports, only the unaccelerated part is free (with maybe old 2D acceleration). The 3D accel's part (which will be used for Xgl) state is uncertain. Xav
From mhopf at suse.de Tue Apr 12 08:49:25 2005 From: mhopf at suse.de (Matthias Hopf) Date: Tue, 12 Apr 2005 17:49:25 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Apr 11, 05 18:33:32 +0200, David Reveman wrote: > I've got GLX and indirect rendering working with Xgl. It's accelerated > and works fine with Composite. There's of course a lot more work to be Great job, David! > With all the above changes in place I can run simple OpenGL applications > accelerated while using a compositing manager, and by changing a few > lines in the applications I can get them to use ARGB visuals as well. Just some thoughts of me, if I get this correctly: - Only indirect rendering is possible at the moment, and this isn't trivially changeable. - You are only able to render redirected OpenGL apps accelerated, when the driver has PBuffer support, because you need a rendering context for the application (if you do not want to re-invent the wheel everywhere and do state tracking yourself). Do you need PBuffers for non-redirected windows as well? - As soon as framebuffer objects exist and should be used for off-screen rendering contexts, we would need something like ARB_render_target, otherwise we couldn't provide the applications with a context to render into. Or we have to intercept all BindRenderbufferEXT() etc. calls from the application. So are you doing something differently when nothing is redirected? What kind of context do OpenGL applications get when creating their rendering context, where do they actually render into? You current root context with scissor tests applied, or is it handled just like the redirected case with PBuffers?
What do we need for direct rendering in the context of Xgl, and more importantly, what do we actually want? I can see three scenarios - with transitions possible: - Non-redirected (no composite manager), windowed applications - Redirected, windowed applications - Full-screen applications The reason I split here for windowed / full-screen applications is that full-screen applications *could* be handled differently, and as these are typically games lag must be avoided more strictly than with the other cases. I'm currently not sure if it save to assume that full-screen apps would never interfere with a composite manager, but I have the feeling they shouldn't. Do we have a possibility to handle all three scenarios the same way? Currently I doubt, because composite managers inherently add lag. Is this something to be discussed outside Xgl because it is composite related? Could very well be.
So how can we make - in the long term - make direct rendering with Xgl possible? So far I think we basically need - EXT_framebuffer_object for rendering X requests into a texture in the server - some extension yet to be specified, which allows sharing of textures between processes (Xgl and application) - ARB_render_texture to create a context on the application side that renders into a texture Then there's still the issue that the libGL on the application side would have to create a context that renders into a texture, without the application actually noticing it. This is currently what scares me most. One alternative would be another extension that would allow the transport of one context to another process, so the context for rendering into a texture could be created on the Xgl side, and the context could then be transferd to the application side. This sounds scary as well. I doubt that an extension for shared contextes would work without patching the application side libGL, either. Any other ideas? What else did I forget? For the non-redirected case, an application could render into its own OpenGL context, but this would make occlusion, window stacking, etc. a nightmare.
> The following is not working: > - Context Sharing (all contexts are currently shared) That is, textures are currently only working correctly, if all applications use GenTextures(), right? > - Drawing to front buffer In the redirected case as well? Does this not work at all, or is it just that glFlush() does not call the update routine in order to copy drawing results to the screen? > Getting front buffer drawing to work is a bit harder. We need to report > damage and do pixel ownership test. Using the current scissor box when > reporting damage is probably good enough but I don't have good solution > for pixel ownership test. I guess we're going to have to do multiple > drawing operations with different scissor boxes but that will make > display lists much harder to handle... What happens if the application wants to use the scissor test on its own? For indirect rendering we could always interprete the protocol ourself (Ugh) and adapt the test to our needs, but for direct rendering I have no clue. > - Textures are used for pixmaps and framebuffer objects for drawing to > them. No GL_EXT_framebuffer_object support, no accelerated offscreen > drawing. Agreed. This sounds sensible. (the rest as well) > - The compositing manager will most likely be using indirect GLX for > drawing the desktop. A double buffered GL visual can be used to > efficiently draw the desktop even when GL_EXT_framebuffer_object isn't > present and buffer flips can be used when redrawing the whole screen. Right, for the compositing manager only being able to use indirect rendering shouldn't be a problem. At least right now I cannot imagine a usefull one that needs so much geometry that it is severely hindered.
Thanks Matthias -- Matthias Hopf
From idr at us.ibm.com Tue Apr 12 08:52:50 2005 From: idr at us.ibm.com (Ian Romanick) Date: Tue, 12 Apr 2005 08:52:50 -0700 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> David Reveman wrote: > On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: >>David Reveman wrote: >> >>I haven't committed (or released as patches) any of this yet because >>it's pretty big, and I don't see a clear way to cherry-pick any parts of >>it out. Pretty much all of my changes end up breaking GLX for Darwin >>and cygwin. After looking at your xserver-glx.diff patch, I'll see if I >>can pull out my dispatch table changes. > > It would be nice for me if we can get something like that into CVS soon. > Even if it's just some temporary solution that we'll use until you're > finished with the real thing that's fine with me. Okay. I'll see what I can come up with. >>Can you elaborate on this more? The reason I'm asking is that, with the >>advent of EXT_framebuffer_object, there is almost no chance that there >>will ever be a GLX_ARB_render_texture extension. Even before >>EXT_framebuffer_object there were a few efforts to start a working group >>for that extension, and there just wasn't enough interest to get it going. > > Sure. > > Using the Composite extension and a GL based compositing manager for > drawing the desktop is what we want. What a GL based compositing manager > needs to be able to draw the desktop is top level windows as textures. > Xgl already stores top level windows as textures so this can be very > efficient with Xgl. What we need is some way for the compositing manager > to bind an X drawable to a texture id in it's GL context. So we need a > new window system dependent GL extensions for this. Accidentally this > happens to be almost exactly what GLX_ARB_render_texture is supposed to > do, maybe we can just use that extension now that we found a use for it. > > I'm going to implement this in Xgl and we can then see what we want to > do. New extension or use GLX_ARB_render_texture, doesn't really matter > for me. But it's going to supply the functionality of > GLX_ARB_render_texture either way. But that was my point. Go look in the extension registry. There is *NO* GLX_ARB_render_texture. It does not exist. Because of that, I doubt that any implementation that doesn't already implement some version of this (I think Nvidia has something on Linux) is going to want to implmement it. EXT_framebuffer_object, on the other hand, is quite likely to end up either as an ARB extension or in the core spec "pretty soon". We just need more implementation & usage experience.
From idr at us.ibm.com Tue Apr 12 09:17:44 2005 From: idr at us.ibm.com (Ian Romanick) Date: Tue, 12 Apr 2005 09:17:44 -0700 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Ian Romanick wrote: > David Reveman wrote: >> On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: >>> David Reveman wrote: >>> >>> I haven't committed (or released as patches) any of this yet because >>> it's pretty big, and I don't see a clear way to cherry-pick any parts >>> of it out. Pretty much all of my changes end up breaking GLX for >>> Darwin and cygwin. After looking at your xserver-glx.diff patch, >>> I'll see if I can pull out my dispatch table changes. >> >> It would be nice for me if we can get something like that into CVS soon. >> Even if it's just some temporary solution that we'll use until you're >> finished with the real thing that's fine with me. > > Okay. I'll see what I can come up with. I just filed bug #2996 to track patches. https://bugs.freedesktop.org/show_bug.cgi?id=2996
From idr at us.ibm.com Tue Apr 12 10:18:12 2005 From: idr at us.ibm.com (Ian Romanick) Date: Tue, 12 Apr 2005 10:18:12 -0700 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> David Reveman wrote: > The problem is that with Composite extension present a drawable can at > any time be redirected to a pixmap. So what do we do if the native GL > stack can't handle this? With framebuffer objects available we can > probably always allocate another texture and redirect drawing to it, the > native GL stack will handle software fall-back if necessary. What do we > do when framebuffer objects are not available? When an XVisualInfo is used to create the context (i.e., using glXCreateContext) and the pixmap (i.e., using glXCreateGLXPixmap), the context *MUST* support rendering to a pixmap. When using the fbconfig interfaces, there is a bit in the fbconfig that specifies whether or not the fbconfig can be used with a pixmap. So, if you make the following call: const int attribs[] = { GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT | GLX_PIXMAP_BIT, None }; ... configs = glXChooseFBConfig( dpy, screen, attribs, & num_configs ); The fbconfigs you get back, if any, will all support creating contexts that can render to both windows and pixmaps. I think it is perfectly reasonable for us to require that, in addition to the other requirements for available fbocnfigs, any implementation support at least one fbconfig that meets those requirements. This is especially true since rendering to pixmaps already has to be supported for the pre-1.3 GLX interfaces. You can be 90+% sure that nobody will hardware accelerate rendering to pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;)
From otaylor at redhat.com Tue Apr 12 11:33:42 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 12 Apr 2005 14:33:42 -0400 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote: > David Reveman wrote: > > > The problem is that with Composite extension present a drawable can at > > any time be redirected to a pixmap. So what do we do if the native GL > > stack can't handle this? With framebuffer objects available we can > > probably always allocate another texture and redirect drawing to it, the > > native GL stack will handle software fall-back if necessary. What do we > > do when framebuffer objects are not available? > > When an XVisualInfo is used to create the context (i.e., using > glXCreateContext) and the pixmap (i.e., using glXCreateGLXPixmap), the > context *MUST* support rendering to a pixmap. When using the fbconfig > interfaces, there is a bit in the fbconfig that specifies whether or not > the fbconfig can be used with a pixmap. > > So, if you make the following call: > > const int attribs[] = { GLX_DRAWABLE_TYPE, > GLX_WINDOW_BIT | GLX_PIXMAP_BIT, > None }; > > ... > > configs = glXChooseFBConfig( dpy, screen, attribs, & num_configs ); > > The fbconfigs you get back, if any, will all support creating contexts > that can render to both windows and pixmaps. > > I think it is perfectly reasonable for us to require that, in addition > to the other requirements for available fbocnfigs, any implementation > support at least one fbconfig that meets those requirements. This is > especially true since rendering to pixmaps already has to be supported > for the pre-1.3 GLX interfaces. > > You can be 90+% sure that nobody will hardware accelerate rendering to > pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;) I get the impression that you are looking at the wrong side of rendering to pixmaps ... the ability to render to a pixmap via the GL API is really pretty uninteresting. The *implementation* of such is what we need. Hardware acceleration to "pixmaps" is exactly what we need here, because a redirected window is (from the point of view of the server internals) a pixmap, and in fact can be named as a pixmap via the Composite API. For indirect rendering, we can simply redefine a "pixmap" to be a fbo, but for direct rendering, we need something that: A) Has a global XID A) Can be rendered to by multiple clients B) Is offscreen Which is pretty much the general problem of accelerated rendering to a pixmap. We don't have to support rendering to *all* pixmaps, but we don't escape what seems to me to be the hard parts of rendering to pixmaps. Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From ajax at nwnk.net Tue Apr 12 12:04:01 2005 From: ajax at nwnk.net (Adam Jackson) Date: Tue, 12 Apr 2005 15:04:01 -0400 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tuesday 12 April 2005 14:52, Ian Romanick wrote: > Owen Taylor wrote: > > On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote: > >>You can be 90+% sure that nobody will hardware accelerate rendering to > >>pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;) > > > > I get the impression that you are looking at the wrong side of rendering > > to pixmaps ... the ability to render to a pixmap via the GL API is > > really pretty uninteresting. The *implementation* of such is what > > we need. > > > > Hardware acceleration to "pixmaps" is exactly what we need > > here, because a redirected window is (from the point of view of the > > server internals) a pixmap, and in fact can be named as a pixmap via > > the Composite API. > > ...which will quite likely never happen. There *are* reasons that > OpenGL implementors abandoned pixmaps and invented pbuffers. Some confusion over terminology here, I think: surface - generic rendering target. has pixels in it. Pixmap - an X rendering target containing a surface and some X state GLXPixmap - a GLX rendering target containing a Pixmap and some GLX state We need accelerated rendering to offscreen surfaces but not necessarily to the other two. The compmgr needs a way to get at the offscreen surface of a window, which is done by binding it to a Pixmap (note capitalization). This will remain the case for non-GLX clients. For GLX clients we merely need access to the offscreen surface that rendering has been redirected to by the Composite machinery. This surface could be exposed as a pbuffer or an fbo, or through EXT_render_target, or whatever. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From davidr at novell.com Tue Apr 12 12:15:39 2005 From: davidr at novell.com (David Reveman) Date: Tue, 12 Apr 2005 21:15:39 +0200 Subject: [Mesa3d-dev] GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tue, 2005-04-12 at 08:52 -0700, Ian Romanick wrote: > David Reveman wrote: > > On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: > >>David Reveman wrote: > >> > >>I haven't committed (or released as patches) any of this yet because > >>it's pretty big, and I don't see a clear way to cherry-pick any parts of > >>it out. Pretty much all of my changes end up breaking GLX for Darwin > >>and cygwin. After looking at your xserver-glx.diff patch, I'll see if I > >>can pull out my dispatch table changes. > > > > It would be nice for me if we can get something like that into CVS soon. > > Even if it's just some temporary solution that we'll use until you're > > finished with the real thing that's fine with me. > > Okay. I'll see what I can come up with. > > >>Can you elaborate on this more? The reason I'm asking is that, with the > >>advent of EXT_framebuffer_object, there is almost no chance that there > >>will ever be a GLX_ARB_render_texture extension. Even before > >>EXT_framebuffer_object there were a few efforts to start a working group > >>for that extension, and there just wasn't enough interest to get it going. > > > > Sure. > > > > Using the Composite extension and a GL based compositing manager for > > drawing the desktop is what we want. What a GL based compositing manager > > needs to be able to draw the desktop is top level windows as textures. > > Xgl already stores top level windows as textures so this can be very > > efficient with Xgl. What we need is some way for the compositing manager > > to bind an X drawable to a texture id in it's GL context. So we need a > > new window system dependent GL extensions for this. Accidentally this > > happens to be almost exactly what GLX_ARB_render_texture is supposed to > > do, maybe we can just use that extension now that we found a use for it. > > > > I'm going to implement this in Xgl and we can then see what we want to > > do. New extension or use GLX_ARB_render_texture, doesn't really matter > > for me. But it's going to supply the functionality of > > GLX_ARB_render_texture either way. > > But that was my point. Go look in the extension registry. There is > *NO* GLX_ARB_render_texture. I know that. > It does not exist. Because of that, I > doubt that any implementation that doesn't already implement some > version of this (I think Nvidia has something on Linux) is going to want > to implmement it. I don't want them to implement it. I'll implement it, inside Xgl. > EXT_framebuffer_object, on the other hand, is quite > likely to end up either as an ARB extension or in the core spec "pretty > soon". We just need more implementation & usage experience. I'm all for EXT_framebuffer_object, it's the key to the success of Xgl. It's going to be used inside Xgl for all offscreen drawing. But I don't see how EXT_framebuffer_object will help for a client that needs to bind a window system drawable to a texture. I want the compositing manager to be able to do something like this for every redirected window: GLuint texture; Pixmap pixmap; glGenTextures (1, &texture); pixmap = XCompositeNameWindowPixmap (dpy, redirected_window); glBindTexture (GL_TEXTURE_2D, texture); glXBindTexImageARB (dpy, pixmap); and then be able to draw the desktop using these textures. Is it possible to do this just using EXT_framebuffer_object? I don't see how. -David
From davidr at novell.com Tue Apr 12 12:16:34 2005 From: davidr at novell.com (David Reveman) Date: Tue, 12 Apr 2005 21:16:34 +0200 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote: > David Reveman wrote: > > > The problem is that with Composite extension present a drawable can at > > any time be redirected to a pixmap. So what do we do if the native GL > > stack can't handle this? With framebuffer objects available we can > > probably always allocate another texture and redirect drawing to it, the > > native GL stack will handle software fall-back if necessary. What do we > > do when framebuffer objects are not available? > > When an XVisualInfo is used to create the context (i.e., using > glXCreateContext) and the pixmap (i.e., using glXCreateGLXPixmap), the > context *MUST* support rendering to a pixmap. When using the fbconfig > interfaces, there is a bit in the fbconfig that specifies whether or not > the fbconfig can be used with a pixmap. > > So, if you make the following call: > > const int attribs[] = { GLX_DRAWABLE_TYPE, > GLX_WINDOW_BIT | GLX_PIXMAP_BIT, > None }; > > ... > > configs = glXChooseFBConfig( dpy, screen, attribs, & num_configs ); > > The fbconfigs you get back, if any, will all support creating contexts > that can render to both windows and pixmaps. > > I think it is perfectly reasonable for us to require that, in addition > to the other requirements for available fbocnfigs, any implementation > support at least one fbconfig that meets those requirements. This is > especially true since rendering to pixmaps already has to be supported > for the pre-1.3 GLX interfaces. > > You can be 90+% sure that nobody will hardware accelerate rendering to > pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;) > That's a GLX specific solution. I definitely don't want that. It would mean that we can't run Xgl on top of a window system that doesn't have a fully working alternative to glXCreateGLXPixmap. -David
From otaylor at redhat.com Tue Apr 12 12:49:02 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 12 Apr 2005 15:49:02 -0400 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tue, 2005-04-12 at 11:52 -0700, Ian Romanick wrote: > Owen Taylor wrote: > > On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote: > > > >>You can be 90+% sure that nobody will hardware accelerate rendering to > >>pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;) > > > > I get the impression that you are looking at the wrong side of rendering > > to pixmaps ... the ability to render to a pixmap via the GL API is > > really pretty uninteresting. The *implementation* of such is what > > we need. > > > > Hardware acceleration to "pixmaps" is exactly what we need > > here, because a redirected window is (from the point of view of the > > server internals) a pixmap, and in fact can be named as a pixmap via > > the Composite API. > > ...which will quite likely never happen. There *are* reasons that > OpenGL implementors abandoned pixmaps and invented pbuffers. Let me be clear on what is needed. - We don't need to be able to take a random Pixmap ID, and render to it from a direct rendering client. - We *do* need to be able to do rendering to an offscreen buffer from a direct rendering client, then reference that with a pixmap ID in the server internals The only real reason I see the second as being easier than the first is that we know ahead of time (potentially at least) that the piece of offscreen memory is going to be used for GL rendering. (*) > > For indirect rendering, we can simply redefine a "pixmap" to be a fbo, > > but for direct rendering, we need something that: > > > > A) Has a global XID > > A) Can be rendered to by multiple clients > > B) Is offscreen > > > > Which is pretty much the general problem of accelerated rendering to > > a pixmap. We don't have to support rendering to *all* pixmaps, but we > > don't escape what seems to me to be the hard parts of rendering to > > pixmaps. > > At this point, I'm pretty confused. There is no hardware accelerated > direct-rendering to pixmaps today. Why will it be missed if it's not > implemented? I think I missed some detail as to why this needs to be > exposed. We don't need hardware accelerated direct rendering to pixmaps. We do need hardware accelerated direct rendering to pieces of memory that can be named as pixmaps. Just to review, the basic architecture of composite is:
Client -- renders --> Window +------+ [ backed ] +------+ Pixmap -- composites --> Screen (compositing manager ) The rendering step could be direct GL, indirect GL, X RENDER, or the classic X protocol. The compositing step could be indirect GL or RENDER. Currently, we think that indirect GL is the right thing, for that we actually just need to name the window contents as a texture, and not as a Pixmap, but the ability to name it as a Pixmap is in Composite protocol. Note that one possible simplification is to only support double buffered rendering to the back buffer and make the SwapBuffers step copy from fbo to pixmap/texture. Regards, Owen (*) Even that isn't a big advantage, since we could always just migrate the pixmap. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From eich at pdx.freedesktop.org Wed Apr 13 01:45:46 2005 From: eich at pdx.freedesktop.org (Egbert Eich) Date: Wed, 13 Apr 2005 10:45:46 +0200 Subject: dynamic driver configuration idea... In-Reply-To: [email protected] wrote on Friday, 8 April 2005 at 16:34:38 +1000 References: <[email protected]> Message-ID: <[email protected]> Dave Airlie writes: > I've been thinking about this and recently after using Thomas > Winischhofer's sisctrl application wondered why we don't have a > standard method for driver configuration... > > I'm thinking something like driconf does for DRI 3D drivers, but maybe > a bit more network aware, (btw driconf just writes a local .drirc > file, and it gets the config options from the actual driver binary and > this is read by the 3D client library at startup so you can have > differnet settings for different apps... etc..) > > it would probably be like a super xrandr, the driver could return an > XML description of what if wants to offer, a GUI app could build a GUI > from those options and could then send the results dynamically back to > the driver to reconfigure itself.. as every driver would have > different options I wouldn't feel the need to limit it through some > interface hence XML or something like that... > > Mainly I would think of CRT configurations, desktop size, driver > acceleration tweaks, like you see on Windows drivers .... also it > might have the option to write the X config file but that may not be > necessary... > > I can see security issues as well with what clients can access it .. > > btw I probably won't write this at all, just throwing the idea around > as that sisctrl panel doth rock when messing with TV-OUT on an SIS > laptop... I had a similar idea a while back. Starting from the attributes for Xv which depend on the capabilities of the driver/chipset. There the driver can provide some information on the properties of the attributes it accepts. My idea was to provide enough information so that a gui application can provide a meaningful interface even without knowing about the specific property. Additionally I wanted to cerate a registry for 'well known properties' so that their behavior can be uniform across drivers. My idea was to create an extension which would eventually have replaced the ill designed xf86misc extension (and the xf86vidmode extension). Also some functionalities of Xrandr (the screen resolution reconfig part, not the event notofication part) could have been placed there. Also a lot of the static config options from the drivers could have been made dynamic thru this mechanism. In short it would have consolidated most of the DDX specific extensions having to do with DDX configuration. Since then paradigms have changed as people explained that there is no need to craft an extension as it doesn't make sense to push this over the wire. This may be true to some extend - on the other hand thinking of thin clients with absolutely no local X client running there may be exceptions. Anyway, I kind of have abandoned that idea. Egbert.
From carl at personnelware.com Wed Apr 13 05:07:31 2005 From: carl at personnelware.com (Carl Karsten) Date: Wed, 13 Apr 2005 07:07:31 -0500 Subject: setting up xorg.conf In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> (recovering from cross post fumble... nothing new for the Ubuntu list, just getting both lists in the loop.) Daniel Stone wrote: > On Tue, Apr 12, 2005 at 12:47:40PM -0500, Carl Karsten wrote: > >>xorg guys have some interest in something that I thought I had seen here >>but I can't find it. Also, anyone leaning on ddcprobe may be interested >>in what I found. >> >>google ddcprobe: >> >>http://cvs.seul.org/cgi-bin/cvsweb-1.80.cgi/distrib/install/anaconda/ddcprobe/ README?rev=1.1.1.1&content-type=text/x-cvsweb-markup > > > This is the source our ddcprobe is based off, yes. > > >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138381 "ddcprobe >>claims to do a "Videocard DDC probe". However, in the course of >>troubleshooting bug 108681, I learned from Mike Harris that there is no >>such thing. I think it would be less misleading if it was called >>something like a "Videocard VBE probe". Even if that's not the best >>phrase either, it's much better and much closer to the truth than >>"Videocard DDC probe". > > > 'VBE probe' is rather meaningless -- what it should really say is 'VBE > DDC probe', but hopefully that won't be true for too long. As that bug > says, DDC is a generic name for describing the sort of probe that gets > done. VBE is one way to do it. Doing it by setting up I2C channels and > poking them in specific ways is another way to do it. We do the former. > > >>CarlK: it seems a common problem is getting the valid resolutions in >>xorg.conf >>CarlK: valid = ones that will work with my hardware (video card, video >>memory and monitor) >>ajax: if we had a way to probe DDC on a card without running all of X, > > ^^^^^^^^^^^^^^^^^^^ > he means via I2C channels > >>we could do that pretty reliably >>ajax: linux might give you enough info through sysfs to make that possible >>CarlK: ever heard of ddcprobe? >>libv: CarlK: that most likely uses VESA > > > It sure does. > > >>CarlK: /usr/sbin/ddcprobe - can't figure out where it comes from - no >>man or info > > > Comes from the xresprobe package. > >
> On Wed, Apr 13, 2005 at 01:21:58AM +0100, Matthew Garrett wrote: >>> On Wed, 2005-04-13 at 10:08 +1000, Daniel Stone wrote: >> >>>>> > > libv: which makes it a BIOS dependant function, which only makes it >>>>> > > possible on the primary graphics card >>> >>>> > >>>> > Yeah, which sucks. >> >>> >>> This bit can actually be solved without too much pain (a-ha ha ha) - >>> it's a "simple" matter of reading the ROM off the secondary cards, >>> setting up the PCI legacy video IO routing and then executing the code >>> in it. Jon Smirl's been working on this sort of thing. > > > Right, but screwing around with PCI routing is so very nasty. Last I > checked, you had to disable the IO routing for the primary card, then > walk the series of bridges, setting a specific VGA routing flag, then > enabling IO routing for that specific card. If it gets done in the > kernel such that we can rather transparently cat the BIOS out of /sys, > more power to Jon. I've certainly got no desire to do that in > userspace.
> >>ajax: probably the easy solution is to bump the default resolution to >>800x600, > > > No thanks. > > >>use DDC by default > > > Um, we already do. > > >>and cache the results of the DDC probe from the last server startup >>ajax: that last bit being important, so the monitor still works even if >>you start X with it powered down. > > > Yeah, I've been meaning to get to that for a while. Bug#5917. https://bugzilla.ubuntu.com/show_bug.cgi?id=5917 > > >>JakubS_: so there should be no problem with only primary card - from >>what i have seen there is bios image for video card in /sys >>JakubS_: it would probably have to be run on emulator, like x server does > > > On i386, it runs natively. On powerpc, it's exposed via /proc. On > amd64, ia64, hppa and sparc, it doesn't run at all. But eventually, it > will be run on an emulator (x86emu) like X does - Bug#1421. https://bugzilla.ubuntu.com/show_bug.cgi?id=1421 > > >>If someone can give me the subject(s) of the ubuntu threads (pretty sure >>it was here) I'll forward it to xorg at lists.freedesktop.org > > > Which Ubuntu threads? > Apparently only this one ;) Carl K
From clemens.koller at anagramm.de Wed Apr 13 05:23:48 2005 From: clemens.koller at anagramm.de (Clemens Koller) Date: Wed, 13 Apr 2005 14:23:48 +0200 Subject: gcc-3.4-20050401 BUG? generates illegal instruction inX11R6.4.2/mkfontscale/freetypemacro (worksforme) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Hello, Roland! I built freetype-2.1.9 separate from X. This is/was fixed in the current freetype2 CVS since 2004-11-16 by Werner Lember g. He added the -fno-strict-aliasing there. So an upcoming 2.1.10 might have these issues fixed. I am about to test the latest CVS of freetype2. Currently, I link them dynamically. Are there any issues (other than performance)? Clemens Koller ______R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Roland Mainz wrote: > Clemens Koller wrote: > >>In the freetype-devel list, I got some suggestions: >>This bug/problem seems to concentrate on ppc32/64 and s390 architectures. >>Basically all Type1 fonts shipped with X11 are suspect to this >>problem. I made tests agains UTBI____.pfa >> >>The possible (temporary)fix: >>If I re-compile freetype with -fno-strict-aliasing I can get >>mkfontscale to work! >>It's still not clear whether this is a problem in freetype >>(2.1.7 to 2.1.9 at least), the macros there, or in gcc. > > > 1. Could you please file a bug at https://bugs.freedesktop.org/ and post > the bugid back here ? > 2. Can you test the attached patch > (xorg_gcc_strict_aliasing_crasher_fix001.gudiff.txt) and check whether > this fixes the problem (please make sure to use the libfreetype library > build in the xc/ tree or link FreeType2 statically) ? > > ---- > > Bye, > Roland > > > > ------> > Index: xc/config/cf/xorg.cf > ======> RCS file: /cvs/xorg/xc/config/cf/xorg.cf,v > retrieving revision 1.45 > diff -u -2 -0 -r1.45 xorg.cf > --- xc/config/cf/xorg.cf 1 Feb 2005 02:02:31 -0000 1.45 > +++ xc/config/cf/xorg.cf 12 Apr 2005 02:03:39 -0000 > @@ -1524,41 +1524,46 @@ > # else > # define DefaultCCOptions -ansi -pedantic GccWarningOptions > # endif > # endif > # if defined(UseInstalled) > # ifndef UseGccMakeDepend > # define UseGccMakeDepend YES > # endif > # endif > #endif > > /* Make imake noisier. Note that this is ineffective for 3.0 <= GCC <= 3.2 * / > #ifndef ImakeWarningFlags > # ifdef Gcc28Warnings > # define ImakeWarningFlags Gcc28Warnings > # else > # define ImakeWarningFlags /* */ > # endif > #endif > > -#if ((GccMajorVersion == 3) && (GccMinorVersion >= 1)) || (GccMajorVersion > 3) > +/* PPC and S390(x) always need -fno-strict-aliasing to avoid crash in in > + * Freetype code and some other locations */ > +#if (((GccMajorVersion == 3) && (GccMinorVersion >= 1)) || (GccMajorVersion > 3)) \ > + || defined (PpcArchitecture) \ > + || defined (s390Architecture) \ > + || defined (s390xArchitecture) > # define GccAliasingArgs -fno-strict-aliasing > #else > # define GccAliasingArgs /* */ > #endif > > #if HasGcc2 && defined(i386Architecture) > # ifndef DefaultGcc2i386Opt > # define DefaultGcc2i386Opt -O2 -fno-strength-reduce GccAliasingArgs > # endif > #endif > > #if HasGcc2 && defined(AMD64Architecture) > # ifndef DefaultGcc2AMD64Opt > # define DefaultGcc2AMD64Opt -O2 -fno-strength-reduce GccAliasingArgs > # endif > #endif > > #if HasGcc2 && defined(AlphaArchitecture) > # ifndef DefaultGcc2AxpOpt > # define DefaultGcc2AxpOpt -O2 GccAliasingArgs
From vR at movingparts.net Wed Apr 13 06:28:28 2005 From: vR at movingparts.net (Jason 'vanRijn' Kasper) Date: Wed, 13 Apr 2005 09:28:28 -0400 Subject: New wireless intellimouse explorer 2 In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Wednesday 13 April 2005 02:30, Gene Heskett wrote: > Greetings; > > In my quest for a better mouse in terms of my carpel tunnel syndrome, > I bought one of these tonight, and other than having to accellerate > it by 2x, it was an unplug one kensington wireless and plug in the M$ > mouse operation. > > Does anyone have a mouse entry worked out that makes all the extra > buttons and the tilting scroll wheel on the above mouse do something > usefull? I can't speak to that mouse in particular, but I have the logitech multimedia mouse which has 15 buttons or so. I've blogged about it here: http://movingparts.net/b/?p=78 and that has the details for what kernel module I had to use, what I had to put in my xorg.conf, etc.
-- ,------// | Jason 'vanRijn' Kasper :: Numbers 6:22-26 ` | All brontosauruses are thin at one end, much MUCH thicker | in the middle, and then thin again at the far end. That is | the theory that I have and which is mine, and what it is too. , | bash$ :(){ :|:&};: `------//
From mhopf at suse.de Wed Apr 13 07:38:55 2005 From: mhopf at suse.de (Matthias Hopf) Date: Wed, 13 Apr 2005 16:38:55 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Apr 12, 05 14:59:07 -0400, Owen Taylor wrote: > On Tue, 2005-04-12 at 17:49 +0200, Matthias Hopf wrote: > > So how can we make - in the long term - make direct rendering with Xgl > > possible? So far I think we basically need > > > > - EXT_framebuffer_object for rendering X requests into a texture in > > the server > > - some extension yet to be specified, which allows sharing of textures > > between processes (Xgl and application) > > I think it is important to note that this isn't exactly arbitrary > peer-to-peer sharing of textures; the setup of the shared "textures" > (really render targets) is always part of the server, and the server Yes, I didn't specify concrete details by intention. > is special in the GLX protocol. In the simplest model, the differences > from how the DRI works is: I've never done much work with DRI, so I'm not influenced that much from that direction (I used to work a lot with SGIs). > In the DRI/Egl/Xgl world, it clearly is a fairly different problem, > but still doesn't seem essentially different from the problem of > non-redirected direct rendering. The server has to tell the clients > where to render in memory, and there must be locking so that the > client doesn't render to memory that is being used for something > else. I guess I have to dig a bit into GLX code and read the specs more thorowly. Right now there is no notion of a memory pointer to be rendered to in OpenGL. So we might need an extension to get these low-level rendering parameters from the OpenGL layer in order to implement the GLX rendering context negotiation / redirection completely in user space (which we have to, because we no longer have access to low level routines like regular Xservers have). > One obvious hard problem is framebuffer memory exhaustion ... nothing > prevents an application from just creating more and more GL windows, > and that would require more and more video memory given independent > backbuffers. You might need a framebuffer ejection mechanism much like > the current texture ejection mechanism, except that it's more > complex ... restoring the framebuffer requires cooperation between the > ejector and the ejectee. Agreed. AFAIR 3Dlabs had MMIO on their chips which could easily deal with this problem, but neither NVidia nor ATI have something like this or even plan to implement it AFAIK. > > - ARB_render_texture to create a context on the application side that > > renders into a texture > > To the client it must look precisely as if they are rendering to a > window. No client-exposed extension can be involved. That should be the plan. I wanted to read the GLX specs more thorowly for the bytestream protocol to initiate direct rendering, however, I couldn't find anything related to that. Do you know whether this part is vendor specific? Guess I have to read the Mesa sources. > > One alternative would be another extension that would allow the > > transport of one context to another process, so the context for > > rendering into a texture could be created on the Xgl side, and the > > context could then be transferred to the application side. This sounds > > scary as well. I doubt that an extension for shared contextes would work > > without patching the application side libGL, either. > > Hmm, sounds like the hard way to do things. I'd think a GLcontext is a > much more complex object than "there is a framebuffer at this > address in video memory with this fbconfig" Yes it is. That's what makes me quite a bit uncomfortable. CU Matthias -- Matthias Hopf
>>>- some extension yet to be specified, which allows sharing of textures >>> between processes (Xgl and application) >> >>I think it is important to note that this isn't exactly arbitrary >>peer-to-peer sharing of textures; the setup of the shared "textures" >>(really render targets) is always part of the server, and the server > > > Yes, I didn't specify concrete details by intention. > > >>is special in the GLX protocol. In the simplest model, the differences >>from how the DRI works is: > > > I've never done much work with DRI, so I'm not influenced that much from > that direction (I used to work a lot with SGIs). > > >>In the DRI/Egl/Xgl world, it clearly is a fairly different problem, >>but still doesn't seem essentially different from the problem of >>non-redirected direct rendering. The server has to tell the clients >>where to render in memory, and there must be locking so that the >>client doesn't render to memory that is being used for something >>else. > > > I guess I have to dig a bit into GLX code and read the specs more > thorowly. Right now there is no notion of a memory pointer to be > rendered to in OpenGL. So we might need an extension to get these > low-level rendering parameters from the OpenGL layer in order to > implement the GLX rendering context negotiation / redirection completely > in user space (which we have to, because we no longer have access to low > level routines like regular Xservers have). > > >>One obvious hard problem is framebuffer memory exhaustion ... nothing >>prevents an application from just creating more and more GL windows, >>and that would require more and more video memory given independent >>backbuffers. You might need a framebuffer ejection mechanism much like >>the current texture ejection mechanism, except that it's more >>complex ... restoring the framebuffer requires cooperation between the >>ejector and the ejectee. > > > Agreed. > AFAIR 3Dlabs had MMIO on their chips which could easily deal with this > problem, but neither NVidia nor ATI have something like this or even > plan to implement it AFAIK. > > >>>- ARB_render_texture to create a context on the application side that >>> renders into a texture >> >>To the client it must look precisely as if they are rendering to a >>window. No client-exposed extension can be involved. > > > That should be the plan. > I wanted to read the GLX specs more thorowly for the bytestream protocol > to initiate direct rendering, however, I couldn't find anything related > to that. Do you know whether this part is vendor specific? > Guess I have to read the Mesa sources. > > >>>One alternative would be another extension that would allow the >>>transport of one context to another process, so the context for >>>rendering into a texture could be created on the Xgl side, and the >>>context could then be transferred to the application side. This sounds >>>scary as well. I doubt that an extension for shared contextes would work >>>without patching the application side libGL, either. >> >>Hmm, sounds like the hard way to do things. I'd think a GLcontext is a >>much more complex object than "there is a framebuffer at this >>address in video memory with this fbconfig" > > > Yes it is. That's what makes me quite a bit uncomfortable. I often see people referring to a "GL context" without really knowing what it is. An OpenGL rendering context is not a drawing surface; it's a state record which keeps track of things like current blend mode, current drawing color, current texture parameters, etc. A rendering context can't be changed or used until it's bound to a drawing surface. A single rendering context can be used with any number of (compatible) drawing surfaces. And a drawing surface can be drawn to by any number of (compatible) rendering contexts. -Brian
From jonsmirl at gmail.com Wed Apr 13 08:29:33 2005 From: jonsmirl at gmail.com (Jon Smirl) Date: Wed, 13 Apr 2005 11:29:33 -0400 Subject: [Mesa3d-dev] Re: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On 4/13/05, Brian Paul
From ijs at txcorp.com Wed Apr 13 09:02:12 2005 From: ijs at txcorp.com (Irek Szczesniak) Date: Wed, 13 Apr 2005 10:02:12 -0600 (MDT) Subject: Xvfb and the composite extention Message-ID:
Best, Irek From ajax at nwnk.net Wed Apr 13 09:35:41 2005 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 13 Apr 2005 12:35:41 -0400 Subject: Xvfb and the composite extention In-Reply-To:
From mhopf at suse.de Wed Apr 13 11:37:20 2005 From: mhopf at suse.de (Matthias Hopf) Date: Wed, 13 Apr 2005 20:37:20 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> This is getting a longer post, again... On Apr 12, 05 21:12:48 +0200, David Reveman wrote: > On Tue, 2005-04-12 at 17:49 +0200, Matthias Hopf wrote: > > - You are only able to render redirected OpenGL apps accelerated, when > > the driver has PBuffer support, because you need a rendering context > > for the application (if you do not want to re-invent the wheel > > everywhere and do state tracking yourself). > > Do you need PBuffers for non-redirected windows as well? > The back buffer is currently allocated in the same way as pixmaps and > Xgl is currently using the *real* back buffer for pixmaps so you might > be able to run non-redirected windows accelerated without pbuffers. This Again, with scissor test, I imagine? > stupid use of the *real* back buffer for pixmaps is only there so that > we can test and get these things (XRender, Composite...) running before > we have framebuffer object support. Once we can start to use framebuffer > objects I'll change so that the *real* back buffer is used as back > buffer for non-redirected windows. Then we can actually intercept glXSwapBuffers() and account for overlapping windows etc. pp. I guess this will make things much easier. > > - As soon as framebuffer objects exist and should be used for off-screen > > rendering contexts, we would need something like ARB_render_target, > > otherwise we couldn't provide the applications with a context to > > render into. Or we have to intercept all BindRenderbufferEXT() etc. > > calls from the application. > We'll have to intercept BindRenderbuffer, BindFramebuffer... but I think > we can get that working without to much trouble. I don't see how I'll guess so. > ARB_render_target could be of help here... is that extension still > considered? Don't think so. I think I missunderstood something WRT this extension - you explained that to another guy already, I guess I see a bit clearer now. > > So how can we make - in the long term - make direct rendering with Xgl > > possible? So far I think we basically need > > - EXT_framebuffer_object for rendering X requests into a texture in > > the server > > - some extension yet to be specified, which allows sharing of textures > > between processes (Xgl and application) > Yes. Let's look at an application that is just about to create a new context / bind the context to a drawable: (glXCreateNewContext/glXCreateContext/glXMakeContextCurrent/glXMakeCurrent) For indirect rendering we can just create a context, BindRenderbuffer() the current Pixmap texture to it, and after that(!) return the context id to the application. Calls to BindRenderbuffer() etc. have to be intercepted, so that binding to 0 actually binds to the Pixmap texture again. For direct rendering things are getting more complicated. The libgl has to be changed so that it supports a mechanism to let the application create a direct rendering context, that renders not into the framebuffer but into the Pixmap texture. For a regular XWindow. This cannot be done without code change in the library. It doesn't matter, because we have to have additional functionality (extension) anyway: we need to have a way of sharing a texture with another process id. As all of this cannot be done in a backwards-compatible manner, applications linked to old / unextended versions of the library can only be supported using indirect rendering. Not really a problem (who links statically against libgl anyway). So I currently see the need for two extensions: - Share a texture with another process, that is with another address space (GL_shared_texture). For security reasons and ease of implementation this would have to be twofold: the Xserver would have to export the texture, creating an unambiguous ID, transfer this ID to the client, then the client would have to import the texture using this ID. We would have to think about whether we need locking mechanisms here as well, at least for format/size changes. - Identify displays that may correspond with shared textures and change the way contexts are created and bound (GLX_shared_texture_context). The client would have to identify displays with windows associated to off-screen buffers. If (and only if) a direct rendering context is to be created to one of these windows, it should contact the Xserver and ask him for an texture export ID, then bind this texture for its rendering context. So this extension is tightly coupled with GL_shared_texture. On the client side this could actually be coupled with framebuffer objects.
I would write proposals as soon as we agree on what we actually need, but I think we are a bit too early in the discussion process for that. Right now I have no good solution what should happen with OpenGL applications when a composite manager redirects / unredirects windows. I guess the easiest way would be to always render into offscreen buffers, whether a window is redirected or not. For indirect rendering this shouldn't be problematic, as the Xserver is in control of where to render to. > > - ARB_render_texture to create a context on the application side that > > renders into a texture > So far I've only thought of using GLX_ARB_render_texture for indirect > rendering. Don't know if it's a good idea to use it for direct rendering > as well but maybe that's possible. Either way, that's all transparent to > the client so it wouldn't be to too bad if it turns out we need > something else, right? Very right. The only possibility for using this extension for creating the context would be to patch the system libGL as well. I don't like this idea, we would have to have special cases for NVidia/ATI here as well. > > That is, textures are currently only working correctly, if all > > applications use GenTextures(), right? > Exactly. So most of mine won't :-] Was lazy until now... > > > Getting front buffer drawing to work is a bit harder. We need to report > > > damage and do pixel ownership test. Using the current scissor box when > > > reporting damage is probably good enough but I don't have good solution > > > for pixel ownership test. I guess we're going to have to do multiple > > > drawing operations with different scissor boxes but that will make > > > display lists much harder to handle... > > What happens if the application wants to use the scissor test on its own? > > For indirect rendering we could always interprete the protocol ourself > > (Ugh) and adapt the test to our needs, but for direct rendering I have > > no clue. > I'm intersecting the client scissor box with window bounds right now. So you already implemented the (Ugh) case - very impressive :) > Means trouble when display lists are used but I think that can be solved > for indirect rendering by splitting up display lists on the server-side. Oh, right, now I understand why display lists could be a problem. Luckily, typically no scissor test changes are incorporated into display lists. I'm not saying that we shouldn't care ;) > Don't know about direct rendering. When we're drawing to framebuffer > objects we don't have to do this. Right. For double buffered applications this should be easy to implement (copy to screen on glXSwapBuffers()), for single buffered applications we could emulate single buffer with a copy to screen on glXFlush()... CU Matthias -- Matthias Hopf
From jonasmg at softhome.net Wed Apr 13 13:37:28 2005 From: jonasmg at softhome.net (Jonas Melian) Date: Wed, 13 Apr 2005 21:37:28 +0100 Subject: Improvements in X -configure Message-ID: <[email protected]> I've working in a tool (based on mkxf86config.sh from knoppix) to auto-configure xorg config file. And after verifying that 'X -configure' has improved, I want to recommend some improvements. 1- Fonts To add all the directories with fonts that find in /usr/share/fonts/. And to place them of such form that is thus: "/usr/share/fonts/misc/" "/usr/share/fonts/TTF/" other dirs ttf "/usr/share/fonts/Type1/" other dirs type1 "/usr/share/fonts/CID/" other dirs cid "/usr/share/fonts/75dpi/" "/usr/share/fonts/100dpi/" other dirs bitmap Pseudocode: FOR dir in /usr/share/fonts/* (except /util,/encodings); DO IF find *.ttf; THEN dir (underneath .../TTF/) ELIF *.pfa || *.pfb; THEN dir (underneath .../Type1/) ELIF *.cid; THEN dir (underneath .../CID/) ELIF *.pcf.gz; THEN dir (underneath .../100dpi/) FI DONE Also it is possible to be verified that those principal directories (/usr/share/fonts/{misc,TTF,Type1,CID,75dpi,100dpi}) exist and who they have fonts. In my case i haven't .../CID/. If doesn't exist (or directory without fonts) then comment out it. It is necessary to consider that if the resolution is 1024x768 or greater then then there is to put .../100dpi/ before that .../75dpi/ 2- Device (graphic card) The method that uses to detect the module is to prove each one. But it has a failure. What happens if a card allows two different modules and set one of smaller yield? In my case, i have an ati radeon 8500. The correct module would be 'radeon' but it set 'ati'. Would it not be better and faster to use a data base? Like that it uses 'discover' (a tool from debian) graphics card - module ati radeon radeon ... Also in that data base it would be possible to be added specific options for that module, so that they were activated. Like allowing 'swcursor' for the modules ati,radeon,nv,trident. Or comment out 'DefaultColorDepth' for fbdev. 3- Monitor It must use NoPM, because some machines freeze if Power management is being activated: if CheckLineBoot "noapm"; then Option "NoPM" else Option "DPMS" fi And to DPMS, add (i.e.): Option "blank time" "10" Option "standby time" "20" Option "suspend time" "40" Option "off time" "60"
Also, it would be detect all the modelines for the monitor when is being created the config file, as is made by 'ddcxinfo-knoppix -modelines'. If the monitor isn't ddc, then build a standard modesline. 4- Screen To choose the 3 better modes (according to the number of Hertz, 85 or more very well, 75 is ok, 60 ?) for each depth (24, 16, 8, 4). And to choose a good depth as default: 24, if it has as minimun 1024x768 (or 800x600) else 16, ...
From Alan.Coopersmith at Sun.COM Wed Apr 13 14:10:26 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Wed, 13 Apr 2005 14:10:26 -0700 Subject: Improvements in X -configure In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Jonas Melian wrote: > 4- Screen > To choose the 3 better modes (according to the number of Hertz, 85 or > more very well, 75 is ok, 60 ?) for each depth (24, 16, 8, 4). The problem with the "higher hz is better" method of picking a mode is it often picks worse modes on LCD's, since you get screen sizes that don't fit the native resolution well. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From airlied at gmail.com Wed Apr 13 14:35:10 2005 From: airlied at gmail.com (Dave Airlie) Date: Thu, 14 Apr 2005 07:35:10 +1000 Subject: Improvements in X -configure In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> > > 2- Device (graphic card) > The method that uses to detect the module is to prove each one. But it > has a failure. What happens if a card allows two different modules and > set one of smaller yield? > > In my case, i have an ati radeon 8500. The correct module would be > 'radeon' but it set 'ati'. either ati or radeon is correct.. ati is just a loader for radeon or ati2 Dave.
From davidr at novell.com Wed Apr 13 14:49:22 2005 From: davidr at novell.com (David Reveman) Date: Wed, 13 Apr 2005 23:49:22 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Mon, 2005-04-11 at 18:33 +0200, David Reveman wrote: > I've got GLX and indirect rendering working with Xgl. It's accelerated > and works fine with Composite. There's of course a lot more work to be > done but I don't plan on going much further until we're using > framebuffer objects in Xgl as it would mean adding code that will be > thrown away later. > > The glitz and Xgl code needed to get this working is in pretty good > shape and it should land in CVS in a few days. The necessary bits are now in CVS. To build this you'll need me my previously mentioned patches to server-side GLX and probably something like the attached patch for xserver's configure.ac. You might also need to tweak mesa CVS a bit to make it build. E.g. disable shader objects. It doesn't work with mesa DRI yet, and some problems with GetProcAddress when using software mesa. It actually only works OK with nvidia drivers right now, as far as I know. Only some simple OpenGL applications will work right now and don't get surprised if some application break the server completely as client context currently share textures with core Xgl context and some OpenGL calls that need special treatment are not yet handled... > > But I had to do some pretty drastic changes to server side GLX code and > I'm not sure that my current solutions are the best way to go. Here's > what I've done: > > 1. Made glcore use MGL namespace. This allows me to always have software > mesa available and this is currently necessary as there might not be > enough resources to use the *real* GL stack with Composite. It might not > be necessary when we're using framebuffer objects but I still think it's > a good idea. This works fine when running Xgl on top of nvidia's GL > stack or software mesa, but I haven't been able to get it running on top > of mesa/DRI yet. > > 2. Made all GL calls in server side GLX go through another dispatch > table. Allows me to switch between software mesa and *real* GL stack as > I like. This is also necessary as extension function pointers might be > different between contexts and we need to wrap some GL calls. e.g. > glViewport needs an offset. > > Both these changes are available as patches from here: > http://www.cs.umu.se/~c99drn/xgl-glx/ > > xserver-mesa.diff also include some changes required to get xserver > compiling with mesa CVS and a few lines to support ARGB visuals. > xserver-glx.diff modifies files that seem to be auto generated but I > didn't find the source to that so I just made the changes directly. Most > of these changes were done by running a regexp on all files in > xserver/GL/glx directory. > > Does this seem like reasonable changes? > > > I had to add a 8A8R8G8B pixel format to XMesa for ARGB visuals to work > properly. This patch should do that: > http://www.cs.umu.se/~c99drn/xgl-glx/Mesa-PF_8A8R8G8B.diff > > > With all the above changes in place I can run simple OpenGL applications > accelerated while using a compositing manager, and by changing a few > lines in the applications I can get them to use ARGB visuals as well. > > > The following is not working: > - Context Sharing (all contexts are currently shared) > - Drawing to front buffer > - CopyPixels > > All contexts need to be shared inside Xgl so we're going to have to keep > hash tables in Xgl to deal with GLX contexts. > > Getting front buffer drawing to work is a bit harder. We need to report > damage and do pixel ownership test. Using the current scissor box when > reporting damage is probably good enough but I don't have good solution > for pixel ownership test. I guess we're going to have to do multiple > drawing operations with different scissor boxes but that will make > display lists much harder to handle... > > CopyPixels between different buffers is not working right now, but when > we're using framebuffer objects this will work just fine. > > > My current plans for GLX support in Xgl and for Xgl in general are as > follows: > > - Textures are used for pixmaps and framebuffer objects for drawing to > them. No GL_EXT_framebuffer_object support, no accelerated offscreen > drawing. > > - Windows that are not redirected to pixmaps will when attached to a GLX > context use the back buffer, stencil bits and depth bits provided by the > real framebuffer. For windows that are redirected we'll allocate > back/depth/stencil buffers dynamically as needed. > > - The compositing manager will most likely be using indirect GLX for > drawing the desktop. A double buffered GL visual can be used to > efficiently draw the desktop even when GL_EXT_framebuffer_object isn't > present and buffer flips can be used when redrawing the whole screen. > > - All visuals will be GL visuals and by reviving GL_ARB_render_texture > and implementing it in Xgl we'll make it possible for GL applications to > bind a X drawable to a texture id. This is what a GL compositing manager > will do for all top level windows. > > This is just what I believe is the best way to go, it's not in any way > set in stone, it's all open for discussion. Comments and suggestions are > of course much appreciated. > > -David > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -David ------next part ------A non-text attachment was scrubbed... Name: xserver-configure-glx.diff Type: text/x-patch Size: 563 bytes Desc: not available URL:
>>Since we are seeing several people reporting bugs now, that fonts >>that previously worked fine, no longer work, this was kindof >>surprising because X.Org still supplies these fonts *and* installs >>them by default. >> >>I have no strong feelings either way as to wether this gets fixed >>by re-enabling speedo font support, or by preventing the speedo fonts >>from getting installed and/or removing them from CVS, as there have >>only been a few people file bug reports. > > Fixing the "make install" to not installing the Speedo fonts when the > Speedo font rasterizer is not build is fine (erm... we may run into > trouble with Xvnc unless that Xserver has Egbert's code to drop font > path elements with invalid/unsupported content) - but those fonts should > not be removed until the same is done with the xc/lib/font/speedo/ > rasterizer. Agreed, this sounds like the best solution for the Xorg tree. > I'd like to avoid killing the code for now until it is clear > whether the FreeType2 library gets Speedo support or not - once they > made a final decision the fate of the Speedo rasterizer+fonts should be > debated here. That's reasonable I guess.
> Another issue is whether the Speedo fonts shipped in the X.org tree > should be replaced with PS Type1 versions of the same fonts - does > anyone know whether this will trigger any licensing issues ? I've attached the COPYRIGHT file from the Speedo dir in XFree86 4.3.0, which I happened to have laying around. IANAL, but my interpretation of the license seems that it would permit modification and redistribution. Changing font types would fit under "modification" I believe. Anyone up to the task of converting to Type1 or TTF? Type1 is probably superior for this particular case. ------next part ------An embedded and charset-unspecified text was scrubbed... Name: COPYRIGHT URL:
From jonasmg at softhome.net Wed Apr 13 15:26:32 2005 From: jonasmg at softhome.net (Jonas Melian) Date: Wed, 13 Apr 2005 23:26:32 +0100 Subject: Improvements in X -configure In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> Dave Airlie wrote: >>2- Device (graphic card) >>The method that uses to detect the module is to prove each one. But it >>has a failure. What happens if a card allows two different modules and >>set one of smaller yield? >> >>In my case, i have an ati radeon 8500. The correct module would be >>'radeon' but it set 'ati'. > > > either ati or radeon is correct.. ati is just a loader for radeon or ati2 > > Dave. > Ok, the detection is correct. But I continue thinking that a data base is far better, although it only been by speed. In addition as they are added more graphical card modules more time will take in being proving each one until finding it.
From daniel at fooishbar.org Wed Apr 13 15:29:50 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 14 Apr 2005 08:29:50 +1000 Subject: Improvements in X -configure In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Wed, Apr 13, 2005 at 11:26:32PM +0100, Jonas Melian wrote: > Ok, the detection is correct. > > But I continue thinking that a data base is far better, although it only > been by speed. In addition as they are added more graphical card modules > more time will take in being proving each one until finding it. The annoying problem is that you do have to maintain two sets of data then, and it's really, really easy for them to get out of sync. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
From benh at kernel.crashing.org Wed Apr 13 22:12:47 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 14 Apr 2005 15:12:47 +1000 Subject: radeon driver, mode selection, RADEONPreInitModes() Message-ID: <1113455567.5463.82.camel@gaston> Hi ! I'm chasing a problem where the radeon driver basically doesn't get the proper mode from DDC on the second head (both primary and secondary heads are DFP flat panels). I'm having a hard time trying to understand what RADEONPreInitModes() is supposed to do I must admit :) Whatever it does is not right in practice though. What I've figured out so far is: - We never call RADEONUpdatePanelSize() on the second head for some reason I cannot explain. That causes us to never have panel infos for the second head - Later on, that absence of panel infos cause us to call xf86ValidateModes() which seems to replace all our valid DDC modes with crap that doesn't work (especially on this 1920x1200 panel). - The problematic code looks like that: /* Next try to add DDC modes */ modesFound = RADEONValidateDDCModes(pScrn, pScrn->display->modes, info->DisplayType, 0); The above works... It does return a valid mode. modesFound is 1. /* If that fails and we're connect to a flat panel, then try to * add the flat panel modes */ if (info->DisplayType != MT_CRT) { Ok, we do get here... but the above didn't fail ! The comment is misleading... Should we add a "&& modesFound < 1" or something like that in the above if () statement ? /* some panels have DDC, but don't have internal scaler. * in this case, we need to validate additional modes * by using on-chip RMX. */ int user_modes_asked = 0, user_modes_found = 0, i; DisplayModePtr tmp_mode = pScrn->modes; while (pScrn->display->modes[user_modes_asked]) user_modes_asked++; Ok, so here, we could the modes asked in the Subsection "Display" of Section "Sc reen" and we get 5 of them (that's what I have in my xorg.conf). if (tmp_mode) { for (i = 0; i < modesFound; i++) { if (tmp_mode->type & M_T_USERDEF) user_modes_found++; tmp_mode = tmp_mode->next; } } For some strange reason, we do have M_T_USERDEF on our DDC mode (despite not having any mode actually be user defined), so we get 1 in user_modes_found. Ahhh .. I see .. we do actually add ourselves M_T_USERDEF to any mode in the DDC list that is also in the Display/Screen ... in fact, we only keep those in the list it seems (if there is a display/screen subsection, if not, we mark all DDC modes ... hrm... interesting). if ((modesFound <= 1) || (user_modes_found < user_modes_asked)) { Ok, so here the problem starts. So I do get user_modes_found < user_modes_asked, because I did put all those bogus modes in my display/screen subsection (but we would get there anyway even if I didn't, since modesFound == 1). I don't underst and why we get there when modesFound <= 1. Shouldn't this be < 1 instead ? /* when panel size is not valid, try to validate * mode using xf86ValidateModes routine * This can happen when DDC is disabled. */ if (info->PanelXRes < 320 || info->PanelYRes < 200) Ahh ... Here we are on the second head, and we didn't have any panel infos for i t, so we do get in here. So that's intersting. If we had any panel infos, we wouldn 't get there, and we wouldn't get into RADEONValidateFPModes neither since we don't allow calling it for the secondary head.... or do we do that just _because_ we h ave no panel infos ? (It relies on them). Anyway, the point is, depending if DDC returns one mode or more here, we get different behaviour. If DDC returns only one mode, like it is the case for me, (or if the user specified more modes in display/screen than DDC modes found), we get into xf86ValidateModes(), which doesn't quite work for me. It basically doesn't find any valid mode which makes sense since it doesn't get passed the list of mode we obtained from DDC at all. It gets passed pScrn->monitor->Modes which seem to contain all possible nasty mode X can think about (but not the one I want) and pScren->display->modes which is just the requested array. The clockRanges might be ok, but since my 1920x1200 of my flat panel just doesn' t exist in pScrn->monitor->modes, that function will just do no good. Also, I'm a bit worried about the pitch... Might xf96ValidateModes() try to do something about it ? Because we have called RADEONSetPitch() once in RADEONValid ate DDCMode for out biggest DDC mode already, and we may sort-of get out of sync her e, no ? modesFound = xf86ValidateModes(pScrn, pScrn->monitor->Modes, pScrn->display->modes, clockRanges, NULL, /* linePitches */ 8 * 64, /* minPitch */ 8 * 1024, /* maxPitch */ 64 * pScrn->bitsPerPixel, /* pitchInc */ 128, /* minHeight */ 2048, /* maxHeight */ pScrn->display->virtualX, pScrn->display->virtualY, info->FbMapSize, LOOKUP_BEST_REFRESH); else if (!info->IsSecondary) modesFound = RADEONValidateFPModes(pScrn, pScrn->display->mo des); } } Ok, at this point, we used to have a nice mode list that sort-of worked (of 1 mo de) from DDC, and instead of just discarding the bogus user modes, we decided to cal l xf86ValidateModes() which discarded ... the only correct mode we had. So we end up with no valid mode at all. It would have worked if 1) I didn't pass anything in display/screen, or only one mode: the valid one (remember, no RMX on second head) 2) _and_ I had DDC giving me more than one mode so we don't hit the modesFound <=1 test. I really don't understand why this is not < 1 .... It's all very fragile though. I think the problem is that the DDC modes are not in the list that we pass to xf86ValidateModes which makes it do crap, and that w e should have modesFound test be < 1, but then, I can't be 100% certain. I'll need some help here, I'm quite new to this X mode management stuff, but the re is definitelu something wrong here. Regards, Ben.
From benh at kernel.crashing.org Wed Apr 13 22:31:37 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 14 Apr 2005 15:31:37 +1000 Subject: radeon driver, mode selection, RADEONPreInitModes() In-Reply-To: <1113455567.5463.82.camel@gaston> References: <1113455567.5463.82.camel@gaston> Message-ID: <1113456698.5462.87.camel@gaston> On Thu, 2005-04-14 at 15:12 +1000, Benjamin Herrenschmidt wrote: > > 2) _and_ I had DDC giving me more than one mode so we don't hit the modesFou nd <=1 > test. I really don't understand why this is not < 1 .... Ok, I added a patch to my list of patches against stable at http://gate.crashing.org/~benh/xorg/radeon-fix-one-mode-ddc.diff, This one does change if (modesFound <= 1 || .... into if (modesFound < 1 || ..... in 2 places, PreInitModes and the MergedFB equivalent. The result with this patch is that if I don't specify anything in display/screen, or only the right mode, it works fine now. It still breaks if I put more modes there, as I think we should pass to xf86ValidateModes the list of modes from DDC/ModeLines when modesFound >= 1 and not let it use it's default list which doesn't contain most fancy flat panel ones. Oh, finally ... i'm not too sure why we do all of that stuff only for !CRT ... I suspect that whole piece of coded intend to do something that is quite different from what it does in practice, but I would need Hui advice to better understand the issue here. Ben.
From aritger at nvidia.com Wed Apr 13 23:30:31 2005 From: aritger at nvidia.com (Andy Ritger) Date: Wed, 13 Apr 2005 23:30:31 -0700 (PDT) Subject: dynamic driver configuration idea... In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID:
On Wed, 13 Apr 2005, Egbert Eich wrote: > Dave Airlie writes: > > I've been thinking about this and recently after using Thomas > > Winischhofer's sisctrl application wondered why we don't have a > > standard method for driver configuration... > > > > I'm thinking something like driconf does for DRI 3D drivers, but maybe > > a bit more network aware, (btw driconf just writes a local .drirc > > file, and it gets the config options from the actual driver binary and > > this is read by the 3D client library at startup so you can have > > differnet settings for different apps... etc..) > > > > it would probably be like a super xrandr, the driver could return an > > XML description of what if wants to offer, a GUI app could build a GUI > > from those options and could then send the results dynamically back to > > the driver to reconfigure itself.. as every driver would have > > different options I wouldn't feel the need to limit it through some > > interface hence XML or something like that... > > > > Mainly I would think of CRT configurations, desktop size, driver > > acceleration tweaks, like you see on Windows drivers .... also it > > might have the option to write the X config file but that may not be > > necessary... > > > > I can see security issues as well with what clients can access it .. > > > > btw I probably won't write this at all, just throwing the idea around > > as that sisctrl panel doth rock when messing with TV-OUT on an SIS > > laptop... > > I had a similar idea a while back. Starting from the attributes for Xv > which depend on the capabilities of the driver/chipset. There the driver > can provide some information on the properties of the attributes it accepts. > > My idea was to provide enough information so that a gui application can > provide a meaningful interface even without knowing about the specific > property. > Additionally I wanted to cerate a registry for 'well known properties' > so that their behavior can be uniform across drivers. > My idea was to create an extension which would eventually have replaced > the ill designed xf86misc extension (and the xf86vidmode extension). > Also some functionalities of Xrandr (the screen resolution reconfig > part, not the event notofication part) could have been placed there. > Also a lot of the static config options from the drivers could have > been made dynamic thru this mechanism. > > In short it would have consolidated most of the DDX specific extensions > having to do with DDX configuration. > > Since then paradigms have changed as people explained that there is no > need to craft an extension as it doesn't make sense to push this over > the wire. > This may be true to some extend - on the other hand thinking of thin > clients with absolutely no local X client running there may be exceptions. > > Anyway, I kind of have abandoned that idea. > > Egbert. FWIW, the NVIDIA X driver advertises the NV-CONTROL X extension, and I have been very happy with it. The most common NV-CONTROL client is nvidia-settings (ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-1.0.tar.gz), though the API is documented (see NV-CONTROL-API.txt in the above tarball), and we've had customers and assorted end users write their own NV-CONTROL clients. Most of the configurability we've exposed through NV-CONTROL thus far have been simple integer attributes, where clients can query whether the attribute is available on the given X screen, what the current value is of the attribute, what the valid values are for the attribute, and set new values for the attribute. Extending the API then just consists of adding new attributes. Of course, we've run into plenty of strange cases that forced us to add additional entry points and protocol to NV-CONTROL, but the majority of the functionality remains in the simple integer attribute manipulation. This might be a useful architecture to mimic for other projects, though I do believe so much of the functionality is vendor-specific that it would be hard to provide something generic, especially on the gui side. - Andy
> ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg >
From davidr at novell.com Thu Apr 14 03:01:45 2005 From: davidr at novell.com (David Reveman) Date: Thu, 14 Apr 2005 12:01:45 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Wed, 2005-04-13 at 20:37 +0200, Matthias Hopf wrote: > This is getting a longer post, again... > > On Apr 12, 05 21:12:48 +0200, David Reveman wrote: > > On Tue, 2005-04-12 at 17:49 +0200, Matthias Hopf wrote: > > > - You are only able to render redirected OpenGL apps accelerated, when > > > the driver has PBuffer support, because you need a rendering context > > > for the application (if you do not want to re-invent the wheel > > > everywhere and do state tracking yourself). > > > Do you need PBuffers for non-redirected windows as well? > > The back buffer is currently allocated in the same way as pixmaps and > > Xgl is currently using the *real* back buffer for pixmaps so you might > > be able to run non-redirected windows accelerated without pbuffers. This > > Again, with scissor test, I imagine? Yes. > > stupid use of the *real* back buffer for pixmaps is only there so that > > we can test and get these things (XRender, Composite...) running before > > we have framebuffer object support. Once we can start to use framebuffer > > objects I'll change so that the *real* back buffer is used as back > > buffer for non-redirected windows. > > Then we can actually intercept glXSwapBuffers() and account for > overlapping windows etc. pp. I guess this will make things much easier. We're always intercepting glXSwapBuffers, there's no way not to, as it's window system dependent. I'm currently just doing a CopyArea from the back buffer pixmap to the drawable, that way I get damage and composite working OK. This CopyArea is currently done from Xgl's core context, which mean that a context switch occurs at every buffer swap. This makes high frame rate clients like glxgears loose some performance. Not that I see it as a big problem that clients that could run at 4000 FPS only run at 3000 FPS... but we might want do the swap from the client context in the future, especially when the window isn't redirected and it's clip region covers all of the screen as we can then use the native SwapBuffers. > > > > - As soon as framebuffer objects exist and should be used for off-screen > > > rendering contexts, we would need something like ARB_render_target, > > > otherwise we couldn't provide the applications with a context to > > > render into. Or we have to intercept all BindRenderbufferEXT() etc. > > > calls from the application. > > We'll have to intercept BindRenderbuffer, BindFramebuffer... but I think > > we can get that working without to much trouble. I don't see how > > I'll guess so. > > > ARB_render_target could be of help here... is that extension still > > considered? > > Don't think so. I think I missunderstood something WRT this extension - > you explained that to another guy already, I guess I see a bit clearer > now. Are we mixing up extension names here? There's no ARB_render_target as far as I know. I think there is or was a EXT_render_target with similar functionality as EXT_framebuffer_object, I thought you were talking about that one. I guess you just meant GLX_ARB_render_texture. > > > > So how can we make - in the long term - make direct rendering with Xgl > > > possible? So far I think we basically need > > > - EXT_framebuffer_object for rendering X requests into a texture in > > > the server > > > - some extension yet to be specified, which allows sharing of textures > > > between processes (Xgl and application) > > Yes. > > Let's look at an application that is just about to create a new context > / bind the context to a drawable: > (glXCreateNewContext/glXCreateContext/glXMakeContextCurrent/glXMakeCurrent) > > For indirect rendering we can just create a context, BindRenderbuffer() > the current Pixmap texture to it, and after that(!) return the context > id to the application. Calls to BindRenderbuffer() etc. have to be > intercepted, so that binding to 0 actually binds to the Pixmap texture > again. Yes, checkout the current CVS code to see how this is currently done. No framebuffer object support for server-side GLX yet so we don't have to worry BindRenderbuffer right now. > > For direct rendering things are getting more complicated. The libgl has > to be changed so that it supports a mechanism to let the application > create a direct rendering context, that renders not into the framebuffer > but into the Pixmap texture. For a regular XWindow. This cannot be done > without code change in the library. > > It doesn't matter, because we have to have additional functionality > (extension) anyway: we need to have a way of sharing a texture with > another process id. > > As all of this cannot be done in a backwards-compatible manner, > applications linked to old / unextended versions of the library can only > be supported using indirect rendering. Not really a problem (who links > statically against libgl anyway). Being able to get direct rendering working in a backwards-compatible manner never crossed my mind. > > So I currently see the need for two extensions: > > - Share a texture with another process, that is with another address > space (GL_shared_texture). > > For security reasons and ease of implementation this would have to be > twofold: the Xserver would have to export the texture, creating an > unambiguous ID, transfer this ID to the client, then the client would > have to import the texture using this ID. We would have to think about > whether we need locking mechanisms here as well, at least for > format/size changes. > > - Identify displays that may correspond with shared textures and change > the way contexts are created and bound (GLX_shared_texture_context). > > The client would have to identify displays with windows associated to > off-screen buffers. If (and only if) a direct rendering context is to > be created to one of these windows, it should contact the Xserver and > ask him for an texture export ID, then bind this texture for its > rendering context. So this extension is tightly coupled with > GL_shared_texture. > On the client side this could actually be coupled with framebuffer > objects. > > I would write proposals as soon as we agree on what we actually need, > but I think we are a bit too early in the discussion process for that. Yes, and I think we're also too early in the development faze. We should probably get indirect rendering fully working and Xegl at least close to working before we start writing proposals for this. > > Right now I have no good solution what should happen with OpenGL > applications when a composite manager redirects / unredirects windows. I > guess the easiest way would be to always render into offscreen buffers, > whether a window is redirected or not. For indirect rendering this > shouldn't be problematic, as the Xserver is in control of where to > render to. > > > > - ARB_render_texture to create a context on the application side that > > > renders into a texture > > So far I've only thought of using GLX_ARB_render_texture for indirect > > rendering. Don't know if it's a good idea to use it for direct rendering > > as well but maybe that's possible. Either way, that's all transparent to > > the client so it wouldn't be to too bad if it turns out we need > > something else, right? > > Very right. The only possibility for using this extension for creating > the context would be to patch the system libGL as well. I don't like > this idea, we would have to have special cases for NVidia/ATI here as > well. > > > > > That is, textures are currently only working correctly, if all > > > applications use GenTextures(), right? > > Exactly. > > So most of mine won't :-] Was lazy until now... > > > > > Getting front buffer drawing to work is a bit harder. We need to report > > > > damage and do pixel ownership test. Using the current scissor box when > > > > reporting damage is probably good enough but I don't have good solution > > > > for pixel ownership test. I guess we're going to have to do multiple > > > > drawing operations with different scissor boxes but that will make > > > > display lists much harder to handle... > > > What happens if the application wants to use the scissor test on its own? > > > For indirect rendering we could always interprete the protocol ourself > > > (Ugh) and adapt the test to our needs, but for direct rendering I have > > > no clue. > > I'm intersecting the client scissor box with window bounds right now. > > So you already implemented the (Ugh) case - very impressive :) > > > Means trouble when display lists are used but I think that can be solved > > for indirect rendering by splitting up display lists on the server-side. > > Oh, right, now I understand why display lists could be a problem. > Luckily, typically no scissor test changes are incorporated into display > lists. I'm not saying that we shouldn't care ;) And serious OpenGL applications will probably be using VBOs and not be display list so some minor performance issues with display lists isn't that bad. > > > Don't know about direct rendering. When we're drawing to framebuffer > > objects we don't have to do this. > > Right. For double buffered applications this should be easy to implement > (copy to screen on glXSwapBuffers()), for single buffered applications > we could emulate single buffer with a copy to screen on glXFlush()... Yes, we're probably going have to do something like that for direct rendering. -David
From mhopf at suse.de Thu Apr 14 03:09:04 2005 From: mhopf at suse.de (Matthias Hopf) Date: Thu, 14 Apr 2005 12:09:04 +0200 Subject: GLX and Xgl In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > Are we mixing up extension names here? There's no ARB_render_target as > far as I know. I think there is or was a EXT_render_target with similar > functionality as EXT_framebuffer_object, I thought you were talking > about that one. I guess you just meant GLX_ARB_render_texture. Oops. Yes. Matthias
From alexdeucher at gmail.com Thu Apr 14 05:52:08 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 14 Apr 2005 08:52:08 -0400 Subject: radeon driver, mode selection, RADEONPreInitModes() In-Reply-To: <1113456698.5462.87.camel@gaston> References: <1113455567.5463.82.camel@gaston> <1113456698.5462.87.camel@gaston> Message-ID:
From jonasmg at softhome.net Thu Apr 14 06:06:57 2005 From: jonasmg at softhome.net (Jonas Melian) Date: Thu, 14 Apr 2005 14:06:57 +0100 Subject: Improvements in X -configure In-Reply-To: <[email protected]> References: <[email protected]> <21d7e9970504131435582706d8@mail .gmail.com> <[email protected]> <[email protected] ooishbar.org> <[email protected]> Message-ID: <[email protected]> Carl Karsten wrote: > Daniel Stone wrote: > >> On Wed, Apr 13, 2005 at 11:26:32PM +0100, Jonas Melian wrote: >> >>> Ok, the detection is correct. >>> >>> But I continue thinking that a data base is far better, although it only >>> been by speed. In addition as they are added more graphical card modules >>> more time will take in being proving each one until finding it. >> >> >> >> The annoying problem is that you do have to maintain two sets of data >> then, and it's really, really easy for them to get out of sync. > > > Could the "records" be stored as part of the driver source, and when the > driver is built, it adds its record to the database? (check to see if > it isn't in there already.) > > Carl K > Could it be used Hal to this?
From benh at kernel.crashing.org Thu Apr 14 06:13:25 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 14 Apr 2005 23:13:25 +1000 Subject: radeon driver, mode selection, RADEONPreInitModes() In-Reply-To:
> > Oh, finally ... i'm not too sure why we do all of that stuff only > > for !CRT ... I suspect that whole piece of coded intend to do something > > that is quite different from what it does in practice, but I would need > > Hui advice to better understand the issue here. > > > > For CRTs the radeon driver doesn't use DDC modes; to do that you have > to set an option "useDDC" or somesuch. It's supposed to use DDC for > flatpanels, but I suspect the logic might have gotten a bit confused. > The mode validation is probably the most confusing part of the driver. It is definitely confusing ... What annoys me a bit here is that there is nothing really driver specific about validating modes ,doing DDC, etc... The only driver-almost-specific thing is wether you have an RMX engine to scale to any mode or not ... and even that, I'm pretty sure most cards have the same capability. So I'm pretty sure all of that complicated and bogus code can be fixed once for all at the core for all drivers, but then, I lack knowledge about X DDX stuff here... Ben.
From alexdeucher at gmail.com Thu Apr 14 06:19:48 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 14 Apr 2005 09:19:48 -0400 Subject: radeon driver, mode selection, RADEONPreInitModes() In-Reply-To: <1113484405.5515.99.camel@gaston> References: <1113455567.5463.82.camel@gaston> <1113456698.5462.87.camel@gaston>
From daniel at fooishbar.org Wed Apr 13 20:25:22 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 14 Apr 2005 13:25:22 +1000 Subject: Xlibs releases link broken In-Reply-To:
On Tue, Mar 29, 2005 at 01:30:26PM -0800, Jeremy C. Reed wrote: > On Tue, 29 Mar 2005, Mohamed CHAARI wrote: >> > I'm newly registered in this mailing list. I have a problem to get >> > the releases of xlibs libraries : the link in the web site is broken >> > since some months (http://freedesktop.org/~xlibs/release/), so I >> > can't have the "tar.gz" of some missing X11 libraries like >> > libxinerama, libxrandr, ... >> > >> > what's happening ? >> >> I don't know what's happening. I have and others have mentioned these >> problems before for months now. > I can't remember exactly where it's referenced, but hey, it's a wiki; anyone can edit them. Hello, Thanks Jeremy for the link to the Xlibs upstream. Sorry for the delay, I didn't receive your e-mail.
-- --Mohamed CHAARI (mailto : mohamed.chaari at st.com)
From idr at us.ibm.com Thu Apr 14 09:07:47 2005 From: idr at us.ibm.com (Ian Romanick) Date: Thu, 14 Apr 2005 09:07:47 -0700 Subject: Why does thread support depend on GLX_DIRECT_RENDERING in libGL? Message-ID: <[email protected]> While working on bug #3024, I noticed something kind of odd. Every place where there is code that depends on XTHREADS being defined, it also depends on GLX_DIRECT_RENDERING being defined. The net result being that the only time you get thread safety in libGL (i.e., a GLX context per thread) is when GLX_DIRECT_RENDERING is defined. This seems wrong. Can any one explain why this is? If not, I'm going to axe it as part of the bug fix. https://bugs.freedesktop.org/show_bug.cgi?id=3024 From keithp at keithp.com Thu Apr 14 09:35:09 2005 From: keithp at keithp.com (Keith Packard) Date: Thu, 14 Apr 2005 09:35:09 -0700 Subject: Why does thread support depend on GLX_DIRECT_RENDERING in libGL? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Thu, 2005-04-14 at 09:07 -0700, Ian Romanick wrote: > While working on bug #3024, I noticed something kind of odd. Every > place where there is code that depends on XTHREADS being defined, it > also depends on GLX_DIRECT_RENDERING being defined. The net result > being that the only time you get thread safety in libGL (i.e., a GLX > context per thread) is when GLX_DIRECT_RENDERING is defined. This seems > wrong. As an aside -- there's a way to detect XTHREADS support in the local Xlib so that libGL can be built correctly if you like. I use the following snippet in various configure.ac files: AC_MSG_CHECKING([for XTHREADS in Xlib]) AC_RUN_IFELSE( [AC_LANG_PROGRAM([[#include
------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From cerdiogenes at yahoo.com.br Fri Apr 15 06:56:31 2005 From: cerdiogenes at yahoo.com.br (=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3 genes?=) Date: Fri, 15 Apr 2005 10:56:31 -0300 Subject: how to debug xinit? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Hi, I'm trying to debug xinit to see how it's avaliate the ViewPort in the xorg.conf. But when I'm using GDB, it's never get in this point, it's output an message "Server error." and exits the program. This occur in these lines: if (startServer(server) > 0 && startClient(client) > 0) { pid = -1; while (pid != clientpid && pid != serverpid #ifndef X_NOT_POSIX && gotSignal == 0 #endif ) pid = wait(NULL); } signal(SIGQUIT, SIG_IGN); signal(SIGINT, SIG_IGN); signal(SIGHUP, SIG_IGN); signal(SIGPIPE, SIG_IGN); shutdown(); the first line is 451 in xc/programs/xinit/xinit.c and when I use 'step' in gdb to verify whats ocurr in 'startServer' I get the error. If I use 'next' it pass, but the validation of the xorg.conf pass through and I can't see how it's done. Thanks, Carlos.
From ajax at nwnk.net Fri Apr 15 10:06:08 2005 From: ajax at nwnk.net (Adam Jackson) Date: Fri, 15 Apr 2005 13:06:08 -0400 Subject: how to debug xinit? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Friday 15 April 2005 09:56, Carlos Eduardo Rodrigues Di?genes wrote: > Hi, > > I'm trying to debug xinit to see how it's avaliate the ViewPort in the > xorg.conf. But when I'm using GDB, it's never get in this point, it's > output an message "Server error." and exits the program. This occur in > these lines: If you're trying to validate what the server is doing, you should debug the server, instead of xinit. The server is typically named 'Xorg'. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
-- Stefan Baltus
From alexdeucher at gmail.com Fri Apr 15 11:26:24 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 15 Apr 2005 14:26:24 -0400 Subject: Dual card setup In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From alan at lxorguk.ukuu.org.uk Fri Apr 15 11:39:16 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Fri, 15 Apr 2005 19:39:16 +0100 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]>
> The speedup using a recent x.org server is less, we currently suspect that > framebuffer reads are the limiting factor now. We're not sure why they are so > slow, but I'm hope on the list can enlighten us. My current suspicion is that > they are not cached in the CPU at all and always go directly to graphics > memory. Correct for PCI/AGP > We can try to reduce framebuffer reads to speed this up (I have some ideas how
> to do this), but we wonder if there are ways to speed up the reads from the > framebuffer, at least from offscreen memory? Use DRI hooks and DMA. That will give you full PCI/AGP bandwidth copying of tiles from the card to the CPU and will be faster for larger blocks. For small blocks the best you can do is ensure you do maximal sized transfers on natural alignment with an x86. Soreen did some timing work on this btw Alan
From otaylor at redhat.com Fri Apr 15 13:18:25 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 15 Apr 2005 16:18:25 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-15 at 16:10 +0200, Lars Knoll wrote: > Hi, > > Zack and myself have in the last two weeks worked on improving performance the
> general composition path in the render extenstion (the code in fbcompose.c). > > You can find patches for xserver and xorg at: > http://trolls.troll.no/lars/render/render_xserver.diff > http://trolls.troll.no/lars/render/render_xorg.diff > > The main change is in fbcompose.c, which you can find separately here: > http://trolls.troll.no/lars/render/fbcompose.c It's very cool that you've been working on this. There's a large outstanding patch from me to merge the MMX code from the xorg tree back to the xserver tree. I think it probably conflicts a fair bit with the above patch, but not in substantive ways. The xorg patch above removes all the changes from the xorg tree that my patch merges from the xorg tree into the xserver tree ... but I think those changes don't have much to do with the bulk of your code, which is all about the general case, instead of special case optimizations. To avoid further confusion, I'll go ahead and commit my changes this evening ... hopefully that won't cause you too much pain. I think it would be very good if someone went through and merged up the remaining differences in fb/ between xserver and xorg. There's no reason that they should differ at all. If we did that, then we could have a simple way of treating fb/ changes ... to say that all changes must go first into xserver than get merged into xorg. In the slightly longer term, the work that needs to be done is to make the X server trees use libpixman. Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From otaylor at redhat.com Fri Apr 15 14:30:05 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 15 Apr 2005 17:30:05 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-15 at 17:02 -0400, Zack Rusin wrote: > On Friday 15 April 2005 16:18, Owen Taylor wrote: > > The xorg patch above removes all the changes from the xorg tree that > > my patch merges from the xorg tree into the xserver tree ... but > > I think those changes don't have much to do with the bulk of your > > code, which is all about the general case, instead of special > > case optimizations. > > Right. > > > To avoid further confusion, I'll go ahead and commit my changes this > > evening ... hopefully that won't cause you too much pain. > > Well, to be honest we removed the mmx code for now. I can add it back > without any problems, but it shouldn't be necessary. That's a confident statement :-) I admit to not having studied your approach in great detail; but if my understanding is correct, you are doing Copy from source, dest into temporary ARGB32 buffers Composite in temporary ARGB32 buffers Copy from temporary ARGB32 buffers to dest Assuming that the temporary buffer fits into L1 cache, that isn't horribly bad, but it's is only going to be fast as an in-place algorithm if you don't get any pipelining between memory accesses and arithmetic in the in-place algorithm. Also, for compositing to video memory, you get a fairly big win by optimizing alpha=0, alpha=255 source pixels to not read from the destination, something that you can't do with your method. While it's better to have a fast general case and no special cases then a slow general case that gets hit and some ultra-fast special cases, it's still better to have a fast general case and some ultra-fast special cases. I don't think you did any testing of the xorg code rendering to system memory? Once I get my patch merged, it might be interesting to try your benchmarks against Xephyr and compare that to your code. > Also since now the combining methods operate on scanlines adding code > that would in a common way accelerate all operations by combining a > couple of pixels in one pass should be rather easy. You do most likely want to MMX optimize the pieces of your algorithm. All my experience is that MMX makes a large (> 2x) improvement for this kind of code. > > I think it would be very good if someone went through and merged up > > the remaining differences in fb/ between xserver and xorg. There's > > no reason that they should differ at all. > > I guess I could do it early next week, but... > > > If we did that, then we could have a simple way of treating fb/ > > changes ... to say that all changes must go first into xserver than > > get merged into xorg. > > Before we do that, lets decide what to do about convolution filters. > Start of them them is in the xserver but not in the xorg or the specs. > Glitz implements them already. We haven't implemented them in our > implementation. I wasn't sure whether I should bother quite yet. This > might be the right moment to figure out what to do with them :) Hmm. I don't think that needs to block merging the rest. (it's mostly small bug fixes that got put into one bit of the xorg code or the other). > > In the slightly longer term, the work that needs to be done is to > > make the X server trees use libpixman. > > Yeah, that'd be good. One other short-term thing I'd like to see is > improving the tessellation code in XRenderCompositeDoublePoly, or maybe > even having one common trapezoidation algorithm that everyone could > share. I guess even merging back the changes from the Cairo tessellator > back into Render would be enough for now. Do we want to link libxrender against libpixman and move the tesellator there? Do we think that XRenderCompositeDoublePoly() is something people should be using at all? Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From otaylor at redhat.com Fri Apr 15 16:39:12 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 15 Apr 2005 19:39:12 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-15 at 18:13 -0400, Zack Rusin wrote: > On Friday 15 April 2005 17:30, Owen Taylor wrote: > > Assuming that the temporary buffer fits into L1 cache, that isn't > > horribly bad, but it's is only going to be fast as an in-place > > algorithm if you don't get any pipelining between memory > > accesses and arithmetic in the in-place algorithm. > > > > Also, for compositing to video memory, you get a fairly big win > > by optimizing alpha=0, alpha=255 source pixels to not read from > > the destination, something that you can't do with your method. > > Right. It's not exactly impossible becaue we still get the source first. > It's just less practical because you would have to scan the source > before fetching the destination. So you'd be forced to scan the source > twice. At this point it might be worth it. Reading from framebuffer memory is so slow, that it might be worth it if you had to send off for the pixels to read by postal mail ;-) You'd basically just need to pass the read-in source buffer to the functions that read and write the destination. (You need it at the write stage to optimize the normal case of alpha == 0). But I think an integrated loop is going to be significantly faster. > > While it's better to have a fast general case and no special cases > > then a slow general case that gets hit and some ultra-fast special > > cases, it's still better to have a fast general case and some > > ultra-fast special cases. > > > > I don't think you did any testing of the xorg code rendering to > > system memory? Once I get my patch merged, it might be interesting > > to try your benchmarks against Xephyr and compare that to your > > code. > > Is that a challenge? ;) More curiousity. > Either way that's not something I'm worried about for two reasons: > a) merging special cases is trivial so we can do in a few minutes > without any problems, Yes, it should just be a matter of not deleting the MMX code :-) > b) operating on scanlines in general gives us more power to use MMX to > optimize the general case itself > > Right now the fact that Lars was sitting in front of the assembly dump > trying to figure out how to combine everything in a most efficient > manner helps quite a bit :) On a real server the combining methods are > hardly visible though. It's the fetch/store cycle that's killing us. If > we could optimize fetching we could easily get a huge improvement. I'd > like to look into what Alan suggested. > > > > Also since now the combining methods operate on scanlines adding > > > code that would in a common way accelerate all operations by > > > combining a couple of pixels in one pass should be rather easy. > > > > You do most likely want to MMX optimize the pieces of your algorithm. > > All my experience is that MMX makes a large (> 2x) improvement for > > this kind of code. > > I'm a PPC fan. Your MMX foo does nothing for me ;) Well, feel free to write fbaltivec.c ... the same compiler intrinsics method will work. > > > Before we do that, lets decide what to do about convolution > > > filters. Start of them them is in the xserver but not in the xorg > > > or the specs. Glitz implements them already. We haven't implemented > > > them in our implementation. I wasn't sure whether I should bother > > > quite yet. This might be the right moment to figure out what to do > > > with them :) > > > > Hmm. I don't think that needs to block merging the rest. (it's mostly > > small bug fixes that got put into one bit of the xorg code or the > > other). > > Personally I'd just like to know what's the official word on convolution > filters. "official" here is I think pretty much whatever the people doing the work decide on. > > Do we want to link libxrender against libpixman and move the > > tesellator there? > > Ideally, yes! > > > Do we think that XRenderCompositeDoublePoly() is > > something people should be using at all? > > To be honest my biggest worry is having tessellation code duplicated in > a few places. Granted that right now it's only Arthur and Cairo but > that's already two places where it should be shared. So having > tessellator in a library that we could share would be very nice. The challenge for Cairo is to make it good enough that you just use it from Authur :-), but certainly we don't want to block code sharing to achieve that goal. Regards, Owen
From benh at kernel.crashing.org Fri Apr 15 16:43:27 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 16 Apr 2005 09:43:27 +1000 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1113608607.5462.215.camel@gaston>
> The speedup using a recent x.org server is less, we currently suspect that > framebuffer reads are the limiting factor now. We're not sure why they are so > slow, but I'm hope on the list can enlighten us. My current suspicion is that > they are not cached in the CPU at all and always go directly to graphics > memory. > > We can try to reduce framebuffer reads to speed this up (I have some ideas how
> to do this), but we wonder if there are ways to speed up the reads from the > framebuffer, at least from offscreen memory? Yes, framebuffer is usually mapped uncacheable. On some architecture, it can have some kind of prefetch but that is not always the case. That also why it's usually better to use the largest possble transfer size from/to the framebuffer to generate long bursts. For example, using the Altivec/VMX on ppc would allow 16 bytes bursts. I suppose MMX/SEE would allow similar, in addition to the actual parallelisation of pixel processing of course. Ben.
From benh at kernel.crashing.org Fri Apr 15 16:44:37 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 16 Apr 2005 09:44:37 +1000 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <1113608677.5516.217.camel@gaston> On Fri, 2005-04-15 at 18:13 -0400, Zack Rusin wrote: > I'm a PPC fan. Your MMX foo does nothing for me ;) Heh :) Then try limiting the accesses to the real framebuffer and doing them with the largest possible burst size, that is altivec register load/stores :)
From benh at kernel.crashing.org Fri Apr 15 16:47:13 2005 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 16 Apr 2005 09:47:13 +1000 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <1113608833.5515.220.camel@gaston> > Use DRI hooks and DMA. That will give you full PCI/AGP bandwidth copying > of tiles from the card to the CPU and will be faster for larger blocks. > For small blocks the best you can do is ensure you do maximal sized > transfers on natural alignment with an x86. > > Soreen did some timing work on this btw Yes, and the radeon driver already have some support for AGP blits, however be careful with that, make it an option somewhere for now. The problem is that not all AGP bridge implementation support AGP writes (card -> AGP memory) and I don't know if we have a way to cascade that info from the low level AGP driver to the X driver. Maximal sized transfers on natural alignement will help on ppc as well. Ben. From ajax at nwnk.net Fri Apr 15 17:14:42 2005 From: ajax at nwnk.net (Adam Jackson) Date: Fri, 15 Apr 2005 20:14:42 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Friday 15 April 2005 10:10, Lars Knoll wrote: > Hi, > > Zack and myself have in the last two weeks worked on improving performance > the general composition path in the render extenstion (the code in > fbcompose.c). Nice work! This fails rendercheck (from /cvs/xapps) for a few transformations and for the component alpha case. I don't know whether that's a bug in your code or in rendercheck but we should verify it. The benchmark numbers you posted look good for the general case but are marginally slower for Over blends, which will probably be 90% of Render usage. I suspect this is a result of not using the MMX path. Xvfb performance (as measured with raster's render_bench) is merely about twice as fast as before for untransformed operations. This is disturbing. Either Xvfb is naive or Xephyr is clever, because Xvfb should in principle be faster, host memory always being faster than the AGP bus. Interesting that it's almost exactly the same speed at both 16bpp and 32bpp. - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From ephracis at linux.se Sat Apr 16 04:00:27 2005 From: ephracis at linux.se (Christoffer Brodd-Reijer) Date: Sat, 16 Apr 2005 13:00:27 +0200 Subject: keyboard module missing Message-ID: <[email protected]> I am struggling with drivers for my video card which requires that I compile xorg with DRI and a lot of other stuff. So I managed to compile some XvMC stuff and put it into the xorg build tree (or how I should put it, I'm a first timer) along with the via driver for unichrome. I then backuped /usr/X11R6/lib/modules and installed xorg. When I restarted it saw that the new xorg only had the via_drv.o in the driver dir (/usr/X11R6/lib/modules/drivers), beside that driver there was no other drivers! Why did not xorg install any drivers? I then thought I could copy every .o file from the old driver dir, but that was just a wild guess and it did not succeed. So I removed the new /usr/X11R6/lib/modules dir and replaced it with my old one. Now here is a interesting thing. When I tried to start xorg it gave me these errors: $ cat /root/xorg-logbackup-1.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (II) Loading extension MIT-SCREEN-SAVER (EE) Failed to load module "Keyboard" (module does not exist, 0) (EE) No Input driver matching `Keyboard' Why was that one missing, and how come that the new xorg did not have any drivers at all? Lucky for me I had made a backup of the entire /usr/X11R6 so I could go back. But should this be? I, forgot to mention, I was using the CVS version of xorg. Christoffer
From michel at daenzer.net Sat Apr 16 06:30:09 2005 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Sat, 16 Apr 2005 09:30:09 -0400 Subject: keyboard module missing In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1113658209.15947.30.camel@localhost> On Sat, 2005-16-04 at 13:00 +0200, Christoffer Brodd-Reijer wrote: > > $ cat /root/xorg-logbackup-1.log | grep EE > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (II) Loading extension MIT-SCREEN-SAVER > (EE) Failed to load module "Keyboard" (module does not exist, 0) > (EE) No Input driver matching `Keyboard' > > Why was that one missing, "Keyboard" only ever worked for the built-in keyboard driver of XFree86 I think. The modular keyboard driver of X.org is called "kbd". "keyboard" is an alias that should work for both X.org and XFree86. > and how come that the new xorg did not have any drivers at all? Maybe you overrode XF86CardDrivers in xc/config/cf/ ?
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From ephracis at linux.se Sat Apr 16 06:43:47 2005 From: ephracis at linux.se (Christoffer Brodd-Reijer) Date: Sat, 16 Apr 2005 15:43:47 +0200 Subject: keyboard module missing In-Reply-To: <1113658209.15947.30.camel@localhost> References: <[email protected]> <1113658209.15947.30.camel@localhost> Message-ID: <[email protected]> Michel D?nzer wrote: >Maybe you overrode XF86CardDrivers in xc/config/cf/ ? > > Hm, I followed the DRI guide for installing xorg over the existing version. That one told me to get and use the host.def located at http://freedesktop.org/~fxkuehl/host.def, in that one I found this line: /* DDX drivers to build: trim this list to your needs */ #define XF86CardDrivers via The guide suggested that I should remove everything else but the one driver that I needed for my card. But this is only affecting video card drivers, right? Cause the new xorg did not have any drivers at all, for example it did not have my synaptics driver for my touchpad and no mouse drivers existed. Nothing.
From mark.carey at gmail.com Sat Apr 16 13:41:30 2005 From: mark.carey at gmail.com (Mark Carey) Date: Sun, 17 Apr 2005 08:41:30 +1200 Subject: xft upgrade path Message-ID: <[email protected]> Hi, I have hit this bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118587 in that mozilla segfaults on startup trying to do font stuff, supposedly effects gnome-terminal as well. The version of xft on my system was installed with X.org 6.8.2, when I examine the .pc file for xft I find I have version 2.1.2.2. Name: Xft Description: X FreeType library Version: 2.1.2.2 Supposedly I need to update to 2.1.6 (see Redhat bugzilla comments), which means a rebuild of X.org, and all the gnome stuff which depends on xft. Google tells me Xft comes from the xlibs project but I cant find the upstream source. From http://xlibs.freedesktop.org/release/current/ page I can find version 2.1.3. http://freedesktop.org/software/fontconfig/releases/ lists xft-2.1.2 as the latest release. Some pointers as to where I would find xft-2.1.6 or later would be much appreciated. >From http://lists.freedesktop.org/pipermail/release-wranglers/2004-March/000047 .html I see some discussion on being able to build versions of xft not bundled in the monolithic tree and comments that a #define HasXft was to be implemented for host.def, did this make it into 6.8.2? Or is it possible that I apply http://cvs.freedesktop.org/xlibs/Xft/xftfreetype.c?r1=text&r2=text&tr1=1.40&tr2= 1.42&makepatch=1&diff_format=c to the xft in X.org 6.8.2 rebuild and the problem fixed. Any suggestions or pointers greatly appreciated..... Mark Carey
From dcb122 at msn.com Sat Apr 16 14:32:29 2005 From: dcb122 at msn.com (Derek Blankenship) Date: Sat, 16 Apr 2005 16:32:29 -0500 Subject: Gentoo Linux Help Message-ID:
What does all this mean, and how can I solve the problem. Thanks for you help. Derek Blankenship ------next part ------An HTML attachment was scrubbed... URL:
What does all this mean, and how can I solve the problem. Thanks for you help. Derek Blankenship ------next part ------An HTML attachment was scrubbed... URL:
From josh at freedesktop.org Sat Apr 16 18:17:25 2005 From: josh at freedesktop.org (Josh Triplett) Date: Sat, 16 Apr 2005 18:17:25 -0700 Subject: Xss/COPYING in xlibs CVS contains GPL Message-ID: <[email protected]> In the xlibs module, Xss/COPYING contains a copy of the GPL. I'm assuming this is unintentional, and caused by GNU autotools? If this is the case, may I replace it with the X Consortium copyright notice and license at the top of Xss/XScrnSaver.c? - Josh Triplett ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL:
From otaylor at redhat.com Sat Apr 16 19:39:59 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 16 Apr 2005 22:39:59 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sat, 2005-04-16 at 20:48 -0400, Zack Rusin wrote: > On Saturday 16 April 2005 18:59, Owen Taylor wrote: > > On Fri, 2005-04-15 at 20:35 -0400, Zack Rusin wrote: > > > > The benchmark numbers you posted look good for the general case > > > > but are marginally slower for Over blends, which will probably be > > > > 90% of Render usage. I suspect this is a result of not using the > > > > MMX path. > > > > > > Right. The super-fancy special casing is not in ;) Once Owen > > > commits the MMX code to xserver we'll merge that back in and I'll > > > add some AltiVec code because we just can't have PPC trailing > > > behind, can we? ;) > > > > This was committed yesterday. (Had to get Soeren to do it for me > > since I don't have commit access to the xserver tree, as it turns > > out.) > > Great, thanks. You forgot to commit the fbmmx.{h,c} files though. Attached below. I don't know of Soeren is around today ... if someone wants to commit them to get things compiling again, that might be a good idea. Regards, Owen
------next part ------A non-text attachment was scrubbed... Name: fbmmx.c Type: text/x-csrc Size: 42415 bytes Desc: not available URL:
From Alan.Coopersmith at Sun.COM Sat Apr 16 20:19:35 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sat, 16 Apr 2005 20:19:35 -0700 Subject: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Sergey Udaltsov wrote: > Tonight there was discussion on IRC regarding the integration process > for xkeyboard-config. Talking about the porting to the monolythic > tree, some points were mentioned: > > 1. New dependency in the build process - intltool Which in turn brings in it's own dependencies, since last I checked, intltool was incompatible with non-GNU versions of xgettext. > 2. Potential problems with xorg.conf for many users > 3. Full compatibility with the current X.Org code (server, xkbcomp, setxkbmap) How many users will be broken? Why is it a good idea to break compatibility? Why is it not a better idea to simply continue to ship the working files we have and not break things for our users? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From keithp at keithp.com Sat Apr 16 23:08:17 2005 From: keithp at keithp.com (Keith Packard) Date: Sun, 17 Apr 2005 16:08:17 +1000 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-15 at 17:30 -0400, Owen Taylor wrote: > Do we want to link libxrender against libpixman and move the tesellator > there? Do we think that XRenderCompositeDoublePoly() is something people > should be using at all? Ack! Zombie functions from beyond the grave! That code should never have been written, and would have been deleted a long time ago if xclock wasn't using it. I don't know how to get rid of it now though, suggestions would be welcome. -keith ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From Alan.Coopersmith at Sun.COM Sun Apr 17 09:21:10 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 17 Apr 2005 09:21:10 -0700 Subject: [xkb] Re: xkeyboard-config and modular release In-Reply-To:
From Alan.Coopersmith at Sun.COM Sun Apr 17 09:28:38 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 17 Apr 2005 09:28:38 -0700 Subject: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Sergey Udaltsov wrote: >>How many users will be broken? Why is it a good idea to break >>compatibility? Why is it not a better idea to simply continue >>to ship the working files we have and not break things for our users? > > Because they are not working properly. They are not consistent. The > organization of the layout tree is ad-hoc and messy. And, finally, > there are loads of bugs which are fixed in our code. It's nice to have a clean tree, but more important to not break existing configs, so if it's just consistency and cleanliness, I see no reason to break what users already have. If there's no other way to fix bugs, that's one thing, but if we're breaking users just because we can, that's a serious mistake I'd like to avoid. Now, that's not to say I don't appreciate the work put into trying to get the layouts working, and I'd like to see a way to use that work without breaking users who are already happy with their config. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From sergey.udaltsov at gmail.com Sun Apr 17 10:10:21 2005 From: sergey.udaltsov at gmail.com (Sergey Udaltsov) Date: Sun, 17 Apr 2005 18:10:21 +0100 Subject: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > It's nice to have a clean tree, but more important to not break > existing configs, so if it's just consistency and cleanliness, Not only this. In xorg 6.7, there is a mixture of layout supporting "multiple layout" and the ones which do not. That is why people get this nice GNOME "XKB error" dialog - for non-compatible layouts. And there is no way to fix it finally without breaking user's config files - for example, for Canadian users (Hungarian, Mongolian etc). Inconsistency in existing tree is really outrageous - users ask when they should look for variants - and when they should look for standalone layouts (xorg has 4 'se' layouts, 3 'hu' etc - not variants, layouts!). In xkeyboard config ALL layouts are compatible with "multiple layouts" feature (and they ALL are moved from the 'symbols/pc' subdirectory to the 'symbols' directory - because old layout are not going to be supported). > users just because we can, that's a serious mistake I'd like to > avoid. Of course. Understanding this, we are trying to introduce the compatibity rules, just to keep the compatibility on 'XkbLayout' level (--enable-compat-rules). But for SOME people using 'XkbSymbols' compatibility would be broken anyway - just because of the removal of the old obsolete (unmaintained, incompatible!) code. BTW, talking about configuration files. We changed the rules file name to 'base' (from 'xorg' which was derived from 'xfree86'). But it should not be a problem if xkeyboard-config is built with --with-xkb-rules-symlink option - so here we are also trying to protect users. In a word - we realize the importance of the compatibility. And we are trying to be as compatible as we can. But we realize we cannot be 100% compatible - and since we are not, we are using this 'moment of breakage' in order to clean up the tree and introduce some logic in the layouts.
Cheers, Sergey
From otaylor at redhat.com Sun Apr 17 10:25:04 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 17 Apr 2005 13:25:04 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sun, 2005-04-17 at 16:18 +1000, Carl Worth wrote: > On Sat, 16 Apr 2005 22:39:59 -0400, Owen Taylor wrote: > > > On Saturday 16 April 2005 18:59, Owen Taylor wrote: > > > > This was committed yesterday. (Had to get Soeren to do it for me > > > > since I don't have commit access to the xserver tree, as it turns > > > > out.) > > Ouch. That's not a good state. I've just fixed this. > now. Thanks. > > Attached below. I don't know of Soeren is around today ... if someone > > wants to commit them to get things compiling again, that might be a > > good idea. > > You should be able to take care of this yourself now. Done. Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From Alan.Coopersmith at Sun.COM Sun Apr 17 14:18:44 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sun, 17 Apr 2005 14:18:44 -0700 Subject: [xkb] Re: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]>
From sergey.udaltsov at gmail.com Sun Apr 17 15:02:36 2005 From: sergey.udaltsov at gmail.com (Sergey Udaltsov) Date: Sun, 17 Apr 2005 23:02:36 +0100 Subject: [xkb] Re: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]>
> What you have now is a broken hack that barely works when used with > the X server it expects, and breaks completely when you replace your > X server or remote display to a machine with a different X server. Well, there is xmodmap fallback in GNOME 2.10 - but you are right, since XKB is uncapable to deliver necessary information, I have to use private X server library and build on top of it. Returing to the original message - AFAIK it is mostly internal tools (setxkbmap/xkbcomp) which use xorg.lst file. Regarding the org.xml file - AFAIK only libxklavier is using it (and its structure is visible through gnome-keyboard-properties) - which returns us to the discussion regarding this 'broken hack'. Sergey From somekool at gmail.com Sun Apr 17 16:03:22 2005 From: somekool at gmail.com (somekool at gmail.com) Date: Sun, 17 Apr 2005 16:03:22 -0700 Subject: killer feature for XOrg. Message-ID: <[email protected]> Howdy,.... there is something I always wish xfree would do but never did, and I feel now with XOrg, its possible. I would like every X Client (window) to be detachable likes the command line utility screen and then I would like to be able to kill my X server, reattach the client whenever I want on whatever X server I want, even remote X. so we could have window manager offering to the user "Send this window to ..." and you could send a window to your friend running a X server too... in fact, it would detach the window and reattach it somewhere else. what do you guys think ? Mathieu -- -- thanks to visit http://justbudget.com and give your feedback. -- Due to the current virus surge, Linux is highly recommended for e-mail and Internet operations. -- When mass sending, make TO: equal to FROM: And everybody else in BCC:
From roland.mainz at nrubsig.org Sun Apr 17 16:11:10 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Mon, 18 Apr 2005 01:11:10 +0200 Subject: killer feature for XOrg. References: <[email protected]> Message-ID: <[email protected]> somekool at gmail.com wrote: > there is something I always wish xfree would do but never did, and I feel now > with XOrg, its possible. I would like every X Client (window) to be > detachable likes the command line utility screen and then I would like to be > able to kill my X server, reattach the client whenever I want on whatever X > server I want, even remote X. > > so we could have window manager offering to the user "Send this window to ..." > and you could send a window to your friend running a X server too... > > in fact, it would detach the window and reattach it somewhere else. > > what do you guys think ? You may want to wait for a public release of David Flynn's "xproxy" which allows such stuff. Otherwise you are bound to support for such a feature at the toolkit level which may allow the transition of one application between Xservers. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
From glynn at gclements.plus.com Sun Apr 17 18:03:25 2005 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon, 18 Apr 2005 02:03:25 +0100 Subject: killer feature for XOrg. In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> somekool at gmail.com wrote: > there is something I always wish xfree would do but never did, and I feel now > with XOrg, its possible. I would like every X Client (window) to be > detachable likes the command line utility screen and then I would like to be > able to kill my X server, reattach the client whenever I want on whatever X > server I want, even remote X. > > so we could have window manager offering to the user "Send this window to ..."
> and you could send a window to your friend running a X server too... > > in fact, it would detach the window and reattach it somewhere else. > > what do you guys think ? It isn't realistic to implement this at the X protocol or Xlib levels. Too many things would need to be changed that it wouldn't really be X any more (i.e. you're talking about The Y Window System, not X12 and certainly not X11R
From daniel at fooishbar.org Sun Apr 17 18:36:57 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 18 Apr 2005 11:36:57 +1000 Subject: Xss/COPYING in xlibs CVS contains GPL In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Sat, Apr 16, 2005 at 06:17:25PM -0700, Josh Triplett wrote: > In the xlibs module, Xss/COPYING contains a copy of the GPL. I'm > assuming this is unintentional, and caused by GNU autotools? If this is > the case, may I replace it with the X Consortium copyright notice and > license at the top of Xss/XScrnSaver.c? Utterly unintentional, and yes. Thanks for picking it up. Note to people autotooling stuff: you really, really, really, do need AUTOMAKE_OPTIONS=foreign. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
>>and you could send a window to your friend running a X server too... >> >>in fact, it would detach the window and reattach it somewhere else. >> >>what do you guys think ? > > > It isn't realistic to implement this at the X protocol or Xlib levels. > Too many things would need to be changed that it wouldn't really be X > any more (i.e. you're talking about The Y Window System, not X12 and > certainly not X11R
From andjoh at rydsbo.net Sun Apr 17 20:00:55 2005 From: andjoh at rydsbo.net (Anders Johansson) Date: Mon, 18 Apr 2005 05:00:55 +0200 Subject: Logitech Media Keyboard Message-ID: <[email protected]> Hi, Sorry if this has been asked before, I searched but couldn't find any info on it I'm trying to get the Logitech Media keyboard's media keys working in X.org 6.8.2 (suse 9.3) with some success. I took the Internet keyboard's xkb definitions and modified it, so now I have most keys working. Except the 'Messenger' key. xev reports it as a mouse button, for some reason. Actually two mouse buttons. On key press, xev reports button 4 pressed and released, and on key release it reports button 5 pressed and released. I'm using the 'kbd' driver with Protocol "Standard" and XkbRules "xfree86". This is what is used by the Internet Keyboard (according to suse's config) but I wonder if perhaps there is another protocol or something that would make X understand that the messenger key isn't a mouse button Did I miss anything?
From josh.trip at verizon.net Sun Apr 17 20:31:00 2005 From: josh.trip at verizon.net (Josh Triplett) Date: Sun, 17 Apr 2005 20:31:00 -0700 Subject: Various missing COPYING files and licenses in xlibs module Message-ID: <[email protected]> The following directories don't have a COPYING file: DMXExt EvIEExt ScrnSaverExt XCalibrate XCalibrateExt XF86DGAExt XF86MiscExt XF86RushExt XF86VMExt XTrap Xevie Xinerama Xp XvMC Xxf86dga Xxf86misc Xxf86rush Xxf86vm xkbui Of those directories, in most cases the COPYING file could be generated by grabbing the appropriate licenses from the tops of the source files. However, of the above, the following also contain some source files with no licenses either (note that I only looked to see that at least one source file had a license, not necessarily all of them): XF86DGAExt XF86MiscExt XF86RushExt Xinerama XvMC Xxf86dga Xxf86misc Xxf86rush Several directories also had present-but-empty COPYING files (either completely empty, or containing only a CVS keyword): FS RecordExt ResourceExt Xaw Xfont Xmu Xrandr Of those, none have missing file licenses.
Finally, many of the modules also have missing or empty AUTHORS files.
These issues were discovered while trying to construct debian/copyright files. - Josh Triplett ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL:
Josh Triplett wrote: > The following directories don't have a COPYING file: > > DMXExt > EvIEExt > ScrnSaverExt > XCalibrate > XCalibrateExt > XF86DGAExt > XF86MiscExt > XF86RushExt > XF86VMExt > XTrap > Xevie > Xinerama > Xp > XvMC > Xxf86dga > Xxf86misc > Xxf86rush > Xxf86vm > xkbui > > Of those directories, in most cases the COPYING file could be generated > by grabbing the appropriate licenses from the tops of the source files. > However, of the above, the following also contain some source files > with no licenses either (note that I only looked to see that at least > one source file had a license, not necessarily all of them): > > XF86DGAExt > XF86MiscExt > XF86RushExt > Xinerama > XvMC > Xxf86dga > Xxf86misc > Xxf86rush > > Several directories also had present-but-empty COPYING files (either > completely empty, or containing only a CVS keyword): > > FS > RecordExt > ResourceExt > Xaw > Xfont > Xmu > Xrandr > > Of those, none have missing file licenses. > > > Finally, many of the modules also have missing or empty AUTHORS files. > > > These issues were discovered while trying to construct debian/copyright > files. > > - Josh Triplett > > > ------> > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
From michel at daenzer.net Mon Apr 18 08:59:40 2005 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Mon, 18 Apr 2005 11:59:40 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <1113839981.16000.123.camel@localhost> On Sat, 2005-16-04 at 20:48 -0400, Zack Rusin wrote: > On Saturday 16 April 2005 18:59, Owen Taylor wrote: > > On Fri, 2005-04-15 at 20:35 -0400, Zack Rusin wrote: > > > > The benchmark numbers you posted look good for the general case > > > > but are marginally slower for Over blends, which will probably be > > > > 90% of Render usage. I suspect this is a result of not using the > > > > MMX path. > > > > > > Right. The super-fancy special casing is not in ;) Once Owen > > > commits the MMX code to xserver we'll merge that back in and I'll > > > add some AltiVec code because we just can't have PPC trailing > > > behind, can we? ;) > > > > This was committed yesterday. (Had to get Soeren to do it for me > > since I don't have commit access to the xserver tree, as it turns > > out.) > > Great, thanks. You forgot to commit the fbmmx.{h,c} files though. I > merged in our changes anyway. The new diff is at > http://ktown.kde.org/~zrusin/render_xserver.diff . But this one is > completely untested (I have to leave for a bit. It compiles, hence we > can ship it, we just might not want to be running it ;) ) . The MMX code in the xserver tree is broken here (only the shadows of translucent windows are visible), but it seems to be the same with or without your patch.
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From zrusin at trolltech.com Mon Apr 18 09:12:57 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Mon, 18 Apr 2005 12:12:57 -0400 Subject: render improvements In-Reply-To: <1113839981.16000.123.camel@localhost> References: <[email protected]> <[email protected]> <1113839981.16000.123.camel@localhost> Message-ID: <[email protected]> On Monday 18 April 2005 11:59, Michel D?nzer wrote: > > Great, thanks. You forgot to commit the fbmmx.{h,c} files though. I > > merged in our changes anyway. The new diff is at > > http://ktown.kde.org/~zrusin/render_xserver.diff . But this one is > > completely untested (I have to leave for a bit. It compiles, hence > > we can ship it, we just might not want to be running it ;) ) . > > The MMX code in the xserver tree is broken here (only the shadows of > translucent windows are visible), but it seems to be the same with or > without your patch. The new composition patch or the MMX patch? An easy way of figuring out what ops are broken is by running http://ktown.kde.org/~zrusin/render_ops.tar.bz2 which shows the visual results of all the basic ops (but I'm using Qt4 to setup widgets as paintareas for Render, it would be very easy to port it to either pure Xlib or anything else). Zack -- Every man for himself, all in favour say "I"
From leon at magic.shiman.com Mon Apr 18 09:41:46 2005 From: leon at magic.shiman.com (Leon Shiman) Date: Mon, 18 Apr 2005 12:41:46 -0400 (EDT) Subject: Major contribution to X.Org Foundation by Aptest and Open Group Message-ID: <[email protected]>
X Window System Test Suite Contributed by ApTest and Open Group to The X.Org Foundation Released under "X" Open Source License. ------Brookline Massachusetts, 18 April 2005. The X.Org Foundation, global steward of the X Window System* and Standards, announced today that ApTest and Open Group have together donated their VSW5 Test Suite to The X.Org Foundation, where it shall be released under their standard Open Source license as XTS 5.0.2. The X Window System is released by the X.Org Foundation under the MIT ("X") License. The VSW5 Test Suite is the industry best practice in testing the X Window System. All Official X.Org releases are free and available for download from ftp://www.x.org/pub and at mirror-sites world-wide.
"ApTest is excited by the opportunity X.Org offers the X community. We are pleased to contribute our technology and look forward to participating in ensuring the ongoing quality of X releases" said Shane McCarron, Managing Director of ApTest Minnesota "The Open Group congratulates the X.Org Foundation on making the free availability of the X Window System Test Suite (VSW5) under an open source license possible and establishing a test working group" said Andrew Josey, Director of Certification at The Open Group. "This initiative will further enhance the quality of the X Window System and we look forward to working with X.Org. As part of that cooperation we plan to contribute a number of patches to the code base. To support the development of this critical and unique testing technology in tandem with the X Window System itself, the X.Org Foundation also announces the formation of a Testing Workgroup, to be lead by Stuart Anderson, for maintenance and extension of the test suites. Information about this workgroup can be found at http://www.x.org/TestGroup. Membership in all X.Org work groups is open and free. About VSW5: The VSW5 Test Suite is the latest in an evolutionary series of test suites for the X Window System that began in the early 1990's. The VSW Test Suite is built on the Open Group's Test Environment Toolkit (TET) framework (http://tetworks.opengroup.org/). The VSW test suite is a part of the branding program for both UNIX and Linux Standard Base (LSB) systems. About ApTest: Applied Testing and Technology has provided testing analysis, design, development, and execution services to its clients since 1993. ApTest specializes in outsourced product testing and the development of automated test suites, test tools, and test technology. We also develop and market the ApTest Manager test management system - a web-based product for managing QA testing across the enterprise. Further information on ApTest can be found at http://www.aptest.com or from Andy Silverman at 408-399-1930. About the Open Group: The Open Group is a specialist in the development and operation of certification programs for software specifications endorsed by industry standards bodies. The Open Group has a fifteen-year history of the provision of high quality test suites and certification related services to the software industry, and has been the active maintainer of VSW5 and X Window System certification for a number of years. Further information on The Open Group can be found at http://www.opengroup.org.
About the X.Org Foundation: X.Org Foundation L.L.C. is a Delaware company organized to operate as a scientific charity under IRS code 501(c)(3), chartered to develop and execute effective strategies that provide worldwide stewardship of the X Window System technology and standards. The group is currently managed by its Board of Directors that includes: Stuart Anderson (Free Standards Group), Egbert Eich (Novell), Jim Gettys (HP), Stuart Kreitman (SUN Microsystems), Kevin Martin (Red Hat), Jim McQuillan (Linux Terminal Server Project), Keith Packard (HP), and Leon Shiman (Shiman Associates). The website for the X.Org Foundation can be found at http://www.x.org/. ------Please Contact Leon Shiman, Secretary, X.Org Foundation at leon at shiman.com with any questions. From Alan.Coopersmith at Sun.COM Mon Apr 18 10:19:26 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 18 Apr 2005 10:19:26 -0700 Subject: Major contribution to X.Org Foundation by Aptest and Open Group In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Leon Shiman wrote: > The X.Org Foundation, global steward of the X Window System* and Standards, > announced today that ApTest and Open Group have together donated their VSW5 > Test Suite to The X.Org Foundation, where it shall be released under > their standard Open Source license as XTS 5.0.2. The X Window System is > released by the X.Org Foundation under the MIT ("X") License. The VSW5 Test > Suite is the industry best practice in testing the X Window System. This is great - just one question. VSW5 5.1.5 is the current version from the Open Group under the old license - is that the same version as in XTS 5.0.2 or how do these version numbers map? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From leon at magic.shiman.com Mon Apr 18 10:31:32 2005 From: leon at magic.shiman.com (Leon Shiman) Date: Mon, 18 Apr 2005 13:31:32 -0400 (EDT) Subject: Major contribution to X.Org Foundation by Aptest and Open Group Message-ID: <[email protected]> on Mon, 18 Apr 2005 10:19:26 -0700 Alan Coopersmith wrote: > >Leon Shiman wrote: >> The X.Org Foundation, global steward of the X Window System* and Standards, >> announced today that ApTest and Open Group have together donated their VSW5 >> Test Suite to The X.Org Foundation, where it shall be released under >> their standard Open Source license as XTS 5.0.2. The X Window System is >> released by the X.Org Foundation under the MIT ("X") License. The VSW5 Test >> Suite is the industry best practice in testing the X Window System. > >This is great - just one question. VSW5 5.1.5 is the current version from >the Open Group under the old license - is that the same version as in XTS >5.0.2 or how do these version numbers map? Stuart Anderson, who chairs X.Org's Testing Work Group will be coordinating the evolution of XTS. VSW5 5.0.2 is the starting point. Leon > >-- > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering From reed at reedmedia.net Mon Apr 18 10:44:27 2005 From: reed at reedmedia.net (Jeremy C. Reed) Date: Mon, 18 Apr 2005 10:44:27 -0700 (PDT) Subject: Various missing COPYING files and licenses in xlibs module In-Reply-To: <[email protected]> Message-ID:
From otaylor at redhat.com Mon Apr 18 12:36:33 2005 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 18 Apr 2005 15:36:33 -0400 Subject: render improvements In-Reply-To: <1113839981.16000.123.camel@localhost> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <1113839981.16000.123.camel@localhost> Message-ID: <[email protected]> On Mon, 2005-04-18 at 11:59 -0400, Michel D?nzer wrote: > On Sat, 2005-16-04 at 20:48 -0400, Zack Rusin wrote: > > On Saturday 16 April 2005 18:59, Owen Taylor wrote: > > > On Fri, 2005-04-15 at 20:35 -0400, Zack Rusin wrote: > > > > > The benchmark numbers you posted look good for the general case > > > > > but are marginally slower for Over blends, which will probably be > > > > > 90% of Render usage. I suspect this is a result of not using the > > > > > MMX path. > > > > > > > > Right. The super-fancy special casing is not in ;) Once Owen > > > > commits the MMX code to xserver we'll merge that back in and I'll > > > > add some AltiVec code because we just can't have PPC trailing > > > > behind, can we? ;) > > > > > > This was committed yesterday. (Had to get Soeren to do it for me > > > since I don't have commit access to the xserver tree, as it turns > > > out.) > > > > Great, thanks. You forgot to commit the fbmmx.{h,c} files though. I > > merged in our changes anyway. The new diff is at > > http://ktown.kde.org/~zrusin/render_xserver.diff . But this one is > > completely untested (I have to leave for a bit. It compiles, hence we > > can ship it, we just might not want to be running it ;) ) . > > The MMX code in the xserver tree is broken here (only the shadows of > translucent windows are visible), but it seems to be the same with or > without your patch. Hmm, can you be specific about how you are testing here? I've seen some problems that I'll try to track down, but more information about what is broken at the moment would be useful. Thanks, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From Stuart.Kreitman at Sun.COM Mon Apr 18 13:37:04 2005 From: Stuart.Kreitman at Sun.COM (Stuart Kreitman) Date: Mon, 18 Apr 2005 13:37:04 -0700 Subject: Questions In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Outside of Sun, Egbert Eich knows the most about this. He authored to X.org version. Inside Sun, I'm probably yer guy. skk
Viet Pham wrote: >Hi All, >I don't know if this is the right mailing list but looks closest to what >I am looking for. I apologize if it is not the correct one. > >I am looking for the developers of xvfb package. Could you please point >me to the right person or persons or mailing list. Thanks. > >______>xorg mailing list >xorg at lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xorg > >
From sandmann at daimi.au.dk Mon Apr 18 14:21:19 2005 From: sandmann at daimi.au.dk (Soeren Sandmann) Date: 18 Apr 2005 23:21:19 +0200 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID:
Soeren
From keithp at keithp.com Mon Apr 18 14:51:16 2005 From: keithp at keithp.com (Keith Packard) Date: Tue, 19 Apr 2005 07:51:16 +1000 Subject: render improvements In-Reply-To:
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From otaylor at redhat.com Mon Apr 18 15:09:14 2005 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 18 Apr 2005 18:09:14 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <1113839981.16000.123.camel@localhost> <[email protected]> Message-ID: <[email protected]> On Mon, 2005-04-18 at 15:36 -0400, Owen Taylor wrote: > > The MMX code in the xserver tree is broken here (only the shadows of > > translucent windows are visible), but it seems to be the same with or > > without your patch. > > Hmm, can you be specific about how you are testing here? I've seen some > problems that I'll try to track down, but more information about what is > broken at the moment would be useful. OK, the problems that I thought I saw don't exist, so information about how you are testing would be much appreciated. (Especially if you can reproduce with Xephyr or Xfake) Regards, Owen [Sorry for the noise here]
From fxkuehl at gmx.de Mon Apr 18 15:17:19 2005 From: fxkuehl at gmx.de (Felix =?ISO-8859-1?Q?K=FChling?=) Date: Tue, 19 Apr 2005 00:17:19 +0200 Subject: keyboard module missing In-Reply-To: <[email protected]> References: <[email protected]> <1113658209.15947.30.camel@localhost> <[email protected]> Message-ID: <1113862639.3435.17.camel@trabant> Am Samstag, den 16.04.2005, 15:43 +0200 schrieb Christoffer Brodd-Reijer: > Michel D?nzer wrote: > > >Maybe you overrode XF86CardDrivers in xc/config/cf/ ? > > > > > > Hm, I followed the DRI guide for installing xorg over the existing > version. That one told me to get and use the host.def located at > http://freedesktop.org/~fxkuehl/host.def, in that one I found this line: > > /* DDX drivers to build: trim this list to your needs */ > #define XF86CardDrivers via > > The guide suggested that I should remove everything else but the one > driver that I needed for my card. But this is only affecting video card > drivers, right? Cause the new xorg did not have any drivers at all, for > example it did not have my synaptics driver for my touchpad and no mouse > drivers existed. Nothing. These instructions are for installing an X.org server and a few libraries on top of an existing Xorg or Xfree86 installation. If you want to build and install a full Xorg, they are not suitable. Anyway, the synaptics driver is not part of Xorg. You need to get it from somewhere else. In Debian Sarge for example it's in a separate package (xfree86-driver-synaptics). The binary from that package works for me with a current Xorg server too. As to your keyboard problem, I had to change the Driver in the keyboard's InputDevice-section to "kbd" when I first installed an Xorg server. The keyboard-alias never worked for me. Mvh, Felix -- | Felix K?hling
From daniel at fooishbar.org Mon Apr 18 15:16:26 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 19 Apr 2005 08:16:26 +1000 Subject: Various missing COPYING files and licenses in xlibs module In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mon, Apr 18, 2005 at 08:33:43AM -0700, Alan Coopersmith wrote: > Is anyone going to continue maintaining the old xlibs modules once > the Xorg modular tree gets going? Is there any reason to put in much > more effort there? While it was a useful expirement and is still a > source of info for the Xorg modularization, I'm not sure I see a long-term > purpose for it to continue - most experimentation could be done in CVS > branches on the Xorg modular tree. I don't see any use for it, no. However, there's no reason to stop working on it, since the split there is (almost?) identical to the one being proposed for X11R7; whatever's done there now will be useful for 'the modular tree'. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
From otaylor at redhat.com Mon Apr 18 15:58:46 2005 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 18 Apr 2005 18:58:46 -0400 Subject: render improvements In-Reply-To: <1113861616.15945.147.camel@localhost> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <1113839981.16000.123.camel@localhost> <[email protected]> <1113861616.15945.147.camel@localhost> Message-ID: <[email protected]> On Mon, 2005-04-18 at 18:00 -0400, Michel D?nzer wrote: > On Mon, 2005-18-04 at 15:36 -0400, Owen Taylor wrote: > > On Mon, 2005-04-18 at 11:59 -0400, Michel D?nzer wrote: > > > > > > The MMX code in the xserver tree is broken here (only the shadows of > > > translucent windows are visible), [...] > > > > Hmm, can you be specific about how you are testing here? I've seen some > > problems that I'll try to track down, but more information about what is > > broken at the moment would be useful. > > Just run a compositing manager on Xephyr and make any window > translucent. As soon as it stops being fully opaque, it becomes > invisible (except for some small, seemingly random areas, sometimes), > you only see the shadow behind it. So the global alpha value of the > window doesn't seem to be handled correctly. > > If you can't reproduce it, I can create screenshots tomorrow at work. OK, fixed in xserver. The same fixes need to be merged back to xorg (I guess I shouldn't have turned down that offer of commit access to xorg so fast...) In xorg the function is called fbCompositeSrc_8888x8x8888mmx() instead of fbCompositeSrc_x888x8x8888mmx. (I fixed the name when merging, but not the function.) Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: diff Type: text/x-patch Size: 1714 bytes Desc: not available URL:
From airlied at gmail.com Mon Apr 18 16:38:33 2005 From: airlied at gmail.com (Dave Airlie) Date: Tue, 19 Apr 2005 09:38:33 +1000 Subject: keyboard module missing In-Reply-To: <[email protected]> References: <[email protected]> <1113658209.15947.30.camel@localhost> <[email protected]> <1113862639.3435.17.camel@trabant> <[email protected]> Message-ID: <[email protected]> > > > I am not sure if I want to build a full Xorg. What I want is just to > install Unichrome drivers in xorg and I don't know if that requires a > whole new installation of xorg or if I can install over my existing > version. Anyway, now when I did install over my existing xorg my modules > were removed, as I said earlier. Can I do this and then replace the > module-dir with my old one (the one I am using now), would this be OK if > all I want is to install drivers to xorg? Build the whole lot it is easier in the long run, with the change to the loaders recently you end up with modules of both types and this can cause issues.. your best bet is install distros latest Xorg release, build new Xorg, mv /usr/X11R6/lib/modules out of the way and make install the CVS one.. Dave.
From zrusin at trolltech.com Mon Apr 18 16:40:16 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Mon, 18 Apr 2005 19:40:16 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]>
From zrusin at trolltech.com Mon Apr 18 16:48:03 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Mon, 18 Apr 2005 19:48:03 -0400 Subject: render improvements In-Reply-To:
From keithp at keithp.com Mon Apr 18 16:51:55 2005 From: keithp at keithp.com (Keith Packard) Date: Tue, 19 Apr 2005 09:51:55 +1000 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]>
>> However, all the sufficiently modern tools read xorg.lst or xorg.xml >> to get list of available layouts (or xfree86.lst/xfree86.xml), and >> these are even better with xkeyboard-config (they are translated, more >> complete, etc.). > > Any tool outside the X server and it's bundled configuration tools that > reads XKB configuration files is broken by design, so that's hardly much > of an argument. Thinking that way does not solve the real problems however. The state of xkb configuration in the current tree leaves a lot to be desired. Ivan and Sergey have spent a great deal of time and effort to solve the problems and in as clean a way as possible, with long term vision. I for one would like to see their work included into the Xorg CVS head as soon as possible, so that the plethora of incoming bugs concerning xkb can some day come to a stop.
From mharris at www.linux.org.uk Mon Apr 18 23:52:05 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Tue, 19 Apr 2005 02:52:05 -0400 Subject: xkeyboard-config and modular release In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Sergey Udaltsov wrote: >>It's nice to have a clean tree, but more important to not break >>existing configs, so if it's just consistency and cleanliness, > > Not only this. In xorg 6.7, there is a mixture of layout supporting > "multiple layout" and the ones which do not. That is why people get > this nice GNOME "XKB error" dialog - for non-compatible layouts. And > there is no way to fix it finally without breaking user's config files > - for example, for Canadian users (Hungarian, Mongolian etc). Indeed. Red Hat bugzilla gets inundated with bug reports from Canadian, Hungarian and other users, to which we refer upstream, as there is no way to fix what is there currently without larger changes you propose. All other distributions seem to get inundated with these problems as well. Attempting to solve the problems by applying ugly distribution specific hacks that wont and should not be included upstream is not a solution, as it just breaks something for some other user, creating an ongoing and never ending maintenance nightmare. This is a problem that needs to be solved directly in the upstream project IMHO, and xkeyboard-config seems to be the right solution to the problem to me.
> Inconsistency in existing tree is really outrageous - users ask when > they should look for variants - and when they should look for > standalone layouts (xorg has 4 'se' layouts, 3 'hu' etc - not > variants, layouts!). I think this is caused due to bit rot over the years, and lack of documentation and overall sanity in the xkb files. My observation has been that random users want a particular keyboard layout, explore X to find it doesn't exist, they copy an existing layout and modify it to their liking, then they submit bug reports to their distribution vendor or to XFree86 or X.Org to request their new custom layout be included. Generally, every request is honoured and the number of xkb layouts blooms each release. Nobody really took charge of the problem until Ivan and yourself came along to fix the underlying problem and to provide a more solid framework for future enhancement. It's unfortunate that your work hasn't been included in X.Org already, but I hope to see it integrated into X11R7 at least.
> In xkeyboard config ALL layouts are compatible with "multiple layouts" > feature (and they ALL are moved from the 'symbols/pc' subdirectory to > the 'symbols' directory - because old layout are not going to be > supported). That will be an absolute godsend. The number of bug reports received about this problem is staggering. What's worse is people don't care what the problem is, they just want a solution and feel it is rediculous that it isn't solved yet. Since it *is* solved though, it is a shame to not have the solution integrated into the tree so everyone benefits. I hope that it does get integrated now.
>>users just because we can, that's a serious mistake I'd like to >>avoid. > > Of course. Understanding this, we are trying to introduce the > compatibity rules, just to keep the compatibility on 'XkbLayout' level > (--enable-compat-rules). But for SOME people using 'XkbSymbols' > compatibility would be broken anyway - just because of the removal of > the old obsolete (unmaintained, incompatible!) code. I think that a small amount of growing pain is well justified for long term sanity of a better design/solution. > BTW, talking about configuration files. We changed the rules file name > to 'base' (from 'xorg' which was derived from 'xfree86'). But it > should not be a problem if xkeyboard-config is built with > --with-xkb-rules-symlink option - so here we are also trying to > protect users. That was only a problem due to broken applications out there assuming that if you're using an X server, it is XFree86. I was shocked at how many things hard coded "xfree86". The ugly workaround of course was to add a symlink from xfree86 -> xorg xkb rules file, however my personal opinion about that, was that if we did that, NONE of the broken applications would EVER get fixed for real, because that meant doing a bit more work and reading Xkb API documentation and doing things the right way. As such, in our OS releases at least, I explicitly deleted the xfree86 -> xorg symlink to force application authors to fix their broken apps and libraries to query the server for the name of the xkb rules file. In order to be fair, I wrote a very small test application which opened a connection to the X server, queried for the rules file name, printed it to stdout, and exited, so that people who didn't have the time to figure out how to do it themselves, could just cut and paste my code and massage it to fit their app/library as seen fit. All of the apps/libs in our OS which hard coded the xkb rules file were patched over time by us to do things "the right way" by using my example code, as I knew the rules filename may very well be changing to "base" eventually, and did not want to relive the hundreds of bug reports again. We still receive occasional bug reports about this, but they're much less infrequent, as it appears upstream projects have fixed most of their broken code out there. As such, changing the rules filename to "base" IMHO is not a problem at all. If this happens, I will do the same thing I did the last time things were renamed, to shake out any other broken applications that were never fixed properly, and I recommend all other distros/vendors do the same thing, to encourage expediant resolution to broken apps/libs. Compat symlinks can always be thrown in as an 11th hour compatibility measure after a full development cycle has punished broken app authors to fix their software. My experience so far is that this "tough love" approach has worked well. "You'll hate me now, but you'll love me later." so to speak.
> In a word - we realize the importance of the compatibility. And we are > trying to be as compatible as we can. But we realize we cannot be 100% > compatible - and since we are not, we are using this 'moment of > breakage' in order to clean up the tree and introduce some logic in > the layouts. I think you guys have done as good a job as can be done, and compatibility seems to be fairly good IMHO. Any temporary growing pains are a coin in the ocean, and well worth it, in particular at a major change from X11R6 to X11R7. Now is the time for any major changes to occur, including anything that might cause temporary inconveniences for a small number of users. Hopefully xkeyboard-config will be incorporated into Xorg CVS head soon. Alternatively, OS vendors can just disable the Xorg supplied broken xkb stuff and replace it with xkeyboard-config separately. If the latter happens though, and nobody ends up shipping the broken stuff that is in the tree right now, it would beg the question why the tree isn't updated to the stuff everyone actually decides to ship. A bit early to speculate that perhaps. It sure would be nice to see this fixed for once and for all though, so we don't need to see the same bug reports reported over and over again. TIA
From lars at trolltech.com Tue Apr 19 00:23:18 2005 From: lars at trolltech.com (Lars Knoll) Date: Tue, 19 Apr 2005 09:23:18 +0200 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]>
From otaylor at redhat.com Tue Apr 19 04:15:44 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 19 Apr 2005 07:15:44 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]>
From mharris at www.linux.org.uk Tue Apr 19 08:32:24 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Tue, 19 Apr 2005 11:32:24 -0400 Subject: Proposed change to xorgcfg In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Kean Johnston wrote: >>This look good to me. Do you already have code? >>I could patch up a test server and try it out.... > > I've got part of it done. I'll work on a test patch for you > and get it to you in teh next day or two. Can you file a bugzilla request for this and attach the patch for review, or even post the patch here so we can have a look? It'd be good to see this continue to be discussed and tweaked until something goes into the tree. It would be a great benefit for autodetection with sane fallback mechanism, which would help distros out a lot. TIA
From michel at daenzer.net Tue Apr 19 09:00:14 2005 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Tue, 19 Apr 2005 12:00:14 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <1113839981.16000.123.camel@localhost> <[email protected]> <1113861616.15945.147.camel@localhost> <[email protected]> Message-ID: <1113926415.15947.176.camel@localhost> On Mon, 2005-18-04 at 18:58 -0400, Owen Taylor wrote: > On Mon, 2005-04-18 at 18:00 -0400, Michel D?nzer wrote: > > > > Just run a compositing manager on Xephyr and make any window > > translucent. As soon as it stops being fully opaque, it becomes > > invisible (except for some small, seemingly random areas, sometimes), > > you only see the shadow behind it. So the global alpha value of the > > window doesn't seem to be handled correctly. > > > > If you can't reproduce it, I can create screenshots tomorrow at work. > > OK, fixed in xserver. Thanks, GNOME with xcompmgr is mostly fixed now, but I still get very bad artifacts with KDE 3.4. The global alpha value of non-opaque windows seems more or less random there now; I can only seem to reproduce a similar effect with GNOME/xcompmgr by moving a translucent window out of the left edge of the screen, so it seems to be related to clipping. On a brighter note, software compositing performance seems comparable to Mac OS X now, looking forward to Altivec optimizations. :)
-- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From jjosburn at hotmail.com Tue Apr 19 09:53:52 2005 From: jjosburn at hotmail.com (james osburn) Date: Tue, 19 Apr 2005 16:53:52 +0000 Subject: how do i use the Xvesa server with xorg? Message-ID:
From sandmann at daimi.au.dk Tue Apr 19 12:01:45 2005 From: sandmann at daimi.au.dk (Soeren Sandmann) Date: 19 Apr 2005 21:01:45 +0200 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]>
From hiryu at audioseek.net Tue Apr 19 15:54:33 2005 From: hiryu at audioseek.net (Cameron) Date: Tue, 19 Apr 2005 15:54:33 -0700 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Bring m video game thingy too (the transparent cartridge). -Cameron On Tuesday April 19 2005 1:58 pm, Alan Cox wrote: > On Maw, 2005-04-19 at 16:01, Owen Taylor wrote: > > Well, no, it's just mildly bad, assuming that you have enough free > > scratch space to copy the pixmap into video ram immediately before > > compositing it... if compositing is just limited by system => video > > bandwidth, that still is pretty good. > > You might be better off tiling for large operations anyway. The loop > then becomes close to maximally efficient when using DMA and DRI to > retrieve tiles from the video ram > > kick DMA off for tile n+1 > Render tile n > polled wait DMA complete n+1 > > overlapping full speed bus transfers with software rendering. > > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
From hiryu at audioseek.net Tue Apr 19 15:55:37 2005 From: hiryu at audioseek.net (Cameron) Date: Tue, 19 Apr 2005 15:55:37 -0700 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Whoops, my apologies. Kmail brought up the wrong message for response. -Cameron On Tuesday April 19 2005 3:54 pm, Cameron wrote: > Bring m video game thingy too (the transparent cartridge). > > -Cameron > > On Tuesday April 19 2005 1:58 pm, Alan Cox wrote: > > On Maw, 2005-04-19 at 16:01, Owen Taylor wrote: > > > Well, no, it's just mildly bad, assuming that you have enough free > > > scratch space to copy the pixmap into video ram immediately before > > > compositing it... if compositing is just limited by system => video > > > bandwidth, that still is pretty good. > > > > You might be better off tiling for large operations anyway. The loop > > then becomes close to maximally efficient when using DMA and DRI to > > retrieve tiles from the video ram > > > > kick DMA off for tile n+1 > > Render tile n > > polled wait DMA complete n+1 > > > > overlapping full speed bus transfers with software rendering. > > > > > > ______> > xorg mailing list > > xorg at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xorg > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From sergio at sergiomb.no-ip.org Tue Apr 19 19:26:45 2005 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 20 Apr 2005 03:26:45 +0100 Subject: ANN: xorg-x11-6.8.99.3.src.rpm for FC3 In-Reply-To: <1113937812.7121.11.camel@bastov> References: <1113937812.7121.11.camel@bastov> Message-ID: <1113964006.10101.13.camel@bastov> Hello, Mike Harris Here is my final spec http://sergiomb.no-ip.org/xorg-x11.spec This time, I try to change the minimum text from your spec file, so my advice is to see the diff between your xorg-x11.spec,v 1.197 and this one. Seems a pretties rpms :) Thanks again, On Tue, 2005-04-19 at 20:10 +0100, Sergio Monteiro Basto wrote: > Hi, > > Well I got xorg-x11-6.8.2-23.src.rpm from FC devel repo > > and begging to make xorg-x11-6.8.99.3-1.rpm > the biggest problem that took me the most of time is reported on > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107383 > > I just need a new patch that goes in attachment for compile xdyinfo > without defining INCLUDE_XPRINT_SUPPORT (seems safe because compiler > says defined but not used) > > thanks, > Now I am trying compile fonts -- S?rgio M.B.
From sergio at sergiomb.no-ip.org Tue Apr 19 19:32:10 2005 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 20 Apr 2005 03:32:10 +0100 Subject: [PATCH] xorg-x11-6.9-xdpyinfo_with_no_xprint_support.diff Message-ID: <1113964330.10101.18.camel@bastov> Hi This patch is need it to compile xdpyinfo with -DNO_XPRINT_SUPPORT in xorg-x11-6.8.99.3 thanks, -- S?rgio M.B. ------next part ------A non-text attachment was scrubbed... Name: xorg-x11-6.9-xdpyinfo_with_no_xprint_support.diff Type: text/x-patch Size: 484 bytes Desc: not available URL:
From ijs at txcorp.com Tue Apr 19 21:38:36 2005 From: ijs at txcorp.com (Irek Szczesniak) Date: Tue, 19 Apr 2005 22:38:36 -0600 (MDT) Subject: how doe build parts of xorg? or rather ... In-Reply-To:
Best, Irek
From list at hoenig.cc Wed Apr 20 00:37:41 2005 From: list at hoenig.cc (Christian Hoenig) Date: Wed, 20 Apr 2005 09:37:41 +0200 Subject: flush xorg image cache? Message-ID: <[email protected]> Hi, [second try, this time with the right adress] I'm working on an image viewer written in Qt. Now having alot of large scale images boosts xorgs memory footprint pretty much. As X caches the images, this is not a problem if it wouldn't be persistent after my program quits. Is there a way to ask xorg to flush its image cache? I thought, I heard of one, but I really cannot remember. thanks! take care, have fun /christian ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
From otaylor at redhat.com Wed Apr 20 07:25:12 2005 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 20 Apr 2005 10:25:12 -0400 Subject: flush xorg image cache? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Wed, 2005-04-20 at 09:37 +0200, Christian Hoenig wrote: > Hi, > > [second try, this time with the right adress] > > I'm working on an image viewer written in Qt. Now having alot of large scale > images boosts xorgs memory footprint pretty much. As X caches the images, > this is not a problem if it wouldn't be persistent after my program quits. > > Is there a way to ask xorg to flush its image cache? I thought, I heard of > one, but I really cannot remember. There is no image cache. (What you probably are seeing is simply that once the server has allocated memory from the operating system, it can't easily return it.) Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From roland.mainz at nrubsig.org Wed Apr 20 09:59:01 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Wed, 20 Apr 2005 18:59:01 +0200 Subject: flush xorg image cache? References: <[email protected]> Message-ID: <[email protected]> Christian Hoenig wrote: > I'm working on an image viewer written in Qt. Now having alot of large scale > images boosts xorgs memory footprint pretty much. As X caches the images, > this is not a problem if it wouldn't be persistent after my program quits. > > Is there a way to ask xorg to flush its image cache? I thought, I heard of > one, but I really cannot remember. AFAIK the Xservers do not have an "image cache". What you may be seeing is the allocation of giant pixmaps in the Xserver code which grow the heap size - and due the implementation of most default memory allocators in unix/linux the heap size cannot shrink[1]. BTW: For the pixmap problem I am working right now on a solution which should enable the Xserver to release memory of large pixmaps (like Solaris/Xsun already does) - that's https://bugs.freedesktop.org/show_bug.cgi?id=3053 ("RFE: Need API (|MapAlloc()|/|MapFree()|) to allocate large memory chunks via |mmap()|"). [1]=On Solaris you can use an alternative memory allocator such as mapmalloc(3malloc), however the Solaris/Xsun Xserver already obtains memory for large pixmaps via |mmap()| so this is not neccesary. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
From Alan.Coopersmith at Sun.COM Wed Apr 20 10:09:42 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Wed, 20 Apr 2005 10:09:42 -0700 Subject: [xkb] Re: xkeyboard-config and modular release In-Reply-To:
From alan at lxorguk.ukuu.org.uk Wed Apr 20 09:33:52 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Wed, 20 Apr 2005 17:33:52 +0100 Subject: flush xorg image cache? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Mer, 2005-04-20 at 17:59, Roland Mainz wrote: > heap size - and due the implementation of most default memory allocators > in unix/linux the heap size cannot shrink[1]. ITYM "In unix" To quote the glibc manual on "Efficiency Considerations for 'malloc'" -- Very large blocks (much larger than a page) are allocated with `mmap' (anonymous or via `/dev/zero') by this implementation. This has the great advantage that these chunks are returned to the system immediately when they are freed. Therefore, it cannot happen that a large chunk becomes "locked" in between smaller ones and even after calling `free' wastes memory. The size threshold for `mmap' to be used can be adjusted with `mallopt'. The use of `mmap' can also be disabled completely. -- So for the Linux case mallopt should be all you need to touch.
Alan
From matthieu.herrb at laas.fr Wed Apr 20 10:46:49 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Wed, 20 Apr 2005 19:46:49 +0200 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Alexander Gottwald wrote: > CVSROOT: /cvs/xorg > Module name: xc > Changes by: ago at gabe.freedesktop.org 05/04/20 09:27:11 > > Log message: > 2005-04-20 Alexander Gottwald
From alexander.gottwald at s1999.tu-chemnitz.de Wed Apr 20 11:03:47 2005 From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald) Date: Wed, 20 Apr 2005 20:03:47 +0200 (MEST) Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID:
From matthieu.herrb at laas.fr Wed Apr 20 15:33:44 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Thu, 21 Apr 2005 00:33:44 +0200 Subject: CVS Update: xc (branch: trunk) In-Reply-To:
From daniel at fooishbar.org Wed Apr 20 15:39:13 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 21 Apr 2005 08:39:13 +1000 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]>
From yuanshengquan at gmail.com Thu Apr 21 01:18:21 2005 From: yuanshengquan at gmail.com (Austin Yuan) Date: Thu, 21 Apr 2005 16:18:21 +0800 Subject: Intel845 IGP and XGetImage In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> I found a thread which addressed the same issue I mentioned in xorg lists. It is "X[Shm]GetImage is slow; what can I do about this? " . Now the problem seems on software memory copy from framebuffer to system memory. I will try shadowfb and compare the result with the normal case. Thanks! Austin Yuan On 4/21/05, Austin Yuan
From yuanshengquan at gmail.com Thu Apr 21 01:52:36 2005 From: yuanshengquan at gmail.com (Austin Yuan) Date: Thu, 21 Apr 2005 16:52:36 +0800 Subject: Intel845 IGP and XGetImage In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On 4/21/05, Austin Yuan
From javier-ml-xorg at marcet.info Thu Apr 21 11:40:19 2005 From: javier-ml-xorg at marcet.info (Javier Marcet) Date: Thu, 21 Apr 2005 20:40:19 +0200 Subject: Xserver/fb not compilable with gcc-4 Message-ID: <[email protected]>
Hi guys, I was compiling xorg 6.8.99.3 with gcc-4 and found a blocker on fbmmx.c At first try I had applied the patches which were included in the 'render optimization' thread. but backing them didn't change anything. The thing is that I really don't understand what the error given by gcc is: making all in programs/Xserver/fb... make[5]: Entering directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc/programs /Xserver/fb' i686-pc-linux-gnu-gcc -c -march=athlon-xp -O2 -pipe -ansi -pedantic -Wno-return- type -w -fPIC -I../../../programs/Xserver/fb -I../../../programs/Xserver/mi -I ../../../programs/Xserver/include -I../../../exports/include/X11 -I../../../include/fonts -I../../../programs/Xserver/hw/xfree86/common -I../../../programs/Xserver/render -I../../../include/extensions -I../../. ./programs/Xserver/Xext -I../../.. -I../../../exports/include -Dlinux -D__i38 6__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN _SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROU P -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPAN ORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUS ESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeX DGA -DXvExtension -DXFree86LOADER -DDLOPEN_HACK -D XFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((99) * 1000) + 3)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -mmmx -W inline --param inline-unit-growth=10000 --param large-function-growth=10 000 -DUSE_MMX fbpict.c rm -f fbmmx.o i686-pc-linux-gnu-gcc -c -march=athlon-xp -O2 -pipe -ansi -pedantic -Wno-return- type -w -fPIC -I../../../programs/Xserver/fb -I../../../programs/Xserver/mi -I ../../../programs/Xserver/include -I../../../exports/include/X11 -I../../../include/fonts -I../../../programs/Xserver/hw/xfree86/common -I../../../programs/Xserver/render -I../../../include/extensions -I../../. ./programs/Xserver/Xext -I../../.. -I../../../exports/include -Dlinux -D__i38 6__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN _SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROU P -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPAN ORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUS ESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeX DGA -DXvExtension -DXFree86LOADER -DDLOPEN_HACK -D XFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((99) * 1000) + 3)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -mmmx -W inline --param inline-unit-growth=10000 --param large-function-growth=10 000 -DUSE_MMX fbmmx.c fbmmx.c: In function 'fbCompositeSolid_nx8888mmx': fbmmx.c:374: error: syntax error before 'CARD32' fbmmx.c: In function 'fbCompositeSolid_nx0565mmx': fbmmx.c:453: error: syntax error before 'CARD16' fbmmx.c: In function 'fbCompositeSolidMask_nx8888x8888Cmmx': fbmmx.c:539: error: syntax error before 'CARD32' fbmmx.c:540: error: syntax error before 'CARD32' fbmmx.c: In function 'fbCompositeSrc_8888x8x8888mmx': fbmmx.c:639: error: syntax error before 'CARD32' fbmmx.c:640: error: syntax error before 'CARD32' fbmmx.c:641: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSrc_x888x8x8888mmx': fbmmx.c:724: error: syntax error before 'CARD32' fbmmx.c:725: error: syntax error before 'CARD32' fbmmx.c:726: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSolidMask_nx8x8888mmx': fbmmx.c:866: error: syntax error before 'CARD32' fbmmx.c:867: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSolidMaskSrc_nx8x8888mmx': fbmmx.c:984: error: syntax error before 'CARD32' fbmmx.c:985: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSolidMask_nx8x0565mmx': fbmmx.c:1098: error: syntax error before 'CARD16' fbmmx.c:1099: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSrc_8888RevNPx0565mmx': fbmmx.c:1218: error: syntax error before 'CARD16' fbmmx.c:1219: error: syntax error before 'CARD32' fbmmx.c: In function 'fbCompositeSrc_8888RevNPx8888mmx': fbmmx.c:1336: error: syntax error before 'CARD32' fbmmx.c:1337: error: syntax error before 'CARD32' fbmmx.c: In function 'fbCompositeSolidMask_nx8888x0565Cmmx': fbmmx.c:1439: error: syntax error before 'CARD16' fbmmx.c:1440: error: syntax error before 'CARD32' fbmmx.c: In function 'fbCompositeSrcAdd_8000x8000mmx': fbmmx.c:1541: error: syntax error before 'CARD8' fbmmx.c:1542: error: syntax error before 'CARD8' fbmmx.c: In function 'fbCompositeSrcAdd_8888x8888mmx': fbmmx.c:1611: error: syntax error before 'CARD32' fbmmx.c:1612: error: syntax error before 'CARD32' make[5]: *** [fbmmx.o] Error 1 make[5]: Leaving directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc/programs/ Xserver/fb' make[4]: *** [fb] Error 2 make[4]: Leaving directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc/programs/ Xserver' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc/programs' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/usr/src/portage/xorg-x11-6.8.99.3/work/xc' make: *** [World] Error 2 !!! ERROR: x11-base/xorg-x11-6.8.99.3 failed. !!! Function build, Line 969, Exitcode 2 !!! make World failed !!! If you need support, post the topmost build error, NOT this status message. I even tried to compile only Xserver/fb with gcc-3.4.3 and I got the same error, hence I guess the error might come from somewhere else rather than fbmmx.c itself... Any help would be appreciated :) P.S. Is there any progress on getting render acceleration in the open source radeon driver? (for older Radeon cards, like 9000/9200 at least)
-- I have not yet begun to byte! Javier Marcet
From andjoh at rydsbo.net Thu Apr 21 11:51:36 2005 From: andjoh at rydsbo.net (Anders Johansson) Date: Thu, 21 Apr 2005 20:51:36 +0200 Subject: Logitech Media Keyboard In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Wednesday 20 April 2005 10:19, Anders Johansson wrote: > On Monday 18 April 2005 05:00, I wrote: > > Hi, > > Anyone? Did I send this to the wrong mailing list? The X.org mailing list > page makes it a little difficult to see which list end user config problems > should be sent to. Could someone at least point me to the correct mailing list? Every mailing list that I thought was a candidate on the x.org list page had mail on it saying 'this list is dead'. So which is correct?
From Alan.Coopersmith at Sun.COM Thu Apr 21 11:54:28 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Thu, 21 Apr 2005 11:54:28 -0700 Subject: Logitech Media Keyboard In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Anders Johansson wrote: > On Wednesday 20 April 2005 10:19, Anders Johansson wrote: > >>On Monday 18 April 2005 05:00, I wrote: >> >>>Hi, >> >>Anyone? Did I send this to the wrong mailing list? The X.org mailing list >>page makes it a little difficult to see which list end user config problems >>should be sent to. > > > Could someone at least point me to the correct mailing list? Every mailing > list that I thought was a candidate on the x.org list page had mail on it > saying 'this list is dead'. So which is correct? This is probably the best list - I'd just guess no one else has seen the problem you're reporting or knows how to fix it. Sorry. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From anderson at netsweng.com Thu Apr 21 12:42:33 2005 From: anderson at netsweng.com (Stuart Anderson) Date: Thu, 21 Apr 2005 15:42:33 -0400 (EDT) Subject: Major contribution to X.Org Foundation by Aptest and Open Group In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID:
Stuart Stuart R. Anderson anderson at netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
From airlied at gmail.com Thu Apr 21 15:13:16 2005 From: airlied at gmail.com (Dave Airlie) Date: Fri, 22 Apr 2005 08:13:16 +1000 Subject: Xserver/fb not compilable with gcc-4 In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> > P.S. Is there any progress on getting render acceleration in the open > source radeon driver? (for older Radeon cards, like 9000/9200 at least) we have some render acceleration, for things like gnome-terminal it works very well.. for composite not so good.. this is due to the XAA, no idea how people plan to merge KAA drivers back into Xorg if at all.. Dave.
From cloos+pdx-xorg at jhcloos.com Thu Apr 21 19:29:45 2005 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Thu, 21 Apr 2005 22:29:45 -0400 Subject: Logitech Media Keyboard In-Reply-To: <[email protected]> (Anders Johansson's message of "Mon, 18 Apr 2005 05:00:55 +0200") References: <[email protected]> Message-ID:
From unichrome at shipmail.org Fri Apr 22 01:44:44 2005 From: unichrome at shipmail.org (Thomas Hellstrom) Date: Fri, 22 Apr 2005 10:44:44 +0200 Subject: The DRI drawable spinlock Message-ID: <[email protected]> Hi! Does anybody have a clear understanding of the drawable spinlock? From my reading of code in the X server and dri_utilities.c it is ment to be used to stop anyone but the context holding the lock to touch the dri drawables in a way that would change their timestamp. The X server has a very inefficient way of checking whether a client died while holding the drawable spinlock. It waits for 10 seconds and then grabs it by force. Also the usage is dri_util.c is beyond my understanding. Basically, to lock and validate drawable info, the following happens: get_heavyweight_lock; while drawable_stamps_mismatch { release_heavyweight_lock; get_drawable_spinlock; //In dri_util.c do_some_minor_processing_that_can_be_done_elsewhere; release_drawable_spinlock; call_X_to_update_drawable_info; get_drawable_spinlock; //In driver. release_drawable_spinlock; } Basically no driver seems to be using it for anything, except possibly the gamma driver, which I figure is outdated anyway? I have found some use for it in XvMC clients: To run the scaling engine to render to a drawable without holding the heavyweight lock for prolonged periods, but I strongly dislike the idea of freezing the X server for 10 secs if the XvMC client accidently dies. Proposed changes: 1). Could we replace the locking value (which now seems to be 1) with the context number | _DRM_LOCK_HELD. In this way the drm can detect when the drawable lock is held by a killed client and release it. 2). Could we replace the drawable_spinlock with a futex-like lock similar to what's used in the via drm to reserve certain chip functions. The purpose would be to sched_yield() if the lock is contended, with an immediate wakeup when the lock is released. This would not be backwards binary compatible with other drivers, but it seems no up-to-date drivers is using this lock anyway. /Thomas
From keith at tungstengraphics.com Fri Apr 22 02:12:30 2005 From: keith at tungstengraphics.com (Keith Whitwell) Date: Fri, 22 Apr 2005 10:12:30 +0100 Subject: The DRI drawable spinlock In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> It's a horrible hack, basically. I used to understand it but now no longer want to. I think the original DRI documentation will have some information on it. I think the original motiviation was for the gamma (and actually lots of subsequent drivers), you end up encoding the window position and cliprects in the command stream. And this lock somehow protected those command streams from being submitted to hardware with out-of-date window positions. In fact if you go right back, the DRM supported multiple software command stream where commands from the X server could be prioritized ahead of commands from 3d clients, so you could get the window-move blits being submitted to hardware ahead of 3d drawing commands to the old window position. This created all sorts of amazing problems which have subsequently been avoided by simply submitting all commands to hardware in the order they are generated. Right now, no driver uses the spinlock directly or explicitly, but they all use it when requesting their cliprects from the X server. So basically the sequence goes: Client gets dri lock Client sees timestamp changed Client wants to talk to the X server to get new cliprects, but because client is holding the lock, the X server is unable to respond to the client. So the client needs to release the lock to let the X server reply. --> But! (some set of circumstances might apply here), so there' s a need for this funny other lock, that the client grabs before it releases the main dri lock, to stop the cliprects getting changed again in the meantime. I don't see why you couldn't just do something like get lock while (timestamp mismatch) { release lock request new cliprects and timestamp get lock } Note that is the contended case only. What's the worst that could happen - somebody's wizzing windows around and our 3d client sits in this loop for the duration. Note that the loop includes X server communication so it's not going to suck up the cpu or anything drastic. In some respects it's like the code in the radeon DDX driver which uses a software path to perform depth buffer copying on window moves - well intentioned perhaps, but not actually useful or desirable. Keith Thomas Hellstrom wrote: > Hi! > > Does anybody have a clear understanding of the drawable spinlock? > > From my reading of code in the X server and dri_utilities.c it is ment > to be used to stop anyone but the context holding the lock to touch the > dri drawables in a way that would change their timestamp. > > The X server has a very inefficient way of checking whether a client > died while holding the drawable spinlock. It waits for 10 seconds and > then grabs it by force. > > Also the usage is dri_util.c is beyond my understanding. Basically, to > lock and validate drawable info, the following happens: > > get_heavyweight_lock; > > while drawable_stamps_mismatch { > release_heavyweight_lock; > get_drawable_spinlock; > //In dri_util.c > do_some_minor_processing_that_can_be_done_elsewhere; > release_drawable_spinlock; > call_X_to_update_drawable_info; > get_drawable_spinlock; > //In driver. > release_drawable_spinlock; > } > > Basically no driver seems to be using it for anything, except possibly > the gamma driver, which I figure is outdated anyway? > > I have found some use for it in XvMC clients: To run the scaling engine > to render to a drawable without holding the heavyweight lock for > prolonged periods, but I strongly dislike the idea of freezing the X > server for 10 secs if the XvMC client accidently dies. > > Proposed changes: > > 1). Could we replace the locking value (which now seems to be 1) with > the context number | _DRM_LOCK_HELD. In this way the drm can detect when > the drawable lock is held by a killed client and release it. > > 2). Could we replace the drawable_spinlock with a futex-like lock > similar to what's used in the via drm to reserve certain chip functions. > The purpose would be to sched_yield() if the lock is contended, with an > immediate wakeup when the lock is released. This would not be backwards > binary compatible with other drivers, but it seems no up-to-date drivers > is using this lock anyway. > > /Thomas > > > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg >
From keith at tungstengraphics.com Fri Apr 22 03:51:21 2005 From: keith at tungstengraphics.com (Keith Whitwell) Date: Fri, 22 Apr 2005 11:51:21 +0100 Subject: The DRI drawable spinlock In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Thomas Hellstrom wrote: > Hi! > > Does anybody have a clear understanding of the drawable spinlock? > > From my reading of code in the X server and dri_utilities.c it is ment > to be used to stop anyone but the context holding the lock to touch the > dri drawables in a way that would change their timestamp. > > The X server has a very inefficient way of checking whether a client > died while holding the drawable spinlock. It waits for 10 seconds and > then grabs it by force. > > Also the usage is dri_util.c is beyond my understanding. Basically, to > lock and validate drawable info, the following happens: > > get_heavyweight_lock; > > while drawable_stamps_mismatch { > release_heavyweight_lock; > get_drawable_spinlock; > //In dri_util.c > do_some_minor_processing_that_can_be_done_elsewhere; > release_drawable_spinlock; > call_X_to_update_drawable_info; > get_drawable_spinlock; > //In driver. > release_drawable_spinlock; > } > > Basically no driver seems to be using it for anything, except possibly > the gamma driver, which I figure is outdated anyway? > > I have found some use for it in XvMC clients: To run the scaling engine > to render to a drawable without holding the heavyweight lock for > prolonged periods, but I strongly dislike the idea of freezing the X > server for 10 secs if the XvMC client accidently dies. > > Proposed changes: > > 1). Could we replace the locking value (which now seems to be 1) with > the context number | _DRM_LOCK_HELD. In this way the drm can detect when > the drawable lock is held by a killed client and release it. This seems like a reasonable thing to do now. Note that the X server could also be the one responsible for freeing the lock, which might be cleaner if the DRM is currenly unaware of this beast. > 2). Could we replace the drawable_spinlock with a futex-like lock > similar to what's used in the via drm to reserve certain chip functions. > The purpose would be to sched_yield() if the lock is contended, with an > immediate wakeup when the lock is released. This would not be backwards > binary compatible with other drivers, but it seems no up-to-date drivers > is using this lock anyway. Maybe this is something to put off to be part of Ian's forthcoming binary-compatibility breakages for X.org 6.7? Keith
From mhopf at suse.de Fri Apr 22 09:52:37 2005 From: mhopf at suse.de (Matthias Hopf) Date: Fri, 22 Apr 2005 18:52:37 +0200 Subject: Compose table cache for faster X11 application starts Message-ID: <[email protected]> Hi all, as talked about on the Xorg developer conference, I implemented a compose cache mechanism for XIM, based on the early implementation by Lubos Lunak (llunak at suse.de). We should still think about replacing XIM in the long term, but these patches help for application startups in the short term. All information and all patches have been uploaded to a bugzilla entry: https://bugs.freedesktop.org/show_bug.cgi?id=3104
The compose cache accelerates program startup times and memory consumption considerably, especially for UTF8 locales. If a cache file is found during the startup of an application, the according cache is mmap()ed. Speedup is approx. 40-200ms decreased startup time for every X application, depending on your processor. Approx. 240KB memory is saved per application. This is for UTF8 locales, differences are much lower for non-UTF8 locales, as well as for home-grown compose tables. The patches also implement a small (single entry) cache to _XlcLocaleDirName to deal with repeated calls. Cache files are searched in a global cache dir (read-only) and in the .compose-cache diretory of the user's home. If this directory does not exist, it is *not* created, effectively disabling the possibility of creating cache files. The whole thing consists of three patches, one for flattening out the internal database, one for the cache, and one for a helper program. The patches have been applied within SuSE Linux 9.3 (already shipping), and global cache files are shipped for all UTF8 locales as well. So far no problems.
I'd like to see a discussion whether this can be included upstream, and what you gyus basically think about the patches.
Thanks Matthias -- Matthias Hopf
From Jim.Gettys at hp.com Fri Apr 22 09:53:35 2005 From: Jim.Gettys at hp.com (Jim Gettys) Date: Fri, 22 Apr 2005 12:53:35 -0400 Subject: [Bug 3104] New: Compose table cache for faster X11 application starts In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Great stuff! Given the number of applications that get started up these days in a modern Linux desktop, (and the fact that other egregious delays in booting are in the process of getting fixed in Linux), this is a worthwhile enhancement indeed, which will cut off seconds of startup time in all probability... I'm posting this to the general list to make sure the work gets the exposure it deserves. Regards, - Jim Gettys
On Fri, 2005-04-22 at 09:35 -0700, bugzilla-daemon at freedesktop.org wrote: > Please do not reply to this email: if you want to comment on the bug, go to
> > the URL shown below and enter yourcomments there. > > https://bugs.freedesktop.org/show_bug.cgi?id=3104 > > Summary: Compose table cache for faster X11 application starts > Product: xlibs > Version: unspecified > Platform: All > OS/Version: All > Status: NEW > Keywords: l10n > Severity: enhancement > Priority: P2 > Component: libX11 > AssignedTo: jim.gettys at hp.com > ReportedBy: mhopf at suse.de > CC: eich at pdx.freedesktop.org,sndirsch at suse.de > > > As talked about on the Xorg developer conference, I implemented a compose > cache mechanism for XIM, based on the early implementation by Lubos Lunak > (llunak at suse.de). We should still think about replacing XIM in the long > term, but these patches help for application startups in the short term. > > The compose cache accelerates program startup times and memory consumption > considerably, especially for UTF8 locales. If a cache file is found during > the startup of an application, the according cache is mmap()ed. > > Speedup is approx. 40-200ms decreased startup time for every X application, > depending on your processor. Approx. 240KB memory is saved per application. > This is for UTF8 locales, differences are much lower for non-UTF8 locales, > as well as for home-grown compose tables. > > The patches also implement a small (single entry) cache to _XlcLocaleDirName > to deal with repeated calls. > > Cache files are searched in a global cache dir (read-only) and in the > .compose-cache diretory of the user's home. If this directory does not > exist, it is *not* created, effectively disabling the possibility of > creating cache files. > > The whole thing consists of three patches, one for flattening out the > internal database, one for the cache, and one for a helper program. > > The patches have been applied with SuSE Linux 9.3 (already shipping), and > global cache files are shipped for all UTF8 locales as well. > No problems so far. > > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> > ------You are receiving this mail because: ------> You are the assignee for the bug, or are watching the assignee.
From ajax at nwnk.net Fri Apr 22 13:53:25 2005 From: ajax at nwnk.net (Adam Jackson) Date: Fri, 22 Apr 2005 16:53:25 -0400 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Thursday 21 April 2005 17:30, Thomas Winischhofer wrote: > Revision Changes Path > 1.10 xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h Anyone know why the +/- counter on changes stopped working? - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
> > Anyone know why the +/- counter on changes stopped working? Because cvs 1.12.12 (a security release) broke the log info format. In a security release. Again. ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:
From alan at lxorguk.ukuu.org.uk Sat Apr 23 02:54:47 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Sat, 23 Apr 2005 10:54:47 +0100 Subject: pkgconfig license In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Sad, 2005-04-23 at 08:10, Matthieu Herrb wrote: > Hi, > > Reading http://wiki.x.org/wiki/ModularDevelopersGuide I see that > pkgconfig is required to build the modular tree, not only for developpers. > This conflicts with the goal that X.Org should be buildable on OpenBSD's > (or NetBSD's) base system which doesn't include pkgconfig (and never > will as long as its license is the GPL).
What compiler are you using to build X on NetBSD ?
From reed at reedmedia.net Sat Apr 23 07:22:44 2005 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sat, 23 Apr 2005 07:22:44 -0700 (PDT) Subject: pkgconfig license In-Reply-To: <[email protected]> Message-ID:
From ajax at nwnk.net Sat Apr 23 08:46:54 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sat, 23 Apr 2005 11:46:54 -0400 Subject: pkgconfig license In-Reply-To:
From ttb at tentacle.dhs.org Sat Apr 23 08:52:38 2005 From: ttb at tentacle.dhs.org (John McCutchan) Date: Sat, 23 Apr 2005 11:52:38 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From otaylor at redhat.com Sat Apr 23 10:08:40 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 23 Apr 2005 13:08:40 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From reed at reedmedia.net Sat Apr 23 13:18:23 2005 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sat, 23 Apr 2005 13:18:23 -0700 (PDT) Subject: pkgconfig license In-Reply-To: <[email protected]> Message-ID:
From matthieu.herrb at laas.fr Sat Apr 23 13:28:57 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sat, 23 Apr 2005 22:28:57 +0200 Subject: pkgconfig license In-Reply-To: <1114276120.6910.10.camel@huygens> References:
From otaylor at redhat.com Sat Apr 23 14:00:48 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 23 Apr 2005 17:00:48 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
error 9 request 157 minor 4 serial 3557
I get several (~10) lines similar to that but the last number is always different.
I have not been able to find out what this means or how to resolve the problem (if this error message does mean that there is a problem).
I appreciate any suggestions
From roland.mainz at nrubsig.org Sat Apr 23 15:38:52 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 24 Apr 2005 00:38:52 +0200 Subject: Commit to dix/main.c broke the Xprint server / was: [Fwd: CVS Update: xc (branch: trunk)] Message-ID: <[email protected]>
Hi! ---- That checkin broke the Xprint server... ;-( (it would be nice if such commits would have a bug id and an attachment that it can be commented there...). ------Original Message ------Subject: CVS Update: xc (branch: trunk) Date: Wed, 20 Apr 2005 05:49:46 -0700 (PDT) From: Daniel Stone
Revision Changes Path 1.881 +3 -1 xc/ChangeLog 1.8 +7 -1 xc/programs/Xserver/dix/main.c ______xorg-commit mailing list xorg-commit at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-commit
From roland.mainz at nrubsig.org Sat Apr 23 16:04:01 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 24 Apr 2005 01:04:01 +0200 Subject: Commit to dix/main.c broke the Xprint server / was: [Fwd: CVSUpdate: xc (branch: trunk)] References: <[email protected]> Message-ID: <[email protected]> Roland Mainz wrote: > That checkin broke the Xprint server... ;-( > (it would be nice if such commits would have a bug id and an attachment > that it can be commented there...). > > ------Original Message ------> Subject: CVS Update: xc (branch: trunk) > Date: Wed, 20 Apr 2005 05:49:46 -0700 (PDT) > From: Daniel Stone
From roland.mainz at nrubsig.org Sat Apr 23 16:33:38 2005 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun, 24 Apr 2005 01:33:38 +0200 Subject: flush xorg image cache? References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Alan Cox wrote: > > On Mer, 2005-04-20 at 17:59, Roland Mainz wrote: > > heap size - and due the implementation of most default memory allocators > > in unix/linux the heap size cannot shrink[1]. > > ITYM "In unix" > > To quote the glibc manual on "Efficiency Considerations for 'malloc'" > > -- > Very large blocks (much larger than a page) are allocated with > `mmap' (anonymous or via `/dev/zero') by this implementation. This has > the great advantage that these chunks are returned to the system > immediately when they are freed. Therefore, it cannot happen that a > large chunk becomes "locked" in between smaller ones and even after > calling `free' wastes memory. The size threshold for `mmap' to be used > can be adjusted with `mallopt'. The use of `mmap' can also be disabled > completely. > -- > > So for the Linux case mallopt should be all you need to touch. That's for Linux/glibc but not for all the other OSes. Additionally only relatively long-living memory such as pixmaps should be allocated using |mmap()| as this always results in a syscall (AFAIK Jim Gettys said some while ago that the Xserver code is a good exercise in avoiding syscalls... :) and may require some additional adjustments (for example I'd like to force the usage of large pages (64K, 512K, 4M) for pixmap memory to save some entries in the TLB). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
From matthieu.herrb at laas.fr Sun Apr 24 07:20:56 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sun, 24 Apr 2005 16:20:56 +0200 Subject: remove reconfig ? Message-ID: <[email protected]> Any objections against removing hw/xfree86/reconfig ? It was a program to convert XFree86 2.x configuration files to the XFree86 3.x format. -- Matthieu Herrb
From listener at wernig.net Sun Apr 24 09:58:25 2005 From: listener at wernig.net (Markus Wernig) Date: Sun, 24 Apr 2005 18:58:25 +0200 Subject: Palmax PD1100 - palmax_drv input Message-ID: <[email protected]> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! I've got a Palmax PD1100 with the Cyrix MediaGX (Kaluha) "all in one" chip (cpu, graphics, sound). And, it's got a touchscreen that ought to be supported by the "palmax" input driver. It's running Gentoo (kernel 2.6.11.7) and X.org 6.8.2. The palmax input driver doesn't work (correctly) under X ;-) The Tap-Button on the lid does work. But as soon as I touch the screen with the stylus, the cursor jumps to the top left corner and doesn't move any further. I've attached a usb imps/2 mouse, and had no problems with it. Now, as I do get a reaction out of the cursor, but not the expected one, I suppose the problem is the calibration. For starting, I used the calibration values from a XF86Config, that I had used in an earlier install some years ago with Xfree86 3.3 or so (had worked then). But at that time, there had been a module called "xf86Palmax.so" that I could load, which isn't there anymore. Has it been replaced by the palmax_drv.so? When (blindly) changing the values (MaxX, MaxY, MinX, MinX), I sometimes get a different behaviour (and sometimes even some movement). Now: Would anybody have a hint as to where I could get the calibration values from? I remembered a binary called xcalib that would do that for me in the old installation, but now it just reports "No Palmax Touchscreen Extension found !!!"
Here's the relevant sniplet from xorg.conf: [...] Section "InputDevice" ~ Driver "palmax" ~ Identifier "Palmax" ~ Option "Device" "/dev/ttyS0" # Those values taken from "xf86Palmax.c" ~ Option "MinX" "8786" ~ Option "MinY" "7608" ~ Option "MaxX" "63104" ~ Option "MaxY" "61592" ~ Option "BaudRate" "9600" ~ Option "Screen" "0" ~ Option "DeviceName" "Palmax Touchscreen" ~ Option "PortraitMode" "Landscape" ~ Option "SwapXY" "0" ~ Option "TapButton" "1" ~ Option "SendCoreEvents" EndSection [...] Grateful for any pointers /markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCa9Aw8BX/d8pVi/cRAk9OAKCwPU6fkh0ZaV5jB34iBVVzux/znACeLxOc rHEDu6Db5MsR6VjnYXt9Rwo= =LPij -----END PGP SIGNATURE-----
From matthieu.herrb at laas.fr Sun Apr 24 11:41:47 2005 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sun, 24 Apr 2005 20:41:47 +0200 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From ajax at nwnk.net Sun Apr 24 11:48:51 2005 From: ajax at nwnk.net (Adam Jackson) Date: Sun, 24 Apr 2005 14:48:51 -0400 Subject: Turning the cursor off In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Sunday 24 April 2005 14:45, H?kan Persson wrote: > Hi! > > How can I, either through some shell script command or through > configuration files, turn off the cursor or maybe move it off the screen > (I have X version 6.8.2)? > > I am running Firefox as an information screen and I have no user input > so the pointer is unnecessary (irritating!). http://lists.freedesktop.org/pipermail/xorg/2005-January/005596.html - ajax ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
I've seen this question earlier on this list.. Google found this for me: http://lists.freedesktop.org/pipermail/xorg/2005-January/005596.html It's a transparent cursor theme that should do the job for you! /J?rgen -- J?rgen Lidholm
From listener at wernig.net Sun Apr 24 16:44:24 2005 From: listener at wernig.net (Markus Wernig) Date: Mon, 25 Apr 2005 01:44:24 +0200 Subject: Palmax PD1100 - palmax_drv input In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: |> Make sure you have | the right serial port and baud rate firstly. cat /dev/ttyS0 creates output on the console when touching the screen, so I suppose it's ok. hmm, right baud rate... 9600 gives the behaviour I described, 4800 has the cursor switch between 4 fixed positions (corners of a rectangle) on the screen, and 2400 makes it go to the bottom right instead of top left, where it will stay forever (in addition, any stylus movement seems to generate a "left-click" event). 19200 results in no reaction at all. ?/m -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCbC9Y8BX/d8pVi/cRAkbBAJ0S7WJIZyoklBEetrSX/PAP/6hhgwCfTVvY V1pIYL79tjo92OjvrpNgAuU= =7KuU -----END PGP SIGNATURE-----
From mharris at www.linux.org.uk Sun Apr 24 18:38:09 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sun, 24 Apr 2005 21:38:09 -0400 Subject: remove reconfig ? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Matthieu Herrb wrote: > Any objections against removing hw/xfree86/reconfig ? > It was a program to convert XFree86 2.x configuration files to the > XFree86 3.x format. Seems like something worth frying nowadays.
From keithp at keithp.com Sun Apr 24 20:11:17 2005 From: keithp at keithp.com (Keith Packard) Date: Sun, 24 Apr 2005 20:11:17 -0700 Subject: flush xorg image cache? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> XFree86 tried a custom allocator for 4.0 and found that it was a disaster in some common, but unexpected cases. I suggest we leave the business of memory allocation to the C library implementors, who have proven far better at this than X developers in the last twenty years. This is not to discourage people from playing with malopt to see whether we can get more stuff returned to the kernel in some situations, but please limit such stuff in the default implementation. -keith ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From alan at lxorguk.ukuu.org.uk Mon Apr 25 03:56:23 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Mon, 25 Apr 2005 11:56:23 +0100 Subject: flush xorg image cache? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> > That's for Linux/glibc but not for all the other OSes. Additionally only As I said "I think you mean in Unix" > relatively long-living memory such as pixmaps should be allocated using > |mmap()| as this always results in a syscall (AFAIK Jim Gettys said some > while ago that the Xserver code is a good exercise in avoiding > syscalls... :) and may require some additional adjustments (for example > I'd like to force the usage of large pages (64K, 512K, 4M) for pixmap > memory to save some entries in the TLB). No commonly used processor has variable sized TLB entries. The x86 has minimal support for 2 and 4Mb pages but they are not really general purpose. As for tuning and syscalls you must remember that system performance is at least as important as app performance. Alan
From alan at lxorguk.ukuu.org.uk Mon Apr 25 06:31:00 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Mon, 25 Apr 2005 14:31:00 +0100 Subject: Palmax PD1100 - palmax_drv input In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> I can send you the data sheet if you want to debug it (at least I think I still have the PDF for the touchscreen interface). Alan
From listener at wernig.net Mon Apr 25 07:59:23 2005 From: listener at wernig.net (Markus Wernig) Date: Mon, 25 Apr 2005 16:59:23 +0200 Subject: Palmax PD1100 - palmax_drv input In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: > I can send you the data sheet if you want to debug it (at least I think > I still have the PDF for the touchscreen interface). Brrrr .... and I hoped you would do that for me ... ;-) But I realize that this is probably just one out of ten pd1100 left, so your time is definitely better spent elsewhere. OK, if you can find the specs, I will try to make something out of it. thank you /markus ps: and another big THANK YOU and thumbs up for all your work and committment to free software!
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCbQXL8BX/d8pVi/cRAiSGAJsFtfjT8Ioxlc1V3Br6GcXvKja4EgCgvOC8 w67rrFFxdsgj0GiqFw3p2IA= =oC2E -----END PGP SIGNATURE-----
From ajax at nwnk.net Mon Apr 25 08:30:18 2005 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 25 Apr 2005 11:30:18 -0400 Subject: CVS Update: xc (branch: trunk) In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Monday 25 April 2005 09:41, you wrote: > CVSROOT: /cvs/xorg > Module name: xc > Changes by: ago at gabe.freedesktop.org 05/04/25 06:41:20 > > Log message: > 2005-04-25 Alexander Gottwald
From kim at schulz.dk Mon Apr 25 13:18:55 2005 From: kim at schulz.dk (Kim Schulz) Date: Mon, 25 Apr 2005 22:18:55 +0200 Subject: i915 and some more research Message-ID: <[email protected]> Hi again. I have recently been playing around with the 855resolution tool on my laptop with i915 chipset. I noticed that this tool recognizes more resolutions reported by the bios that xorg does. This is what 855resolution gives me: Chipset: 915GM VBIOS type: 2 VBIOS Version: 3412 Mode 30 : 640x480, 8 bits/pixel Mode 32 : 800x600, 8 bits/pixel Mode 34 : 1024x768, 8 bits/pixel Mode 38 : 1280x1024, 8 bits/pixel Mode 3a : 1600x1200, 8 bits/pixel Mode 3c : 1920x1440, 8 bits/pixel Mode 41 : 640x480, 16 bits/pixel Mode 43 : 800x600, 16 bits/pixel Mode 45 : 1024x768, 16 bits/pixel Mode 49 : 1280x1024, 16 bits/pixel Mode 4b : 1600x1200, 16 bits/pixel Mode 4d : 1920x1440, 16 bits/pixel Mode 50 : 640x480, 32 bits/pixel Mode 52 : 800x600, 32 bits/pixel Mode 54 : 1024x768, 32 bits/pixel Mode 58 : 1280x1024, 32 bits/pixel Mode 5a : 1600x1200, 32 bits/pixel Mode 5c : 1920x1440, 32 bits/pixel and this is what xorg gives me: www.cs.aau.dk/~kim/Xorg.0.log As you can see, the mode names are the same. Also notice that the Xorg log says this: (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000
I was wondering if it is actually a problem with the way xorg reads out the bios and not the actual bios that has a problem. or am i totally wrong here?
-- Kim Schulz | Fundanemt Content Management system: Geek by nature | http://www.fundanemt.com schulz.dk | http://www.fundausers.org
From alanh at fairlite.demon.co.uk Mon Apr 25 13:32:29 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 25 Apr 2005 21:32:29 +0100 Subject: i915 and some more research In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Mon, Apr 25, 2005 at 10:18:55PM +0200, Kim Schulz wrote: > Hi again. > I have recently been playing around with the 855resolution tool on my > laptop with i915 chipset. > I noticed that this tool recognizes more resolutions reported by the > bios that xorg does. > > This is what 855resolution gives me: > > Chipset: 915GM > VBIOS type: 2 > VBIOS Version: 3412 > > Mode 30 : 640x480, 8 bits/pixel > Mode 32 : 800x600, 8 bits/pixel > Mode 34 : 1024x768, 8 bits/pixel > Mode 38 : 1280x1024, 8 bits/pixel > Mode 3a : 1600x1200, 8 bits/pixel > Mode 3c : 1920x1440, 8 bits/pixel > Mode 41 : 640x480, 16 bits/pixel > Mode 43 : 800x600, 16 bits/pixel > Mode 45 : 1024x768, 16 bits/pixel > Mode 49 : 1280x1024, 16 bits/pixel > Mode 4b : 1600x1200, 16 bits/pixel > Mode 4d : 1920x1440, 16 bits/pixel > Mode 50 : 640x480, 32 bits/pixel > Mode 52 : 800x600, 32 bits/pixel > Mode 54 : 1024x768, 32 bits/pixel > Mode 58 : 1280x1024, 32 bits/pixel > Mode 5a : 1600x1200, 32 bits/pixel > Mode 5c : 1920x1440, 32 bits/pixel > > > and this is what xorg gives me: > www.cs.aau.dk/~kim/Xorg.0.log This is because the tool goes poking in the BIOS, rather than actually making a BIOS call for valid modes. Now, the BIOS intelligently removes modes that are incapable of being displayed on the LCD. So, in your case, 1920x1440 cannot be displayed on your LCD and the BIOS removes the mode from it's pool. Same for 1600x1200 as your panel is only 1680x1050. Alan.
From zrusin at trolltech.com Mon Apr 25 17:04:58 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Mon, 25 Apr 2005 20:04:58 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Friday 15 April 2005 20:14, Adam Jackson wrote: > This fails rendercheck (from /cvs/xapps) for a few transformations > and for the component alpha case. I don't know whether that's a bug > in your code or in rendercheck but we should verify it. Today Lars fixed rendercheck. The new implementation is passing both on xserver and Xorg so I think we're ready to commit it :) Xserver patch is here: http://ktown.kde.org/~zrusin/xserver_new_render.diff Xorg patch at: http://ktown.kde.org/~zrusin/xorg_new_render.diff Owen, could you double checked that I didn't goofed when merging your mmx changes? Also, the plan for the near future (meaning this and next week) is adding max-burst loading from fb using Altivec/SSE (i have that one more less finished using gcc intrisics) and adding some dri hooks to get dma transfers working. After that I'm going to start working on acceleration architecture but we can discuss that once the above is in cvs. Zack -- Despite the rising cost of living, it remains a popular activity.
From zrusin at trolltech.com Mon Apr 25 17:09:19 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Mon, 25 Apr 2005 20:09:19 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From andre.maute at gmx.de Tue Apr 26 02:36:00 2005 From: andre.maute at gmx.de (andre maute) Date: Tue, 26 Apr 2005 11:36:00 +0200 Subject: pkgconfig license Message-ID: <[email protected]> I want to mention that the pkg-config reimplementation does not depend on the glib library, which is in my opinion a very nice side effect. Regards Andre
From alan at lxorguk.ukuu.org.uk Tue Apr 26 01:45:07 2005 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 26 Apr 2005 09:45:07 +0100 Subject: Palmax PD1100 - palmax_drv input In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Llu, 2005-04-25 at 15:59, Markus Wernig wrote: > But I realize that this is probably just one out of ten pd1100 left, > so your time is definitely better spent elsewhere. And mine is mostly defunct
The protocol is 0xFF [padding] Then either 0xFE A B or 0xFF A B C D C/D are the high bits of a 14 bit value and need not be sent if they didnt change at all. C/D cannot be 0xFE/FF but A/B can, which can mean it takes a few samples to sync. X low is A Y low is B Xhigh is C Yhigh is D All this should be at 19200 8N1 Alan
From otaylor at redhat.com Tue Apr 26 04:30:01 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 26 Apr 2005 07:30:01 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1114515002.29859.40.camel@huygens> On Tue, 2005-04-26 at 11:36 +0200, andre maute wrote: > I want to mention that the pkg-config reimplementation does not depend > on the glib library, which is in my opinion a very nice side effect. Though pkg-config doesn't depend on glib either ... it has an internal copy statically linked in. (Except on Windows, which I doubt is the point here.) Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From kem at freedesktop.org Tue Apr 26 07:15:04 2005 From: kem at freedesktop.org (Kevin E Martin) Date: Tue, 26 Apr 2005 10:15:04 -0400 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From ephracis at linux.se Tue Apr 26 07:17:32 2005 From: ephracis at linux.se (Christoffer Brodd-Reijer) Date: Tue, 26 Apr 2005 16:17:32 +0200 Subject: projectroot makes ld not work Message-ID: <[email protected]> I want to compile the CVS of xorg and not install it over my existing xorg. So I read the CVS page on the xorg wiki. My intentions are to install DRI and DRM for my VIA video card (following a guide at http://dri.freedesktop.org/wiki/Building, but this one installs over the existing xorg). So I fetched the cvs and the host.def from http://freedesktop.org/~fxkuehl/host.def. Now I added #define ProjectRoot and NothingOutsideProjectRoot, so I could install this new xorg at some location and then just make a symlink. When I tried to compile I got this error: making all in lib/Xxf86vm... make[4]: Entering directory `/home/mezzymeat/packages/unichrome/build/xc/lib/Xxf86vm' rm -f XF86VMode.o gcc -m32 -c -O2 -gstabs+ -pipe -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../.. -I../../exports/include -I/home/mezzymeat/program/xorg/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL -fPIC XF86VMode.c rm -f libXxf86vm.so.1.0~ + cd . + gcc -m32 -o ./libXxf86vm.so.1.0~ -shared -Wl,-soname,libXxf86vm.so.1 XF86VMode.o -L../../exports/lib -L/home/mezzymeat/program/xorg/lib -lXext -lX11 -lc /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../../i486-slackware-linux/bin /ld: cannot find -lXext collect2: ld returned 1 exit status make[4]: *** [libXxf86vm.so.1.0] Error 1 make[4]: Leaving directory `/home/mezzymeat/packages/unichrome/build/xc/lib/Xxf86vm' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/mezzymeat/packages/unichrome/build/xc/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/mezzymeat/packages/unichrome/build/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/home/mezzymeat/packages/unichrome/build/xc' make: *** [World] Error 2 What am I doing wrong?
From anderson at netsweng.com Tue Apr 26 07:37:49 2005 From: anderson at netsweng.com (Stuart Anderson) Date: Tue, 26 Apr 2005 10:37:49 -0400 (EDT) Subject: projectroot makes ld not work In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
When using projectroot, I think you will need to do a full build of the tree, instead of a minimal build as is configured ni the host.def you referenced. Try removing these lines to get more of the tree to build: #define BuildLibraries NO #define BuildLibrariesForXServers NO #define BuildLibrariesForConfigTools NO Another way would be to figure out how to pass -L/usr/X11R6/lib into the build so it will pick up some of the libraries from you system. On Tue, 26 Apr 2005, Christoffer Brodd-Reijer wrote: > I want to compile the CVS of xorg and not install it over my existing xorg. > So I read the CVS page on the xorg wiki. My intentions are to install DRI and > DRM for my VIA video card (following a guide at > http://dri.freedesktop.org/wiki/Building, but this one installs over the > existing xorg). So I fetched the cvs and the host.def from > http://freedesktop.org/~fxkuehl/host.def. Now I added #define ProjectRoot and > NothingOutsideProjectRoot, so I could install this new xorg at some location > and then just make a symlink. > > What am I doing wrong?
Stuart Stuart R. Anderson anderson at netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
From ephracis at linux.se Tue Apr 26 07:54:39 2005 From: ephracis at linux.se (Christoffer Brodd-Reijer) Date: Tue, 26 Apr 2005 16:54:39 +0200 Subject: projectroot makes ld not work Message-ID: <[email protected]> Stuart Anderson wrote: > > Another way would be to figure out how to pass -L/usr/X11R6/lib into the > build so it will pick up some of the libraries from you system. > Since I am not too good at this I am not able to figure that out by myself. How should I do it?
From ephracis at linux.se Tue Apr 26 08:21:04 2005 From: ephracis at linux.se (Christoffer Brodd-Reijer) Date: Tue, 26 Apr 2005 17:21:04 +0200 Subject: projectroot makes ld not work In-Reply-To:
From zrusin at trolltech.com Tue Apr 26 08:42:55 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Tue, 26 Apr 2005 11:42:55 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Tuesday 26 April 2005 09:08, Diego Calleja wrote: > It doesn't seems to apply 100%. Or I did something wrong? You did something wrong. Of course I can't tell you what because I don't know what was rejected. My guess is that you have some cruft in the fbcompose.c. Do cvs update -PdCA and apply again. Zack -- job Placement, n.: Telling your boss what he can do with your job.
From diegocglinux at yahoo.es Tue Apr 26 09:11:39 2005 From: diegocglinux at yahoo.es (Diego Calleja) Date: Tue, 26 Apr 2005 18:11:39 +0200 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> El Tue, 26 Apr 2005 11:42:55 -0400, Zack Rusin
That didn't work....but rm -rf programs/Xserver/fb did. IOW, CVS sucks - not big news ;) Thanks!
From otaylor at redhat.com Tue Apr 26 09:30:41 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 26 Apr 2005 12:30:41 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <1114533041.11262.4.camel@huygens> On Tue, 2005-04-26 at 11:42 -0400, Zack Rusin wrote: > On Tuesday 26 April 2005 09:08, Diego Calleja wrote: > > It doesn't seems to apply 100%. Or I did something wrong? > > You did something wrong. Of course I can't tell you what because I don't > know what was rejected. My guess is that you have some cruft in the > fbcompose.c. Do cvs update -PdCA and apply again. I get the same reject ... it's harmless though ... just the CVS ID conflicting in the change to the copyright. It looks like you made the xorg diff against an older version of fbcompose.c. Hmm, looking at the rejected diff, shouldn't: * Copyright ? 2000 Keith Packard, member of The XFree86 Project, Inc. + * 2005 Lars Knoll & Zack Rusin, Trolltech
Be: Copyright 2005 Trolltech Authors: Lars Knoll & Zack Rusin Or something like that? presumably the copyright holder is Trolltech not you personally. Regards, Owen
------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From fxkuehl at gmx.de Tue Apr 26 13:44:50 2005 From: fxkuehl at gmx.de (Felix =?ISO-8859-1?Q?K=FChling?=) Date: Tue, 26 Apr 2005 22:44:50 +0200 Subject: projectroot makes ld not work In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <1114548290.3655.44.camel@trabant> Am Dienstag, den 26.04.2005, 16:17 +0200 schrieb Christoffer Brodd-Reijer: > I want to compile the CVS of xorg and not install it over my existing > xorg. So I read the CVS page on the xorg wiki. My intentions are to > install DRI and DRM for my VIA video card (following a guide at > http://dri.freedesktop.org/wiki/Building, but this one installs over the > existing xorg). So I fetched the cvs and the host.def from > http://freedesktop.org/~fxkuehl/host.def. Now I added #define > ProjectRoot and NothingOutsideProjectRoot, so I could install this new > xorg at some location and then just make a symlink. > > When I tried to compile I got this error: [...] I do the same myself. The problem is that the partial build relies on some headers and libs from XFree86/Xorg being installed in ProjectRoot before the build. Try this (assuming ProjectRoot is set to /usr/X11R6-XORG): cd /usr mkdir X11R6-XORG cd X11R6-XORG mkdir include lib lndir ../X11R6/include include lndir ../X11R6/lib lib rm -rf lib/modules (The last line may be necessary to avoid conflicts between old and new modules. Make sure that you don't run this in the wrong directory.) After that run make World in your Xorg source tree. Mvh, Felix -- | Felix K?hling
From sandmann at daimi.au.dk Tue Apr 26 13:48:10 2005 From: sandmann at daimi.au.dk (Soeren Sandmann) Date: 26 Apr 2005 22:48:10 +0200 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <1114533481.11262.10.camel@huygens> <[email protected]> Message-ID:
S?ren
From zrusin at trolltech.com Tue Apr 26 13:54:02 2005 From: zrusin at trolltech.com (Zack Rusin) Date: Tue, 26 Apr 2005 16:54:02 -0400 Subject: render improvements In-Reply-To:
From otaylor at redhat.com Tue Apr 26 14:11:53 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 26 Apr 2005 17:11:53 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]>
From otaylor at redhat.com Tue Apr 26 16:37:48 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 26 Apr 2005 19:37:48 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <1114549913.11262.69.camel@huygens> <[email protected]> Message-ID: <1114558668.11262.75.camel@huygens> On Tue, 2005-04-26 at 19:09 -0400, Zack Rusin wrote: > On Tuesday 26 April 2005 17:11, Owen Taylor wrote: > > What I did to verify was to look at the xserver diff, which is > > smaller, and that didn't look to touch the selection of an optimized > > path at all. > > > > Then I diff'ed fbpict.c between the patched version of the xserver > > code and the patched version of the xorg code, and 'diff -uw' was > > essentially empty, so I think if the xorg code compiles with USE_MMX, > > it should be selecting the right version. > > You're talking about the old version. The diff for Xorg is smaller than > for Xserver. It barely touches fbpict at all. The new patch doesn't > merge the changes between xserver or xorg it just adds the new Render > implementation so there are differences between fbpict's in both > servers (oh, and yes it does compile with mmx code). Well, the old version validates. I'd rather see that then a new version that we have to separately merge the fbpict.c changes, but either way works in the end. Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From otaylor at redhat.com Tue Apr 26 16:37:48 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 26 Apr 2005 19:37:48 -0400 Subject: render improvements In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <1114549913.11262.69.camel@huygens> <[email protected]> Message-ID: <1114558668.11262.75.camel@huygens> On Tue, 2005-04-26 at 19:09 -0400, Zack Rusin wrote: > On Tuesday 26 April 2005 17:11, Owen Taylor wrote: > > What I did to verify was to look at the xserver diff, which is > > smaller, and that didn't look to touch the selection of an optimized > > path at all. > > > > Then I diff'ed fbpict.c between the patched version of the xserver > > code and the patched version of the xorg code, and 'diff -uw' was > > essentially empty, so I think if the xorg code compiles with USE_MMX, > > it should be selecting the right version. > > You're talking about the old version. The diff for Xorg is smaller than > for Xserver. It barely touches fbpict at all. The new patch doesn't > merge the changes between xserver or xorg it just adds the new Render > implementation so there are differences between fbpict's in both > servers (oh, and yes it does compile with mmx code). Well, the old version validates. I'd rather see that then a new version that we have to separately merge the fbpict.c changes, but either way works in the end. Regards, Owen ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From daniel at fooishbar.org Tue Apr 26 21:47:49 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 27 Apr 2005 14:47:49 +1000 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From daniel at fooishbar.org Tue Apr 26 22:31:09 2005 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 27 Apr 2005 15:31:09 +1000 Subject: pkgconfig license In-Reply-To: <[email protected]> References:
From jonasmg at softhome.net Wed Apr 27 01:50:48 2005 From: jonasmg at softhome.net (Jonas Melian) Date: Wed, 27 Apr 2005 09:50:48 +0100 Subject: Info about ddc at configure Message-ID: <[email protected]> Is it possible load this modules: libddc.a, libi2c.a, with 'X -configure' to get info as Display Input, Supported VESA Video Modes, Supported Future Video Modes, Monitor type? The idea is get that information when i run X -configure, so i can configure ok x.org. Now i'm using ddcxinfo-knoppix and ddcprobe to get those data. By the way, I believe that all this information (vbe/ddc), obtained when we initiated x.org, that it is always the same should to be written in the configuration file since is not going to change. If somebody is going to change of monitor or graphical card since it obtains this data again.
From cerdiogenes at yahoo.com.br Wed Apr 27 08:00:40 2005 From: cerdiogenes at yahoo.com.br (=?ISO-8859-1?Q?Carlos_Eduardo_Rodrigues_Di=F3 genes?=) Date: Wed, 27 Apr 2005 12:00:40 -0300 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Hi, How the accessibility list is dead, I decide to post it here. I have an idea of an extension, the X Zoom Extension. I'm posting it here, because sometimes someone have some good ideas and have thinked in this problem. First, to a Zoom extension be good it have to support split screen. Here is my first doubt, it's possible to have an region of the screen that is an entirely root screen? Why I think this could help? If it could be done, we can redirect the rendering of the real screen to the zoomed screen (I don't know if it's possible now too). It is, two screens in one monitor, but the zoomed screen will have an diferrent resolution, so the things that are rendered there get bigger. Other thing that I think that is very interesting to this type of solution is the fonts of X Window System use SVG, because this way we do not have problem in magnifying text, we can maintain the quality. Cairo can give some help with this??? If someone have something to say about this, have some tips of what I can study to solve the problems that I apresented or if I say somethings that are very stupid, share, I will be very thankful. Thanks, Carlos.
From keithp at keithp.com Wed Apr 27 08:39:58 2005 From: keithp at keithp.com (Keith Packard) Date: Wed, 27 Apr 2005 08:39:58 -0700 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Wed, 2005-04-27 at 12:00 -0300, Carlos Eduardo Rodrigues Di?genes wrote: > Hi, > > How the accessibility list is dead, I decide to post it here. > > I have an idea of an extension, the X Zoom Extension. I'm posting it > here, because sometimes someone have some good ideas and have thinked in > this problem. Have you seen my demonstration application 'diopter'? It's in xapps CVS at freedesktop.org and presents a full-screen magnified view which can trivially be modified to display any combination of normal and magnified presentation. The missing piece in this puzzle is mouse-position remapping and work on that piece is on-going. That can be kludged-around by drawing the mouse to the magnified screen by hand while replacing the 'real' sprite with an empty image. > Other thing that I think that is very interesting to this type of > solution is the fonts of X Window System use SVG, because this way we do > not have problem in magnifying text, we can maintain the quality. Cairo > can give some help with this??? Yes, a few people have started thinking about how we might present the application with information about the complete transformation of the window so that the application could construct a target-pixel based representation of its contents. We should start looking into this once we have a more complete implementation of magnification working. > If someone have something to say about this, have some tips of what I > can study to solve the problems that I apresented or if I say somethings > that are very stupid, share, I will be very thankful. I think we have nearly completed the required extensions for this kind of application; please feel free to explore 'diopter' and see whether that does what you need. Given basic magnification, I'd also like to explore different resampling algorithms which can improve the appearance of existing applications. I've seen some interesting algorithmic pixel selection mechanisms which smooth the image while retaining sharp edges of glyphs. I'm wondering if we can't achieve this in hardware by using pixel shaders. Exploring this using the 'luminocity' framework would prove whether it was feasible before we have a completed X server architecture which can get at this kind of hardware. -keith ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
> Given basic magnification, I'd also like to explore different resampling > algorithms which can improve the appearance of existing applications. > I've seen some interesting algorithmic pixel selection mechanisms which > smooth the image while retaining sharp edges of glyphs. I'm wondering > if we can't achieve this in hardware by using pixel shaders. Exploring > this using the 'luminocity' framework would prove whether it was > feasible before we have a completed X server architecture which can get > at this kind of hardware. While it might ultimately be too slow for real use at GUI environment resolutions, the hq2x/3x/4x software algorithms do an excellent job of this, and are quite popular in the emulation community. http://www.hiend3d.com/hq2x.html ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From ijs at txcorp.com Wed Apr 27 09:03:02 2005 From: ijs at txcorp.com (Irek Szczesniak) Date: Wed, 27 Apr 2005 10:03:02 -0600 (MDT) Subject: How to find an available display for Xvfb? Message-ID:
Thanks & best, Irek
From Jim.Gettys at hp.com Wed Apr 27 09:31:49 2005 From: Jim.Gettys at hp.com (Jim Gettys) Date: Wed, 27 Apr 2005 12:31:49 -0400 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Note that magnification is a situation where the display needs to go fast when you are moving a magnifier or the contents of a window changes, but most things are static, most of the time. So having a "cheezy" algorithm that is fast to use in the circumstances where it has to be fast for interactivity's sake, and another more expensive one to use when it doesn't need to go fast is a good approach. And damage lets us know whether window contents are changing under us, so we can figure out what to do when... - Jim
On Wed, 2005-04-27 at 11:59 -0400, Dave Ahlswede wrote: > > Given basic magnification, I'd also like to explore different resampling > > algorithms which can improve the appearance of existing applications. > > I've seen some interesting algorithmic pixel selection mechanisms which > > smooth the image while retaining sharp edges of glyphs. I'm wondering > > if we can't achieve this in hardware by using pixel shaders. Exploring > > this using the 'luminocity' framework would prove whether it was > > feasible before we have a completed X server architecture which can get > > at this kind of hardware. > > While it might ultimately be too slow for real use at GUI environment > resolutions, the hq2x/3x/4x software algorithms do an excellent job of > this, and are quite popular in the emulation community. > > http://www.hiend3d.com/hq2x.html > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
From ttb at tentacle.dhs.org Wed Apr 27 09:33:38 2005 From: ttb at tentacle.dhs.org (John McCutchan) Date: Wed, 27 Apr 2005 12:33:38 -0400 Subject: render improvements In-Reply-To:
From pinzari at nomachine.com Wed Apr 27 09:47:45 2005 From: pinzari at nomachine.com (Gian Filippo Pinzari) Date: Wed, 27 Apr 2005 18:47:45 +0200 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected] m> <[email protected]> <[email protected]> Message-ID: <[email protected]> Jim Gettys wrote: > And damage lets us know whether window contents are changing under us, > so we can figure out what to do when... Wouldn't it be better for the server to scale the coordinates of the X primitives on the fly? I admit that this would not be trivial, but would surely be more efficient, at least from the network point of view. /Gian Filippo.
From list at hoenig.cc Thu Apr 28 04:36:44 2005 From: list at hoenig.cc (Christian Hoenig) Date: Thu, 28 Apr 2005 13:36:44 +0200 Subject: flush xorg image cache? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Hi, > > There is no image cache. > > > > (What you probably are seeing is simply that once the server has > > allocated memory from the operating system, it can't easily return it.) > > You can check this btw with the X resource tools and see if its > resources allocated or as Owen (and I agree with his interpretation) > thinks. Thank for all your head ups! I have to rethink my memory strategy then. And sorry for the late answer, I had an exam today and was out of time lately :-) take care, have fun /christian ------next part ------A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL:
On Wed, 2005-04-27 at 18:47 +0200, Gian Filippo Pinzari wrote: > Jim Gettys wrote: > > And damage lets us know whether window contents are changing under us, > > so we can figure out what to do when... > > Wouldn't it be better for the server to scale the coordinates of > the X primitives on the fly? I admit that this would not be trivial, > but would surely be more efficient, at least from the network point > of view. > > /Gian Filippo. > > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
From debackerl at gmail.com Thu Apr 28 08:55:30 2005 From: debackerl at gmail.com (Laurent Debacker) Date: Thu, 28 Apr 2005 17:55:30 +0200 Subject: Accelerated Trident CyberBlade XP Ai1? Message-ID: <[email protected]> Hello I've a Trident CyberBlade XP Ai1 w/16MB on a Toshiba Port?g? 4000 laptop. I'm running X.org 6.8.2 on FreeBSD 5.4-RC3. Is it possible to get it in accelerated mode? From some web pages about the trident driver, it seems it's accelerated. However a SuSE web pages said it could with X.org. I asked xorg to load glx, dri, and some other stuffs. I also set the DRI mode as 0666. However glxinfo tell me that direct rendering is not enabled. Any idea? Thank you :) Laurent. From pinzari at nomachine.com Thu Apr 28 09:28:43 2005 From: pinzari at nomachine.com (Gian Filippo Pinzari) Date: Thu, 28 Apr 2005 18:28:43 +0200 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Jim Gettys wrote: > You're idea is intriguing, and has me thinking..... Dunno whether it > could work out: I'll chat with Keithp about it... IMHO if we limit this to the core protocol (I mean the GC and the Screen ops of the sample server) this should not be overly diffi- cult. For extensions (other than RENDER) the problem is probably more complex. /Gian Filippo.
From alexdeucher at gmail.com Thu Apr 28 09:39:26 2005 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 28 Apr 2005 12:39:26 -0400 Subject: Accelerated Trident CyberBlade XP Ai1? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID:
From Alan.Coopersmith at Sun.COM Thu Apr 28 09:48:30 2005 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Thu, 28 Apr 2005 09:48:30 -0700 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Gian Filippo Pinzari wrote: > Jim Gettys wrote: > >> And damage lets us know whether window contents are changing under us, >> so we can figure out what to do when... > > > Wouldn't it be better for the server to scale the coordinates of > the X primitives on the fly? I admit that this would not be trivial, > but would surely be more efficient, at least from the network point > of view. That was our initial thought several years ago when we first started working with the GNOME Accessibility project on screen magnification, but we ended up dropping the idea, because they wanted far more control over the magnified output than a simple server side magnifier could provide. For some cases, it's probably good enough, and clearly more could be made more efficient, but those weren't the cases we had to tackle. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
From pinzari at nomachine.com Thu Apr 28 11:08:59 2005 From: pinzari at nomachine.com (Gian Filippo Pinzari) Date: Thu, 28 Apr 2005 20:08:59 +0200 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Alan Coopersmith wrote: > That was our initial thought several years ago when we first started > working with the GNOME Accessibility project on screen magnification, > but we ended up dropping the idea, because they wanted far more control > over the magnified output than a simple server side magnifier could > provide. For some cases, it's probably good enough, and clearly more > could be made more efficient, but those weren't the cases we had to > tackle. I understand your points and fully agree. Anyway they seem to me two different problems. The point of extensions like RANDR, I think, is to make advanced features easily accessible to all clients (built-in?), even if these features could be implemented in clients. If we accept the idea that to implement magnification we have to grab the pixels from the frame-buffer and put it again, magnified, on the server, we are loosing most of the advantages of having a high-level protocol to draw on the display. My take of X windowing, instead, is that we should just go on the "View" menu of the X server and select "Increase font size", as we do with Firefox ;-). I'm perfectly aware that there are important performance implications (an X server is very low in the stack) and that handling something like a "X11 CSS" is not like handling HTML, but maybe it's a possibi- lity. Extensions like DAMAGE appear to me like a renounce. It's like saying: "we can't implement all the things that could be useful in the X server, so let's make applications deal directly with the pixels on the frame-buffer"... /Gian Filippo. P.S.: I love the DAMAGE extension and understand the whole lot of possibilities it opens to developers ;-).
From Jim.Gettys at hp.com Thu Apr 28 11:26:26 2005 From: Jim.Gettys at hp.com (Jim Gettys) Date: Thu, 28 Apr 2005 14:26:26 -0400 Subject: X Zoom Extension: Ideas and Suggestions! In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> The problem is that at this level of the stack (from application, to toolkit, to graphics library, to commands, to pixels), we're really at too low a level to know enough about what the application needs. Even most operations in render are pixel images (e.g. glyphs); about the only operation you might scale successfully are traps. Keith and I have been thinking over the issues presented by projectors and even how one might rotate windows. Even an affine transform is insufficient. A possible solution that leaves things working by dumb applications, but allows them (and/or toolkits) to do better would be a signaling system, in which we might inform clients (toolkits) things like: "If you render into this pixmap over here, which has the following relationship to you original window, you can get better (higher quality) results". I've been thinking along these lines for rotated windows, and there there may be (particularly with GTK moving to using Cairo for its rendering) significant quality advantage to ask the application to repaint once rotation has ceased at the final rotation. Given Cairo as under pinnings that should be do-able. So for a magnifier application, we could just give the application a hint: here's this other pixmap, scaled in relative to the original, and have it repaint. For dumb applications, you'd just get cheezy pixel level applications. - Jim
On Thu, 2005-04-28 at 20:08 +0200, Gian Filippo Pinzari wrote: > Alan Coopersmith wrote: > > That was our initial thought several years ago when we first started > > working with the GNOME Accessibility project on screen magnification, > > but we ended up dropping the idea, because they wanted far more control > > over the magnified output than a simple server side magnifier could > > provide. For some cases, it's probably good enough, and clearly more > > could be made more efficient, but those weren't the cases we had to > > tackle. > > I understand your points and fully agree. Anyway they seem to me two > different problems. The point of extensions like RANDR, I think, is > to make advanced features easily accessible to all clients (built-in?), > even if these features could be implemented in clients. If we accept > the idea that to implement magnification we have to grab the pixels > from the frame-buffer and put it again, magnified, on the server, we > are loosing most of the advantages of having a high-level protocol > to draw on the display. My take of X windowing, instead, is that we > should just go on the "View" menu of the X server and select "Increase > font size", as we do with Firefox ;-). > > I'm perfectly aware that there are important performance implications > (an X server is very low in the stack) and that handling something > like a "X11 CSS" is not like handling HTML, but maybe it's a possibi- > lity. Extensions like DAMAGE appear to me like a renounce. It's like > saying: "we can't implement all the things that could be useful in the > X server, so let's make applications deal directly with the pixels > on the frame-buffer"... > > /Gian Filippo. > > P.S.: I love the DAMAGE extension and understand the whole lot of > possibilities it opens to developers ;-). > > > ______> xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg
From cworth at cworth.org Thu Apr 28 13:15:04 2005 From: cworth at cworth.org (Carl Worth) Date: Thu, 28 Apr 2005 16:15:04 -0400 Subject: render improvements In-Reply-To: <1114619618.31990.0.camel@vertex> References: <[email protected]> <[email protected]>
From yuanshengquan at gmail.com Fri Apr 29 03:30:16 2005 From: yuanshengquan at gmail.com (Austin Yuan) Date: Fri, 29 Apr 2005 18:30:16 +0800 Subject: Why no xf86DeallocateGARTMemory? In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> There isn't a function to free AGP memory in lnx_agp.c,and it is very easy to implement it, but why not? I need it to do dynamic AGP memory allocation in 2D driver. I know when releasing AGP gart, all memory will be freed,but it isn't flexible.
From alanh at fairlite.demon.co.uk Fri Apr 29 06:01:58 2005 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 29 Apr 2005 14:01:58 +0100 Subject: Why no xf86DeallocateGARTMemory? In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> On Fri, Apr 29, 2005 at 06:30:16PM +0800, Austin Yuan wrote: > There isn't a function to free AGP memory in lnx_agp.c,and it is very > easy to implement it, but why not? I need it to do dynamic AGP memory > allocation in 2D driver. I know when releasing AGP gart, all memory > will be freed,but it isn't flexible. It's never really been required before, but there's nothing stopping us adding that function. If you want to implement it and submit a patch that'd be great. Alan.
From keithp at keithp.com Fri Apr 29 08:38:15 2005 From: keithp at keithp.com (Keith Packard) Date: Fri, 29 Apr 2005 08:38:15 -0700 Subject: Shape event using Xfixes region In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Fri, 2005-04-29 at 09:59 +0200, Buola Buola wrote: > I am using an XserverRegion and the Xfixes functions to change the > shape of a window, and I notice that I don't receive any ShapeNotify > event, while I do receive it when I change shape with any of the > funcions of the XShape extension. Is this possible or I have to check > something again? I have to admit that I never tested this case, but the code appears to be in place to send the events, and there doesn't seem to be any way around it. > If this is true, is it a bug or some design decision that I can't understand? > thanks in advance, A small test case which demonstrates the bug would be helpful in diagnosing whether your application or the X server is at fault. -keith ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
Best, Irek
From buola69 at gmail.com Fri Apr 29 15:35:36 2005 From: buola69 at gmail.com (Buola Buola) Date: Sat, 30 Apr 2005 00:35:36 +0200 Subject: Shape event using Xfixes region In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> Message-ID: <[email protected]> > A small test case which demonstrates the bug would be helpful in > diagnosing whether your application or the X server is at fault. > Here is a very short piece of code which still has the problem #include
I also send you exactly the same functionality without using regions: #include
The version which only uses the XShape extension works fine, prints the message and exits, while the one with Xfixes loops forever Am I missing something? Thanks a lot for your help, Xavi
From keithp at keithp.com Fri Apr 29 17:11:33 2005 From: keithp at keithp.com (Keith Packard) Date: Fri, 29 Apr 2005 17:11:33 -0700 Subject: Shape event using Xfixes region In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On Sat, 2005-04-30 at 00:35 +0200, Buola Buola wrote: > The version which only uses the XShape extension works fine, prints > the message and exits, while the one with Xfixes loops forever > > Am I missing something? It doesn't look like it -- your test case works correctly on my X server (Xati). There appears to be a bug specific to your X server here. -keith ------next part ------A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL:
From yuanshengquan at gmail.com Sat Apr 30 00:42:06 2005 From: yuanshengquan at gmail.com (Austin Yuan) Date: Sat, 30 Apr 2005 15:42:06 +0800 Subject: Intel 845 ReadPixmap hw acceleration In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> In order to do some performance improvement for XGetImage, I attempt to implement hardware acceleration for ReadPixmap for the integrated graphics device on Intel845GVSH desktop board. ReadPixmap is a bitblt from framebuffer to system memory. The register specification says that the BLT Engine can be used to transfer data from cacheable memory to graphics memory and vice versa using the BLT instructions,and all surface address programmed in these instructions must be mapped through the GTT. In my opinion, I must program GTT to map system memory in user space as graphics memory("AGP" memory), then use BLT engine to bitblt from frame buffer to it. Now I have patched agpgart driver to support user space memory mapping(using get_use_pages for 2.6 kernel). For every ReadPixmap, I call agpgart driver to map and bind the user space pages and then do the bitblt,and then unbind,free those pages. My question is: Is my idea right?and how to keep cache coherency after bitblt? I fill the user space memory with a solid color using blt engine, but I get a wrong color by reading from it. From yuanshengquan at gmail.com Sat Apr 30 01:07:00 2005 From: yuanshengquan at gmail.com (Austin Yuan) Date: Sat, 30 Apr 2005 16:07:00 +0800 Subject: Intel 845 ReadPixmap hw acceleration In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On 4/30/05, Austin Yuan
From buola69 at gmail.com Sat Apr 30 04:19:56 2005 From: buola69 at gmail.com (Buola Buola) Date: Sat, 30 Apr 2005 13:19:56 +0200 Subject: Shape event using Xfixes region In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> On 4/30/05, Keith Packard
From sithglan at stud.uni-erlangen.de Sat Apr 30 17:23:41 2005 From: sithglan at stud.uni-erlangen.de (Thomas Glanzmann) Date: Sun, 1 May 2005 02:23:41 +0200 Subject: Looking for Grpahic Card which supports Rotating CCW with Acceleration, DVI Output and XV support Message-ID: <[email protected]> Hello, I am looking for a graphic card which support ccw rotate via the rotate/resize extension, has a DVI output and XV support. Sincerely, Thomas