Re: [ANNOUNCE] xorg-server 1.6.1.902
On Tue, 2009-06-30 at 07:57 +0200, Rémi Cardona wrote: Le 30/06/2009 01:03, Keith Packard a écrit : Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've pulled the remaining queued patches and have pushed this as 1.6.1.902 (1.6.2 RC2). If no-one finds any catastrophic bugs, I'll push this out as 1.6.2 shortly. This bug [1] is probably worth waiting for, as I've only been tracking the nominations page with our packages. So, one of the commits since Eamon's xace: Fix a bad device access hook call. seems to have broken KMS somehow. Could I get you to bisect for the problem? (it works for me...) -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Tue, 2009-06-30 at 07:45 +0200, Rémi Cardona wrote:
Le 30/06/2009 01:03, Keith Packard a écrit :
Kristian Høgsberg (1):
Support setTexBuffer2 in AIGLX.
Keith,
That patch requires either some #ifdefs to make it build with mesa 7.4,
or mesa's minimum version needs to be pushed to 7.5 in configure.ac.
How about this (untested) patch?
commit a7a93c12f91e0de72868f17a555215f1795d9e2f
Author: Keith Packard kei...@keithp.com
Date: Mon Jun 29 23:18:55 2009 -0700
Build against DRI_TEX_BUFFER_VERSION 1
setTexBuffer2 isn't present in this version of the structure, so don't try
to call it.
Signed-off-by: Keith Packard kei...@keithp.com
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 0b64298..836fea4 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -222,12 +222,15 @@ __glXDRIbindTexImage(__GLXcontext *baseContext,
if (texBuffer == NULL)
return Success;
+#if __DRI_TEX_BUFFER_VERSION = 2
if (texBuffer-base.version = 2 texBuffer-setTexBuffer2 != NULL) {
(*texBuffer-setTexBuffer2)(context-driContext,
glxPixmap-target,
glxPixmap-format,
drawable-driDrawable);
-} else {
+} else
+#endif
+{
texBuffer-setTexBuffer(context-driContext,
glxPixmap-target,
drawable-driDrawable);
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Mon, 2009-06-29 at 16:03 -0700, Keith Packard wrote: Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've pulled the remaining queued patches and have pushed this as 1.6.1.902 (1.6.2 RC2). If no-one finds any catastrophic bugs, [...] How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. You rejected backports before based on breaking ABI. Don't get me wrong, I like the functionality those DRI2 changes fix, but surely they could have been done without breaking about every binary interface involved. If the video driver ABI won't be restored, this should be reflected by bumping its major version, and the changes breaking it should wait for the next major release like other such changes. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Mon, 29 Jun 2009 23:20:03 -0700 Keith Packard kei...@keithp.com wrote: On Tue, 2009-06-30 at 07:45 +0200, Rémi Cardona wrote: Le 30/06/2009 01:03, Keith Packard a écrit : Kristian Høgsberg (1): Support setTexBuffer2 in AIGLX. Keith, That patch requires either some #ifdefs to make it build with mesa 7.4, or mesa's minimum version needs to be pushed to 7.5 in configure.ac. How about this (untested) patch? commit a7a93c12f91e0de72868f17a555215f1795d9e2f Author: Keith Packard kei...@keithp.com Date: Mon Jun 29 23:18:55 2009 -0700 Build against DRI_TEX_BUFFER_VERSION 1 setTexBuffer2 isn't present in this version of the structure, so don't try to call it. Mail client munged it, but after hand-applying it, looks good here. Up and running on 1.6.1.902 and intel-2.7.99.901 -- thanks! -RW signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Tue, 2009-06-30 at 08:46 +0200, Michel Dänzer wrote: How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. I've read the reports, and I'm treating this as a bug at this point -- I need to see more information about how the ABI is broken so we can figure out how to fix it. You rejected backports before based on breaking ABI. Yup, let's figure out how to fix it. This ABI breakage is unintentional, I believe. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
Keith Packard a écrit : Could I get you to bisect for the problem? (it works for me...) It works for me as well unfortunately, I'll help the user to get the bisect ASAP. Thanks -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
2009/6/30 Keith Packard kei...@keithp.com: On Tue, 2009-06-30 at 08:46 +0200, Michel Dänzer wrote: How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. I've read the reports, and I'm treating this as a bug at this point -- I need to see more information about how the ABI is broken so we can figure out how to fix it. You rejected backports before based on breaking ABI. Yup, let's figure out how to fix it. This ABI breakage is unintentional, I believe. I'm not sure you can easily. The DRI2BufferRec changes size (adds a new int format), the driver mallocs an array of these, so you are probably pwned in that case. I think the extension of DRI2InfoRec is probably okay, if the server checks the version. Dave. -- keith.pack...@intel.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Tue, Jun 30, 2009 at 19:09:00 +1000, Dave Airlie wrote: The DRI2BufferRec changes size (adds a new int format), the driver mallocs an array of these, so you are probably pwned in that case. I think the extension of DRI2InfoRec is probably okay, if the server checks the version. DRI2ScreenInit bails out if the driver was built with the old DRI2InfoRec version, so in that case the DRI2BufferRec mallocs shouldn't happen, unless I'm missing something. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'server-1.6-branch' - 10 commits
On Wed, Jun 24, 2009 at 13:34:57 +0200, Brice Goglin wrote: Hello Ian, This backport breaks the ABI (somewhere between 4cb4c210 and 6be19e8f, I couldn't finish the bisect). The server reproducibly freezes a couple seconds after Gnome startup with Intel 2.7.99.901, KMS and 2.6.30 on i945. Rebuildind the Intel driver against updated Xserver and DRI2 proto fixes the problem. This might not actually be due to ABI breakage, but mostly exposing an xf86-video-intel bug. When running a server without these changes, and xf86-video-intel hacked to disable dri2 on kms, the server crashes in libdrm_intel::drm_intel_gem_bo_alloc_internal(), i.e. the same thing that happens with the updated server, where DRI2ScreenInit() bails out. I haven't tried driver 2.7.1 or UMS. Hope this helps, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'server-1.6-branch' - 10 commits
Julien Cristau a écrit : This might not actually be due to ABI breakage, but mostly exposing an xf86-video-intel bug. When running a server without these changes, and xf86-video-intel hacked to disable dri2 on kms, the server crashes in libdrm_intel::drm_intel_gem_bo_alloc_internal(), i.e. the same thing that happens with the updated server, where DRI2ScreenInit() bails out. I haven't tried driver 2.7.1 or UMS. After talking with Julien, it seems that the 1.6.2 RC2 KMS failure I reported in the announce thread is the same bug. We've started tracking this in here. http://bugs.freedesktop.org/show_bug.cgi?id=22537 Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: proportional panning
On Jun 28, 09 04:41:54 +0100, David De La Harpe Golden wrote:
2009/6/8 Matthias Hopf mh...@suse.de:
Yes, you're right - I forgot how it was on the Amiga. Shame on me.
You're more than welcome to add this to the panning code.
Turns out doing the panning itself is the easy bit, there's extending the
randr
protocol to include a panning mode field and xrandr command line tool to
grok it too to worry about...
Yes, there is no flags field or something similar so far. Either means
that there should be an additional call, or this could be implemented
with a (to be standardized) property for the moment. In the end this
probably should be part of the protocol.
Attached please find an initial patch anyway, though only settable
from xorg.conf
as it stands owing to the above, just adds another field to the end of
the lengthy
Panning option string:
/b (or nothing - default) for border push,
/l for the proportional panning.
Reasonable enough for the beginning.
Note that the border values are still used and relevant in the proportional
code path:
1. as you get close to the edge of the crtc it can be nice to
have unpanned zones to facilitate window placement, it made
sense to reuse the border fields, use positive
border values to have such zones, as in the first example below.
Agreed.
2. it turns out negative border values also allow a potentially quite
useful effect with the proportional panning mode:
Say you had two 1024x768 monitors, one above the other. You want
a larger virtual desktop, say 2048x3072. Well, you can e.g. do the
following, and as you pan around the edges will line up on
both heads at all times, which is neat:
Interesting. Wouldn't have thought of that :-)
Might be interesting to add this to the manual as an example (if it
isn't already).
+ switch (pm) {
+case 'l':
+ output-initialPanningMode = XF86CrtcPanningModeLinear;
+ break;
+case 'b':
+default:
+ output-initialPanningMode = XF86CrtcPanningModeBorderPush;
You should consider printing a warning or even error if the mode is wrong.
Other modes might be added in the future.
+ * panningMode: e.g. push against border or proportional to pointer
position.
+ * Added in ABI version ???
Please change XF86_CRTC_VERSION if you change the struct.
Also only add entries to the end of the struct. This might look ugly,
but is backward compatible. Otherwise we would have to change the server
ABI for just that.
@@ -605,6 +614,7 @@ struct _xf86Output {
BoxRec initialTotalArea;
BoxRec initialTrackingArea;
INT16 initialBorder[4];
+xf86CrtcPanningMode initialPanningMode;
Similar, change XF86_OUTPUT_VERSION.
+ propx = crtc-panningBorder[0] +
+(((x - crtc-panningTotalArea.x1) *
+ (width - crtc-panningBorder[0] -
crtc-panningBorder[2])) /
+ (crtc-panningTotalArea.x2 -
crtc-panningTotalArea.x1));
This *looks* like it could require some rounding - but I could be
totally wrong.
Thanks
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with resumed suspend: Work (dual/external heads) = Home (built in laptop display)
Okay, for posterity, I found the bug that I had commented on. I have several comments on it. (Starting with http://bugs.freedesktop.org/show_bug.cgi?id=17638#c24 ) FWIW, now, with a vanilla xorg.conf, I still have related black-screen problems, but they only last a second or so. I'm not saying this is related to your issue, I was just trying to recall what problem I'd been having, as had originally thought it might be related, before I found the ticket. Thanks, Jamie On Tue, Jun 30, 2009 at 1:23 PM, Jamie Jacksonmyspa...@gmail.com wrote: Hardware: product: Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller Driver (I think this is what you're after, anyway): (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 However, my problem is only when I resume to a different display configuration (i.e., home = work). I don't have any problems resuming to the same displays (e.g., work = work). Actually, now that I think about it, I do have vague memories of having a black display sometimes when suspending/resuming the laptop display. Sometimes, I think I had to hard reset, or ssh in and pm-suspend and re-resume it. My memory's fuzzy on this, but I'll see if I bugged this issue. Thanks, Jamie On Tue, Jun 23, 2009 at 2:05 PM, Andreas Schildbachandr...@schildbach.de wrote: Hi Jamie, What's your hardware? Which video driver do you use? I've got a very similar problem, except that mostly only either the internal or the external display is deactivated after resume. Also, the problem can be reproduced without actually switching monitors (like in your case with home/work). Can you try again by just suspending and resuming without disconnecting the external monitor? Anyway, here is my bugreport: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/352708 Best regards, Andreas On Thu, 2009-06-18 at 01:08 -0400, Jamie Jackson wrote: (Ubuntu 9.04) At work, I've got dual head, external monitors (VGA, TDMS-1). If I suspend there, and resume at home (using only built-in LVDS), I get a black screen. I have similar problems when going in reverse. The only way I've been able to recover is via SSH and xrandr, however, my home = work xrandr process is haphazard. While I can usually get it to work, I can only get enough to give me a panel (on the wrong screen, the VGA) to get to the gnome display config gui (where I can finish the proper config, getting the panel on the main TDMS-1, and the auxiliary display on the smaller VGA). When I need to resume at home, I usually bag it, and just hard reset. I've got a few questions: 1. Is there a way to get X to roam better (be smarter about detecting and using displays on resume)? 2. Alternatively, is there some xrandr sequence I can use that makes the home = work transition less awkward? 3. Also, alternatively, what's the sequence for the work = home transition? (This one's a bit of a pain, because I've got to jump through some hoops to SSH in at home, but if I had a sequence, I could script it, and then maybe blindly run my script from a TTY.) Thanks, Jamie ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with resumed suspend: Work (dual/external heads) = Home (built in laptop display)
Hardware: product: Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller Driver (I think this is what you're after, anyway): (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 However, my problem is only when I resume to a different display configuration (i.e., home = work). I don't have any problems resuming to the same displays (e.g., work = work). Actually, now that I think about it, I do have vague memories of having a black display sometimes when suspending/resuming the laptop display. Sometimes, I think I had to hard reset, or ssh in and pm-suspend and re-resume it. My memory's fuzzy on this, but I'll see if I bugged this issue. Thanks, Jamie On Tue, Jun 23, 2009 at 2:05 PM, Andreas Schildbachandr...@schildbach.de wrote: Hi Jamie, What's your hardware? Which video driver do you use? I've got a very similar problem, except that mostly only either the internal or the external display is deactivated after resume. Also, the problem can be reproduced without actually switching monitors (like in your case with home/work). Can you try again by just suspending and resuming without disconnecting the external monitor? Anyway, here is my bugreport: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/352708 Best regards, Andreas On Thu, 2009-06-18 at 01:08 -0400, Jamie Jackson wrote: (Ubuntu 9.04) At work, I've got dual head, external monitors (VGA, TDMS-1). If I suspend there, and resume at home (using only built-in LVDS), I get a black screen. I have similar problems when going in reverse. The only way I've been able to recover is via SSH and xrandr, however, my home = work xrandr process is haphazard. While I can usually get it to work, I can only get enough to give me a panel (on the wrong screen, the VGA) to get to the gnome display config gui (where I can finish the proper config, getting the panel on the main TDMS-1, and the auxiliary display on the smaller VGA). When I need to resume at home, I usually bag it, and just hard reset. I've got a few questions: 1. Is there a way to get X to roam better (be smarter about detecting and using displays on resume)? 2. Alternatively, is there some xrandr sequence I can use that makes the home = work transition less awkward? 3. Also, alternatively, what's the sequence for the work = home transition? (This one's a bit of a pain, because I've got to jump through some hoops to SSH in at home, but if I had a sequence, I could script it, and then maybe blindly run my script from a TTY.) Thanks, Jamie ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: On Mon, 2009-06-29 at 16:03 -0700, Keith Packard wrote: Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've pulled the remaining queued patches and have pushed this as 1.6.1.902 (1.6.2 RC2). If no-one finds any catastrophic bugs, [...] How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. You rejected backports before based on breaking ABI. Don't get me wrong, I like the functionality those DRI2 changes fix, but surely they could have been done without breaking about every binary interface involved. If the video driver ABI won't be restored, this Actually, the bug in question could not. This was discussed quite a bit on the mailing list and on IRC. The original DRI2 interface was deficient and could not be made to work. So I fixed it. should be reflected by bumping its major version, and the changes breaking it should wait for the next major release like other such changes. The change is in the DRI2 interface, and that version was changed. Without the corresponding updates the only thing you lose is DRI2. Reverting to DRI1 should still work. Since this affects only the Intel driver, and we will have a fixed driver release around the same time as the X server release, I don't think this is a catastrophic problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpKb7wACgkQX1gOwKyEAw8PRACfbon5CuXyDPDMfA+OHLedj7uI I3MAn3qMXMadPzpqIoWFfeYjCJNniZAv =Mcf5 -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: 2009/6/30 Keith Packard kei...@keithp.com: On Tue, 2009-06-30 at 08:46 +0200, Michel Dänzer wrote: How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. I've read the reports, and I'm treating this as a bug at this point -- I need to see more information about how the ABI is broken so we can figure out how to fix it. You rejected backports before based on breaking ABI. Yup, let's figure out how to fix it. This ABI breakage is unintentional, I believe. I'm not sure you can easily. The DRI2BufferRec changes size (adds a new int format), the driver mallocs an array of these, so you are probably pwned in that case. I think the extension of DRI2InfoRec is probably okay, if the server checks the version. The server checks the version and flat rejects drivers with the old version. Ditto for new drivers with an old server. Like I said to Michel, we discussed this quite a bit... you, Michel, and Kristian all participated in those discussions, so I'm a little confused why everyone is so surprised about this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpKcFgACgkQX1gOwKyEAw+7zACfXWfqFC3J6dhee5M/uwA+IJ0a W9MAnAzchMvL9pJA0K8weXYzGN44ZkIS =nx8B -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. I've read the reports, and I'm treating this as a bug at this point -- I need to see more information about how the ABI is broken so we can figure out how to fix it. You rejected backports before based on breaking ABI. Yup, let's figure out how to fix it. This ABI breakage is unintentional, I believe. I'm not sure you can easily. The DRI2BufferRec changes size (adds a new int format), the driver mallocs an array of these, so you are probably pwned in that case. I think the extension of DRI2InfoRec is probably okay, if the server checks the version. The server checks the version and flat rejects drivers with the old version. Ditto for new drivers with an old server. Like I said to Michel, we discussed this quite a bit... you, Michel, and Kristian all participated in those discussions, so I'm a little confused why everyone is so surprised about this. Essentially if a distro pushes out this X server, and has a KMS/DRI2 setup already working this will break it, unless they also push out a new X driver set (granted this is just Intel + maybe ATI) However you look at it this is still a broken ABI from the user POV I'm not saying its good or bad broken. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Monitor and Keyboard disbled during the startup
I have a the error below after the last update. suggestions? Thanks in advance, Alessandro This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.6.1.901 (1.6.2 RC 1) Release Date: 2009-5-8 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30-gentoo-r1 i686 Current Operating System: Linux gentictu 2.6.30-gentoo-r1 #1 SMP PREEMPT Thu Jun 11 22:46:19 CEST 2009 i686 Build Date: 29 June 2009 08:52:08PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Jun 29 20:57:41 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Screen Screen1 (1) (**) | |--Monitor LVDS1 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/Type1/ does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in /usr/share/fonts/100dpi/. Entry deleted from font path. (Run 'mkfontdir' on /usr/share/fonts/100dpi/). (**) FontPath set to: built-ins, /usr/share/fonts/freefont-ttf/, /usr/share/fonts/dejavu/, /usr/share/fonts/75dpi/, /usr/share/fonts/corefonts/, /usr/share/fonts/freefonts/, /usr/share/fonts/intlfonts/, /usr/share/fonts/ttf-bitstream-vera/, /usr/share/fonts/terminus/, /usr/share/fonts/misc/, /usr/share/fonts/75dpi/ (**) ModulePath set to /usr/lib/xorg/modules (**) Extension Composite is enabled (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Loader magic: 0x1d84 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 7 (--) PCI:*(0:0:2:0) 8086:2a02:10cf:13f8 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 3, Mem @ 0xfe00/1048576, 0xe000/268435456, I/O @ 0x1800/8 (--) PCI: (0:0:2:1) 8086:2a03:10cf:13f8 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 3, Mem @ 0xfe10/1048576 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded. This was enabled by default and also specified in the config file. (II) dri will be loaded. This was enabled by default and also specified in the config file. (II) dri2 will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: record (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.6.1.901, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: dri (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor=X.Org Foundation compiled for 1.6.1.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.6.1.901, module version = 1.0.0 Module class: X.Org Server
