From tom at dbservice.com Sat Dec 1 00:35:08 2007 From: tom at dbservice.com (Tomas Carnecky) Date: Sat, 01 Dec 2007 09:35:08 +0100 Subject: Multi X-session setup In-Reply-To: <9209238f53698abf6c7d1b3d47fc17dc@localhost> References: <9209238f53698abf6c7d1b3d47fc17dc@localhost> Message-ID: <47511CBC.4080608@dbservice.com> tech at tnet.no wrote: > I don't have this equipment yet, but I will get it later today hopefully. > > Motherboard: MSI K9AG NEO2-Digital, AMD 690G+SB600, Socket-AM2, ATX,DDR2, DVI+HDMI, PCI-Ex16 with integrated ATI Radeon X1250 GPU. > PCI-Expreses video-card: Sapphire Radeon HD 2400 PRO 256MB DDR2, DVI-I/Tv-out/HDMI > > What I want is two have two seperate X sessions, with two displays, one with tv or projector, the other my LCD monitor. Also, only one set of keyboard and mouse. > > The tv/projector one will be mainly be used to view high-quality video (1280p or 720i in xvid or x264) through mplayer, the other monitor will just be for general stuff. ( Just a little correction: 1280p doesn't exist, it's either 1080p/i or 720p/i ) > I want the video/picture at the X-sessions to be active at the same time, but with ability to switch between what X-session mouse and keyboard will be active/controlling to. To have two separate X sessions, you'd have to start two instances of the xserver, each with its own "ServerLayout" in xorg.conf. Each instance would run on its own VT and you'd have to switch between those with ctrl+alt+Fx. But in this setup I don't think it's possible that the two xservers have both monitors enabled at all times, meaning that the inactive xserver will disable its monitor. I have never tried that setup so don't take my word for it. > I know there's an option for dual screen set-up, but this is not something I quite feel comfortable with. Why not? > What driver that will be used for whatever card is not something I worry about either, I don't mind if there's two different drivers or if any of them is closed source. > > Is this possible and if so could someone hint me to how to do it, either in an explanation or a reference to documentation? > If it is not, could someone please list similiar options I could try? I suggest you start only one xserver and configure two independent screens in xorg.conf. That allows you to move the mouse from one screen to the other (which is very quick compared to a VT switch), yet the screens remain independent in the meaning that you can't drag windows between the two screens. If you also use xrandr you'd be able to disable one screen if it's not in use! I'm currently running that setup with one nvidia card, two monitors, using the nvidia blob. I could help you with the basic setup but I have no idea about which ati driver you'd need. There's plenty of documentation about multi-screen setups on the internet. tom From nicolas.mailhot at laposte.net Sat Dec 1 01:06:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 01 Dec 2007 10:06:47 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <475094D8.9000608@codewiz.org> References: <1192722650.30588.1.camel@rousalka.dyndns.org> <1195038746.3708.8.camel@rousalka.dyndns.org> <1195118577.17511.17.camel@rousalka.dyndns.org> <20071115094337.GA489@intune.research.nokia.com> <1195122422.3047.12.camel@rousalka.dyndns.org> <20071115103121.GA1771@intune.research.nokia.com> <1195124070.3227.3.camel@rousalka.dyndns.org> <20071115105733.GA2493@intune.research.nokia.com> <1195125029.3026.3.camel@rousalka.dyndns.org> <20071115112826.GA3307@intune.research.nokia.com> <1195126692.3026.5.camel@rousalka.dyndns.org> <475094D8.9000608@codewiz.org> Message-ID: <1196500008.16896.0.camel@rousalka.dyndns.org> Le vendredi 30 novembre 2007 ? 17:55 -0500, Bernardo Innocenti a ?crit : > > Nicolas Mailhot wrote: > > Le jeudi 15 novembre 2007 ? 13:28 +0200, Daniel Stone a ?crit : > >> On Thu, Nov 15, 2007 at 12:10:29PM +0100, ext Nicolas Mailhot wrote: > >>> Le jeudi 15 novembre 2007 ? 12:57 +0200, Daniel Stone a ?crit : > >>>> It doesn't look like it's even tried to connect to D-Bus or HAL. Is it > >>>> linked to both? > >>> I guess only Ajax can properly answer this, but you have the build logs > >>> and sources there: > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=240429 > >>> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-server/ > >> checking for DBUS... no > >> checking for HAL... no > > > > Seems I need to poke ajax then. Thanks > > I've just built RPMs of 1.4.99 for the OLPC-2 with hal and dbus enabled. > The relevant packages are here: > > http://www.codewiz.org/pub/xorg1499/ Thanks! I'd really like this to be fixed in rawhide though. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jennytharayil at gmail.com Sat Dec 1 02:33:14 2007 From: jennytharayil at gmail.com (jenny tc) Date: Sat, 1 Dec 2007 16:03:14 +0530 Subject: Is it possible to have keyboard or mouse with Xvfb ? Message-ID: <47b5508f0712010233h67be9be1i5d437c7108d3e90@mail.gmail.com> Hi Is it possible to have a keyboard or mouse or any input device with Xvfb? I am using Xvfb with the X11R7.3. If possible , any special configuration needed? If not any modifiction of the vfb code will do it? -Jenny -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcpa at mandriva.com.br Sat Dec 1 04:49:42 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Sat, 01 Dec 2007 10:49:42 -0200 Subject: Xorg Input Hotplugging In-Reply-To: <4750FBF8.2040405@codewiz.org> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196470645.3148.6.camel@localhost.localdomain> <4750FBF8.2040405@codewiz.org> Message-ID: <20071201104942.uot4da8kfj6so8ss@webmail.conectiva.com.br> Quoting Bernardo Innocenti : > Sergio Monteiro Basto wrote: > >> yap, edev still have a bunch of problems with xserver 1.4 + (one of than >> is not have cursors keys if you want your native language keyboard >> layout), I simply install an edev version for xserver-1.3 which don't >> load at all. Maybe this is related to https://bugs.freedesktop.org/show_bug.cgi?id=13361 The main problem is that there isn't a mapping from hal devices to xorg.conf devices, and the hal code in the X Server, if hal is "properly configured", will load a new module to handle an input device that already have a module loaded for it, as listed in xorg.conf. For example, if I change hal to use the mouse driver for my ps2 mouse, and have an input device section in xorg.conf also using the mouse driver, I will get double clicks for every mouse click. Simillar problems will happen with the keyboard, like arrow keys not working, in my case it was mapping to Print Screen, and calling ksnapshot when running kde. But other different problems may arise if the xorg.conf specifies one driver and hal specifies another, and both drivers are loaded. For the moment, I disabled hal support in the Mandriva X Server a few days ago as I got no reply to the bugzilla above, but hope to work again on it in the next days. I did not finish the patch because it may be required some guessing, or some detail I am missing :-) that would allow mapping hal devices to xorg.conf devices, and then, code in the server would notice it and load only one driver for the device. > Hmm... Our cursor keys just work. > > I noticed that we loose them if we mistakenly load the "xfree86" > keycodes instead of the "evdev" ones. > > You may have to override the xserver defaults with setxkbmap or > by setting the XKB properties in x11-server.fdi. > > >> And I work with synaptics git drive which emulates very well 3rd button >> of my notebook. And usb mouse works in hotplugging very well too. > > Does the USB mouse use evdev_drv or mouse_drv? > > -- > \___/ > |___| Bernardo Innocenti - http://www.codewiz.org/ > \___\ One Laptop Per Child - http://www.laptop.org/ Paulo From geopal at hotmail.com Sat Dec 1 05:26:31 2007 From: geopal at hotmail.com (Ford Prefect) Date: Sat, 1 Dec 2007 13:26:31 +0000 Subject: RandR module version, cant get V1.2 Message-ID: Hello all, I am using a Toshiba notebook with the Intel chip set 945GM. Having the painfull problem of not being able to on-thy-fly plug in external displays (i.e. projectors) I tried to investigate and came up with the conclusion that I would have to use the RandR extension in it's current version 1.2 to overcome all this limitations with a static setup. I am running openSuSE V10.3 on the machine which comes with an Xorg V7.2. So the first thing I did was an upgrade to Xorg V7.3. Also created a proper xorg.conf according to the various howtos that are around. The xorg.conf also was changed to use the 'intel' driver instead of the 'i810'. And now comes the question, randr is stiff-necked in reporting an older version: xrandr -v --verbose Server reports RandR version 1.1 SZ: Pixels Physical Refresh *0 1280 x 1024 ( 376mm x 301mm ) *60 1 1280 x 800 ( 376mm x 301mm ) 60 2 1024 x 768 ( 376mm x 301mm ) 60 3 800 x 600 ( 376mm x 301mm ) 60 4 640 x 480 ( 376mm x 301mm ) 60 Current rotation - normal Current reflection - none Rotations possible - normal Reflections possible - none Setting size to 0, rotation to normal Setting reflection on neither axis Here is the Xserver output: Xorg -version X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux cpreqjpa 2.6.22.12-0.1-default #1 SMP 2007/11/06 23:05:18 UTC i686 Build Date: 19 October 2007 02:15:54AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present ... and I can find this in my log file (extract): (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE With my current version I can't achieve what I was hoping to do. One example is to plug in a projector and being able to run it with a proper resolution without having to plug it in at boot time or having to restart the Xserver. Can someone point me into the correct direction please? What am I doing (or assuming) wrong? Any hint is highly appreciated! Thank you! _________________________________________________________________ Die neue Version vom Windows Live Messenger ist da! http://get.live.com/messenger/overview From bernie at codewiz.org Sat Dec 1 05:56:27 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sat, 01 Dec 2007 08:56:27 -0500 Subject: Xorg Input Hotplugging In-Reply-To: <1196500008.16896.0.camel@rousalka.dyndns.org> References: <1192722650.30588.1.camel@rousalka.dyndns.org> <1195038746.3708.8.camel@rousalka.dyndns.org> <1195118577.17511.17.camel@rousalka.dyndns.org> <20071115094337.GA489@intune.research.nokia.com> <1195122422.3047.12.camel@rousalka.dyndns.org> <20071115103121.GA1771@intune.research.nokia.com> <1195124070.3227.3.camel@rousalka.dyndns.org> <20071115105733.GA2493@intune.research.nokia.com> <1195125029.3026.3.camel@rousalka.dyndns.org> <20071115112826.GA3307@intune.research.nokia.com> <1195126692.3026.5.camel@rousalka.dyndns.org> <475094D8.9000608@codewiz.org> <1196500008.16896.0.camel@rousalka.dyndns.org> Message-ID: <4751680B.6050902@codewiz.org> On 12/01/07 04:06, Nicolas Mailhot wrote: >> http://www.codewiz.org/pub/xorg1499/ > > Thanks! I'd really like this to be fixed in rawhide though. I offered a few times to help with this integration work in Fedora, but so far Ajax has not been answering my mail. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From daniel at fooishbar.org Sat Dec 1 06:00:39 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sat, 1 Dec 2007 14:00:39 +0000 Subject: Xorg Input Hotplugging In-Reply-To: <20071201104942.uot4da8kfj6so8ss@webmail.conectiva.com.br> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196470645.3148.6.camel@localhost.localdomain> <4750FBF8.2040405@codewiz.org> <20071201104942.uot4da8kfj6so8ss@webmail.conectiva.com.br> Message-ID: <20071201140039.GL6534@fooishbar.org> On Sat, Dec 01, 2007 at 10:49:42AM -0200, pcpa at mandriva.com.br wrote: > The main problem is that there isn't a mapping from hal devices > to xorg.conf devices, and the hal code in the X Server, if hal is > "properly configured", will load a new module to handle an input > device that already have a module loaded for it, as listed in > xorg.conf. With evdev, this isn't a problem. EVIOCGRAB means that even if you have the 'mouse' driver on /dev/input/mice and evdev drivers on /dev/input/eventN, you'll never get duplicate events. For the mouse and kbd drivers, yes, this is an issue. > For example, if I change hal to use the mouse driver for my ps2 > mouse, and have an input device section in xorg.conf also using > the mouse driver, I will get double clicks for every mouse click. I'm not really sure why you'd do that, but yes, I do see the problem. I guess one solution is just to remove the keyboard and mouse fallbacks in the HAL FDI, and only ever do drivers that we know don't intefere with others. > Simillar problems will happen with the keyboard, like arrow keys > not working, in my case it was mapping to Print Screen, and calling > ksnapshot when running kde. That's just your XKB model being set wrong. I know the underlying infrastructure works, because I've tested with multiple keyboards having different layouts, etc. > For the moment, I disabled hal support in the Mandriva X Server > a few days ago as I got no reply to the bugzilla above, but hope > to work again on it in the next days. I did not finish the patch > because it may be required some guessing, or some detail I am > missing :-) that would allow mapping hal devices to xorg.conf > devices, and then, code in the server would notice it and load > only one driver for the device. The patch as it is is obviously extremely DDX-dependent, and thus breaks KDrive and others horribly. We already have NewInputDeviceRequest, so handling it in the DDX would be utterly trivial. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ander at c3sl.ufpr.br Sat Dec 1 05:39:02 2007 From: ander at c3sl.ufpr.br (Ander Conselvan de Oliveira) Date: Sat, 1 Dec 2007 11:39:02 -0200 Subject: multiple instances of X In-Reply-To: <1196467584.19126.3.camel@marcio-desktop> References: <1196467584.19126.3.camel@marcio-desktop> Message-ID: <200712011139.02541.ander@c3sl.ufpr.br> Em Friday 30 November 2007 22:06:24 Marcio Kleber Torres escreveu: > ?la Bernardo Innocenti, visit this link, and see the project multilinux, > or mount several terminals with a unique CPU, but here you use the > Xephyr to get up. More so is not possible to do with the new version of > UBUNTU 7.10. Then see the link of the project. > http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu >_7.04 There are some issues with running several instances of the xserver. The idea behind the "xephyr multiseat solution" is to take advantage of the xserver module called RAC (Resource Access Control). Currently, there's people working on a vga arbiter, that will allow several instances of the xserver to run without stepping in each other's toes. They released some code [0] that you could help to test. Regards, Ander [0] http://lists.freedesktop.org/archives/xorg/2007-November/030420.html From pekane52 at gmail.com Sat Dec 1 10:01:24 2007 From: pekane52 at gmail.com (Pat Kane) Date: Sat, 1 Dec 2007 12:01:24 -0600 Subject: RandR module version, cant get V1.2 In-Reply-To: References: Message-ID: On Dec 1, 2007 7:26 AM, Ford Prefect wrote: > > Hello all, > I am using a Toshiba notebook with the Intel chip set 945GM. Having the painfull problem Ford, remember to not *PANIC*, do you have your towel? I think the answer to your question might be 42, or maybe in the HHG v11.8 From alexdeucher at gmail.com Sat Dec 1 10:11:14 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Sat, 1 Dec 2007 13:11:14 -0500 Subject: RandR module version, cant get V1.2 In-Reply-To: References: Message-ID: On Dec 1, 2007 8:26 AM, Ford Prefect wrote: > > Hello all, > I am using a Toshiba notebook with the Intel chip set 945GM. Having the painfull problem of not being able to on-thy-fly plug in external displays (i.e. projectors) I tried to investigate and came up with the conclusion that I would have to use the RandR extension in it's current version 1.2 to overcome all this limitations with a static setup. > > I am running openSuSE V10.3 on the machine which comes with an Xorg V7.2. So the first thing I did was an upgrade to Xorg V7.3. Also created a proper xorg.conf according to the various howtos that are around. The xorg.conf also was changed to use the 'intel' driver instead of the 'i810'. > are you running the i810 or the intel driver? intel supports randr 1.2; i810 does not. Alex From jbarnes at virtuousgeek.org Sat Dec 1 10:30:59 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sat, 1 Dec 2007 10:30:59 -0800 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <1196473279.3899.5.camel@toddl> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <1196435628.5023.22.camel@x60.rd.nextstepsolutions.co.uk> <1196473279.3899.5.camel@toddl> Message-ID: <200712011030.59694.jbarnes@virtuousgeek.org> On Friday, November 30, 2007 5:41 pm Todd Johnson wrote: > I've gotten it working on my work PC at work. It does have many > problems like not being able to restart X or logout. However it > works kindof. This is on Fedora Core 8 but should be similar. > > Section "Device" > Identifier "Videocard0" > # Driver "intel" > Driver "i810" > # Option "Monitor-VGA" "monitor1" > # Option "Monitor-TMDS-1" "monitor0" > Option "Clone" "false" > Option "MonitorLayout" "DFP,CRT" > Option "VideoRam" "131072" > BusId "PCI:0:2:0" > Screen 0 > EndSection Ok, this is kind of weird. F8 has a recent version of the "intel" driver that should support your SDVO configuration. What happens if you follow the dual head configuration instructions at http://www.intellinuxgraphics.com/dualhead.html? If that doesn't work, we may have a driver bug, and it would be good to collect some info about it... Thanks, Jesse From jbarnes at virtuousgeek.org Sat Dec 1 10:42:41 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sat, 1 Dec 2007 10:42:41 -0800 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <1196435628.5023.22.camel@x60.rd.nextstepsolutions.co.uk> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <47502C480200009E00000F0E@amaftp1.amatic1.com> <1196435628.5023.22.camel@x60.rd.nextstepsolutions.co.uk> Message-ID: <200712011042.41812.jbarnes@virtuousgeek.org> On Friday, November 30, 2007 7:13 am Chris Sykes wrote: > On Fri, 2007-11-30 at 15:29 +0100, Clemens Kirchgatterer wrote: > > hi! > > > > > I'm having trouble enabling dual-head (not cloned) video output > > > using the on-board intel 945G graphics chipset and a plug-in PCIe > > > SDVO card. Both outputs are analogue VGA. > > > > i had the same goal and it took me nearly a week to come up with a > > working xorg.conf. i use the latest intel driver from git and the > > following conf works for me: > > What platform/distro are you using? If it's centos 5, how painful > was it getting the pre-requisites for building the latest driver. I > was under the impression that the latest intel driver would require a > newer X server release than is included in centos 5 (7.1.1). Hm, yeah it might. The driver in CentOS 5 depends on the video BIOS to setup outputs and modes. It sounds like yours doesn't support the config you want. The newer driver programs this stuff directly, so it's a lot more flexible, but like you say it depends on some new code in the server. Jesse From pixel at mandriva.com Sat Dec 1 11:17:01 2007 From: pixel at mandriva.com (Pixel) Date: Sat, 01 Dec 2007 20:17:01 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <1196454244.4700.3.camel@juerg-pd.bitron.ch> (=?iso-8859-1?Q?=22J=FCrg?= Billeter"'s message of "Fri\, 30 Nov 2007 21\:24\:04 +0100") References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> Message-ID: > On Fri, 2007-11-30 at 21:15 +0300, Andrey Borzenkov wrote: >> On Thursday 15 November 2007, Nicolas Mailhot wrote: >> > > at least one of the properties for your devices should contain their >> > > usb vendor/product IDs. >> > > >> > > other properties xorg understands for keyboards: >> > > - input.xkb.rules >> > > - input.xkb.model >> >> Should not it be actually "evdev" always? As evdev is really the only driver >> that would work? agreed. IMO XkbModel should not even be supported by evdev driver Daniel Stone writes: [...] >> Simillar problems will happen with the keyboard, like arrow keys >> not working, in my case it was mapping to Print Screen, and calling >> ksnapshot when running kde. > > That's just your XKB model being set wrong. I know the underlying > infrastructure works, because I've tested with multiple keyboards having > different layouts, etc. agreed. the "arrow keys" syndrom :) it is caused by apps like gnome-keyboard-properties which sets the xkb model when the user asked for some "internet" keyboard model. (cf http://lists.freedesktop.org/archives/xorg/2007-November/030433.html) out of the 134 "model"s possible (rules/xorg.lst), 127 are based on keycodes/xfree86. if you apply one of these 127 models to a evdev keyboard, you can be *sure* it will be wrong. here is the list of keysyms that will *always* be broken when applying a keycodes/xfree86 based model on evdev keyboard: : Home Up Prior Left Right End Down Next Insert Delete : KP_Enter KP_Divide XF86_Ungrab KP_Equal : Mode_switch Control_R ISO_Level3_Shift Super_L Multi_key Menu : Pause Break Print Sys_Req internet & multimedia keys will always be broken too. From sergio at sergiomb.no-ip.org Sat Dec 1 13:31:54 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 01 Dec 2007 21:31:54 +0000 Subject: Xorg Input Hotplugging In-Reply-To: References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> Message-ID: <1196544714.28623.19.camel@localhost.localdomain> On Sat, 2007-12-01 at 20:17 +0100, Pixel wrote: > > On Fri, 2007-11-30 at 21:15 +0300, Andrey Borzenkov wrote: > >> On Thursday 15 November 2007, Nicolas Mailhot wrote: > >> > > at least one of the properties for your devices should contain their > >> > > usb vendor/product IDs. > >> > > > >> > > other properties xorg understands for keyboards: > >> > > - input.xkb.rules > >> > > - input.xkb.model > >> > >> Should not it be actually "evdev" always? As evdev is really the only driver > >> that would work? > > agreed. IMO XkbModel should not even be supported by evdev driver > > > Daniel Stone writes: > > [...] > > >> Simillar problems will happen with the keyboard, like arrow keys > >> not working, in my case it was mapping to Print Screen, and calling > >> ksnapshot when running kde. > > > > That's just your XKB model being set wrong. I know the underlying > > infrastructure works, because I've tested with multiple keyboards having > > different layouts, etc. > > agreed. the "arrow keys" syndrom :) > > it is caused by apps like gnome-keyboard-properties which sets the xkb > model when the user asked for some "internet" keyboard model. > (cf http://lists.freedesktop.org/archives/xorg/2007-November/030433.html) > > out of the 134 "model"s possible (rules/xorg.lst), 127 are based on > keycodes/xfree86. if you apply one of these 127 models to a evdev > keyboard, you can be *sure* it will be wrong. > > here is the list of keysyms that will *always* be broken when applying > a keycodes/xfree86 based model on evdev keyboard: > > : Home Up Prior Left Right End Down Next Insert Delete > : KP_Enter KP_Divide XF86_Ungrab KP_Equal > : Mode_switch Control_R ISO_Level3_Shift Super_L Multi_key Menu > : Pause Break Print Sys_Req > > internet & multimedia keys will always be broken too. Hi, I use kde and don't set any xkb model, kde could apply a xkb model but I prefer put the keyboard configuration on xorg.conf. Questions: if evdev breaks so many things what is the point on use it ? On xorg.conf what should be the configuration for pt xkblayout on an compaq/HP laptop, presario model ? with evdev module. you write "set keycodes/xfree86 based model on evdev keyboard breaks ...", so, have we some command to unset keycodes/xfree86 based model ? Thanks, -- S?rgio M. B. From geopal at hotmail.com Sat Dec 1 14:18:44 2007 From: geopal at hotmail.com (Ford Prefect) Date: Sat, 1 Dec 2007 22:18:44 +0000 Subject: RandR module version, cant get V1.2 Message-ID: > > are you running the i810 or the intel driver? intel supports randr > 1.2; i810 does not. > Running this driver (extract from log): (II) Loading /usr/lib/xorg/modules//drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.4.0, module version = 2.1.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 So that makes it the 'intel' driver, right? _________________________________________________________________ Die neue Version vom Windows Live Messenger ist da! http://get.live.com/messenger/overview From pcpa at mandriva.com.br Sat Dec 1 14:24:15 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Sat, 01 Dec 2007 20:24:15 -0200 Subject: Xorg Input Hotplugging In-Reply-To: <1196544714.28623.19.camel@localhost.localdomain> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> Message-ID: <20071201202415.70wtxl9km75csc84@webmail.conectiva.com.br> Quoting Sergio Monteiro Basto : (replying only to list because my other reply, to other message, earlier today is still waiting moderator approval due too much recipients...) > On Sat, 2007-12-01 at 20:17 +0100, Pixel wrote: >> > On Fri, 2007-11-30 at 21:15 +0300, Andrey Borzenkov wrote: >> >> On Thursday 15 November 2007, Nicolas Mailhot wrote: >> >> > > at least one of the properties for your devices should contain their >> >> > > usb vendor/product IDs. >> >> > > >> >> > > other properties xorg understands for keyboards: >> >> > > - input.xkb.rules >> >> > > - input.xkb.model >> >> >> >> Should not it be actually "evdev" always? As evdev is really the >> only driver >> >> that would work? >> >> agreed. IMO XkbModel should not even be supported by evdev driver Hal has also an option to "not handle" a device. Maybe this could be used for keyboards and mouses using the kbd and mouse driver, i.e. for desktops where the user isn't going to attach/detach input devices during a X session. Either way, if hal is configured to use the kbd or mouse driver, and there isn't an input session for the device in xorg.conf, it "just works" (once the bug in handling string lists is fixed), but may require some "magic" to specify multiple layouts or other xkb options. >> Daniel Stone writes: >> >> [...] >> >> >> Simillar problems will happen with the keyboard, like arrow keys >> >> not working, in my case it was mapping to Print Screen, and calling >> >> ksnapshot when running kde. >> > >> > That's just your XKB model being set wrong. I know the underlying >> > infrastructure works, because I've tested with multiple keyboards having >> > different layouts, etc. >> >> agreed. the "arrow keys" syndrom :) That can easily happen if an there is an entry in xorg.conf telling X to use the kbd driver, and then evdev is also loaded using a different setup, usually the default pc105/us. Either way, if xorg.conf is configured to use evdev, problems may still happen as there will exist 2 X drivers managing the keyboard. >> it is caused by apps like gnome-keyboard-properties which sets the xkb >> model when the user asked for some "internet" keyboard model. >> (cf http://lists.freedesktop.org/archives/xorg/2007-November/030433.html) >> >> out of the 134 "model"s possible (rules/xorg.lst), 127 are based on >> keycodes/xfree86. if you apply one of these 127 models to a evdev >> keyboard, you can be *sure* it will be wrong. >> >> here is the list of keysyms that will *always* be broken when applying >> a keycodes/xfree86 based model on evdev keyboard: >> >> : Home Up Prior Left Right End Down Next Insert Delete >> : KP_Enter KP_Divide XF86_Ungrab KP_Equal >> : Mode_switch Control_R ISO_Level3_Shift Super_L Multi_key Menu >> : Pause Break Print Sys_Req >> >> internet & multimedia keys will always be broken too. It seens interesting that, in the computer I am using now it is using the kbd driver, and "setxkbmap -keycodes evdev" breaks the arrow keys, but "setxkbmap -print" does not show any changes; running "setxkbmap -keycodes xfree86" fixes the problem, but still no changes in "setxkbmap -print". And the diff of "setxkbmap -print | xkbcomp -xkb - -o .xkb" generates identical output. > Hi, I use kde and don't set any xkb model, kde could apply a xkb model > but I prefer put the keyboard configuration on xorg.conf. > Questions: > if evdev breaks so many things what is the point on use it ? There is "gratuitous" incompatibility with xfree86 keycodes in the xkb configuration files, I believe the changes are not a "hey, I am different" change, so it should be incompatible to fix some issue with xfree86 keycodes, but maybe the xfree86 keycodes should be fixed in that case... It has special handling done at kernel level, but afaik it is Linux specific, i.e. BSD users probably are not having this problem. I trust the kernel level implementation is correct, but the X Server code is somewhat buggy, as the code that communicates with hal basically ignore the existence of xorg.conf, and what code elsewhere does to load the input devices specified in xorg.conf. But it has a huge infrastructure behind it, involving kernel, hal, x server and it uses xml configuration files !!! So it must be the next step in the technology > On xorg.conf what should be the configuration for pt xkblayout on an > compaq/HP laptop, presario model ? with evdev module. > > you write "set keycodes/xfree86 based model on evdev keyboard > breaks ...", so, have we some command to unset keycodes/xfree86 based > model ? If you are using an external keyboard, probably you will need to use evdev (just remove the keyboard input section in xorg.conf). You can try to change the default values by hand in the file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi and restart the related programs, or temporalily change using some program like hal-set-property. Otherwise, try removing the evdev x11-input package, and make sure the kbd driver is specified in xorg.conf. > Thanks, > -- > S?rgio M. B. Paulo From alexdeucher at gmail.com Sat Dec 1 14:48:59 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Sat, 1 Dec 2007 17:48:59 -0500 Subject: RandR module version, cant get V1.2 In-Reply-To: References: Message-ID: On Dec 1, 2007 5:18 PM, Ford Prefect wrote: > > > > > are you running the i810 or the intel driver? intel supports randr > > 1.2; i810 does not. > > > > Running this driver (extract from log): > > (II) Loading /usr/lib/xorg/modules//drivers/intel_drv.so > (II) Module intel: vendor="X.Org Foundation" > compiled for 1.4.0, module version = 2.1.1 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 2.0 > > So that makes it the 'intel' driver, right? yes. so in that case you may have an old version of xrandr or xrandr protocol headers installed. Did you install from source or did you use distro packages? Alex From nicolas.mailhot at laposte.net Sat Dec 1 15:24:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Dec 2007 00:24:19 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <1196544714.28623.19.camel@localhost.localdomain> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> Message-ID: <1196551459.4351.12.camel@rousalka.dyndns.org> Le samedi 01 d?cembre 2007 ? 21:31 +0000, Sergio Monteiro Basto a ?crit : > > if evdev breaks so many things what is the point on use it ? evdev does not break so many things. What breaks so many things is using a non-evdev model with the evdev protocol (as others have already written this should have been disallowed instead of letting people shot themselves in the feet) I have one of the aforementioned multimedia keyboards, and there are three ways to configure it: a. with old kbd driver & legacy model: stuff like arrows will work, but multimedia keys will return garbage b. with evdev protocol and legacy model: arrows will break but multimedia keys will work c. with evdev protocol and evdev model: everything just works Most of the people complaining of evdev tried b. because evdev is underdocumented, it's a natural mistake to make and it's f* stupid to have made it a valid config in the first place. Note that in non-hal config latest xorg resets various things to legacy defaults, which means various things will break for people who configured evdev before, which will be blamed on evdev instead of on not biting the bullet and making evdev the default, which would have made sure the known-broken mixed configs never occured. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sergio at sergiomb.no-ip.org Sat Dec 1 19:45:38 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sun, 02 Dec 2007 03:45:38 +0000 Subject: Xorg Input Hotplugging In-Reply-To: <1196551459.4351.12.camel@rousalka.dyndns.org> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> <1196551459.4351.12.camel@rousalka.dyndns.org> Message-ID: <1196567138.5738.25.camel@localhost.localdomain> On Sun, 2007-12-02 at 00:24 +0100, Nicolas Mailhot wrote: > there are three ways to configure it: > a. with old kbd driver & legacy model: stuff like arrows will work, > but multimedia keys will return garbage > b. with evdev protocol and legacy model: arrows will break but > multimedia keys will work > c. with evdev protocol and evdev model: everything just works OK!, thanks, finally I put the "configuration c", working on my laptop. How I put evdev work ? what configurations in xorg.conf ? A simple example could be nice, so here it is: I HAVE TO: ADD on Keyboard InputDevice Option "Device" "/dev/input/event1" comment (with #) Option "XkbModel" "presario" keep Option "XkbLayout" "pt" and change Option Driver from "kdb" to "evdev" Only this way I get my keyboard working properly. Note: man evdev says about option Device: "Please note that use of this option is strongly discouraged" but without than Xorg don't load the layout pt. For Mouse InputDevice just change Option Driver from "mouse" to "evdev", improves the detection of mouse hardware, in my case I got a new "Macintosh mouse button emulation" and a new "Video Bus" I still use: Section "InputDevice" Identifier "Synaptics" Driver "synaptics" ... > Most of the people complaining of evdev tried b. because evdev is > underdocumented, it's a natural mistake to make and it's f* stupid to > have made it a valid config in the first place. > Agree, evdev , shouldn't try use old xkbmodels > Note that in non-hal config latest xorg resets various things to > legacy > defaults, which means various things will break for people who > configured evdev before, which will be blamed on evdev instead of on > not > biting the bullet and making evdev the default, which would have made > sure the known-broken mixed configs never occured. Thanks all, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jennytharayil at gmail.com Sat Dec 1 20:06:03 2007 From: jennytharayil at gmail.com (jenny tc) Date: Sun, 2 Dec 2007 09:36:03 +0530 Subject: Anybody please reply:Is it possible to have keyboard or mouse with Xvfb ? Message-ID: <47b5508f0712012006h66103fb4m8f8d4914d1c26564@mail.gmail.com> Hi Is it possible to have a keyboard or mouse or any input device with Xvfb? I am using Xvfb with the X11R7.3. If possible , any special configuration needed? If not any modifiction of the vfb code will do it? -Jenny -------------- next part -------------- An HTML attachment was scrubbed... URL: From todd at toddejohnson.net Sat Dec 1 20:51:22 2007 From: todd at toddejohnson.net (Todd Johnson) Date: Sat, 01 Dec 2007 22:51:22 -0600 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <200712011030.59694.jbarnes@virtuousgeek.org> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <1196435628.5023.22.camel@x60.rd.nextstepsolutions.co.uk> <1196473279.3899.5.camel@toddl> <200712011030.59694.jbarnes@virtuousgeek.org> Message-ID: <1196571082.8230.2.camel@toddl> I had tried it. It gave me many errors. It complained about running out of memory and several other things. I posted the logs and old config at http://www.fedoraforum.org/forum/showthread.php?t=172544 On Sat, 2007-12-01 at 10:30 -0800, Jesse Barnes wrote: > On Friday, November 30, 2007 5:41 pm Todd Johnson wrote: > > I've gotten it working on my work PC at work. It does have many > > problems like not being able to restart X or logout. However it > > works kindof. This is on Fedora Core 8 but should be similar. > > > > Section "Device" > > Identifier "Videocard0" > > # Driver "intel" > > Driver "i810" > > # Option "Monitor-VGA" "monitor1" > > # Option "Monitor-TMDS-1" "monitor0" > > Option "Clone" "false" > > Option "MonitorLayout" "DFP,CRT" > > Option "VideoRam" "131072" > > BusId "PCI:0:2:0" > > Screen 0 > > EndSection > > Ok, this is kind of weird. F8 has a recent version of the "intel" > driver that should support your SDVO configuration. What happens if > you follow the dual head configuration instructions at > http://www.intellinuxgraphics.com/dualhead.html? > > If that doesn't work, we may have a driver bug, and it would be good to > collect some info about it... > > Thanks, > Jesse From tech at tnet.no Sat Dec 1 21:35:02 2007 From: tech at tnet.no (tech at tnet.no) Date: Sun, 2 Dec 2007 6:35:02 +0100 Subject: Multi X-session setup In-Reply-To: <1196502072.6441.1.camel@marcio-desktop> References: <1196502072.6441.1.camel@marcio-desktop> Message-ID: <42ca0f4a4eb3780eaaf9ad0bb79e0ded@localhost> I do not speak this language, but it seems to be a multiseat setup, and seems to require to keyboards, which is not exactly what I want :( If I'm interepting this wrongly, could you explain how this concept is? Because I do not want to keyboards, I want two sessions active at both sessions with one keyboard/mouse, with ability to disable/activate them on each sessions. If this is not a suitable solution for this, is there anyone else than can help? Thanks you. On Sat, 01 Dec 2007 07:41:12 -0200, Marcio Kleber Torres wrote: > Hello. > > See this link, I think this is what you want, in any way it is the > beginning. > > Thank you. > > http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu_7.04 > > > > > Em S?b, 2007-12-01 ?s 06:30 +0100, tech at tnet.no escreveu: >> Hello. >> >> I don't have this equipment yet, but I will get it later today > hopefully. >> >> Motherboard: MSI K9AG NEO2-Digital, AMD 690G+SB600, Socket-AM2, > ATX,DDR2, DVI+HDMI, PCI-Ex16 with integrated ATI Radeon X1250 GPU. >> PCI-Expreses video-card: Sapphire Radeon HD 2400 PRO 256MB DDR2, > DVI-I/Tv-out/HDMI >> >> What I want is two have two seperate X sessions, with two displays, one > with tv or projector, the other my LCD monitor. Also, only one set of > keyboard and mouse. >> >> The tv/projector one will be mainly be used to view high-quality video > (1280p or 720i in xvid or x264) through mplayer, the other monitor will > just be for general stuff. >> >> I want the video/picture at the X-sessions to be active at the same > time, but with ability to switch between what X-session mouse and keyboard > will be active/controlling to. >> >> I know there's an option for dual screen set-up, but this is not > something I quite feel comfortable with. >> >> What driver that will be used for whatever card is not something I worry > about either, I don't mind if there's two different drivers or if any of > them is closed source. >> >> Is this possible and if so could someone hint me to how to do it, either > in an explanation or a reference to documentation? >> If it is not, could someone please list similiar options I could try? >> >> Thank you. >> >> >> _______________________________________________ >> xorg mailing list >> xorg at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg From sergio at sergiomb.no-ip.org Sat Dec 1 21:25:39 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sun, 02 Dec 2007 05:25:39 +0000 Subject: xf86-video-intel In-Reply-To: <200711281235.41211.jbarnes@virtuousgeek.org> References: <20071120203931.GA9092@ics.muni.cz> <1195875297.9744.34.camel@localhost.localdomain> <20071128090856.GM4365@ics.muni.cz> <200711281235.41211.jbarnes@virtuousgeek.org> Message-ID: <1196573139.17672.4.camel@localhost.localdomain> On Wed, 2007-11-28 at 12:35 -0800, Jesse Barnes wrote: > On Wednesday, November 28, 2007 1:08 am Lukas Hejtmanek wrote: > > On Sat, Nov 24, 2007 at 03:34:57AM +0000, Sergio Monteiro Basto wrote: > > > Lukas, I see 3 patches in this tread, what is the best combination ? > > > "also something" say that is this patch more something, should I apply > > > all of the 3 or just yours 2 ? > > > I have applied yours 2 and no crash nor flicks. > > > > You should apply all 3 patches to have the backlight behaving mostly > > correct. > > Does this patch work for you guys? Sorry no, @@ -363,6 +363,7 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool on) dev_priv->set_backlight(output, dev_priv->backlight_duty_cycle); } else { + dev_priv->backlight_duty_cycle = dev_priv->get_backlight(output); dev_priv->set_backlight(output, 0); OUTREG(PP_CONTROL, INREG(PP_CONTROL) & ~POWER_TARGET_ON); put my screen all back (or in blacklight permanently ) I'm using this instead : diff --git a/src/i830_lvds.c b/src/i830_lvds.c index a3a56f7..ab6b472 100644 --- a/src/i830_lvds.c +++ b/src/i830_lvds.c @@ -355,6 +354,14 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool on) I830Ptr pI830 = I830PTR(pScrn); CARD32 pp_status; + /* We need to save current backlight level which can be different from + * the server start up so that we restore it correctly. + * We assume that if LVDS is turned on, it contains also correct backlight + * level. + */ + if (INREG(PP_CONTROL) & POWER_TARGET_ON) + dev_priv->backlight_duty_cycle = dev_priv->get_backlight(output); + if (on) { OUTREG(PP_CONTROL, INREG(PP_CONTROL) | POWER_TARGET_ON); do { > > It properly gets the backlight at startup time, saves and restores it across > DPMS on/off calls, and doesn't mess with it at startup time (iow it assumes > you have it where you want it when you start X). > > Thanks, > Jesse -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jbarnes at virtuousgeek.org Sat Dec 1 22:32:31 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sat, 1 Dec 2007 22:32:31 -0800 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <1196571082.8230.2.camel@toddl> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <200712011030.59694.jbarnes@virtuousgeek.org> <1196571082.8230.2.camel@toddl> Message-ID: <200712012232.31298.jbarnes@virtuousgeek.org> It looks like it's at least detecting the displays to some extent. Can you file a bug for this problem and attach your xorg.conf and Xorg.0.log files to it? Thanks, Jesse On Saturday, December 01, 2007 8:51 pm Todd Johnson wrote: > I had tried it. It gave me many errors. It complained about running > out of memory and several other things. I posted the logs and old > config at http://www.fedoraforum.org/forum/showthread.php?t=172544 > > On Sat, 2007-12-01 at 10:30 -0800, Jesse Barnes wrote: > > On Friday, November 30, 2007 5:41 pm Todd Johnson wrote: > > > I've gotten it working on my work PC at work. It does have many > > > problems like not being able to restart X or logout. However it > > > works kindof. This is on Fedora Core 8 but should be similar. > > > > > > Section "Device" > > > Identifier "Videocard0" > > > # Driver "intel" > > > Driver "i810" > > > # Option "Monitor-VGA" "monitor1" > > > # Option "Monitor-TMDS-1" "monitor0" > > > Option "Clone" "false" > > > Option "MonitorLayout" "DFP,CRT" > > > Option "VideoRam" "131072" > > > BusId "PCI:0:2:0" > > > Screen 0 > > > EndSection > > > > Ok, this is kind of weird. F8 has a recent version of the "intel" > > driver that should support your SDVO configuration. What happens > > if you follow the dual head configuration instructions at > > http://www.intellinuxgraphics.com/dualhead.html? > > > > If that doesn't work, we may have a driver bug, and it would be > > good to collect some info about it... > > > > Thanks, > > Jesse From geopal at hotmail.com Sun Dec 2 00:32:06 2007 From: geopal at hotmail.com (Ford Prefect) Date: Sun, 2 Dec 2007 08:32:06 +0000 Subject: RandR module version, cant get V1.2 Message-ID: > yes. so in that case you may have an old version of xrandr or xrandr > protocol headers installed. Did you install from source or did you > use distro packages? As mentioned I am running openSuSE V10.3. They have a build service for various software categories, including the Xorg. I installed from there, guess that is what you called distro packages, right? In any case, I didn't build the package on my own. _________________________________________________________________ Die neue Version vom Windows Live Messenger ist da! http://get.live.com/messenger/overview From chris.sykes at nextstepsolutions.co.uk Sun Dec 2 02:25:01 2007 From: chris.sykes at nextstepsolutions.co.uk (Chris Sykes) Date: Sun, 02 Dec 2007 10:25:01 +0000 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <1196473279.3899.5.camel@toddl> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <47502C480200009E00000F0E@amaftp1.amatic1.com> <47502C480200009E00000F0E@amaftp1.amatic1.com> <1196435628.5023.22.camel@x60.rd.nextstepsolutions.co.uk> <1196473279.3899.5.camel@toddl> Message-ID: <1196591101.8697.8.camel@x60.newforest-technology.co.uk> On Fri, 2007-11-30 at 19:41 -0600, Todd Johnson wrote: > I've gotten it working on my work PC at work. It does have many > problems like not being able to restart X or logout. However it works > kindof. This is on Fedora Core 8 but should be similar. If this was for my own personal desktop then I could live with it, but unfortunately it is intended for use in a control system "appliance" so it needs to work reliably. This is also why I'm not keen on recompiling/packaging the whole X11 setup to get it working, or move to another platform. I was planning on testing out Fedora 8, but it sounds like that is unlikely to solve the intel issues completely. I was hoping to get away with using the SDVO PCIe card rather than a full blown graphics card, but it looks like that might be the most cost efficient way forward for me right now. I will continue to look into the intel issues on a test system, and will post a follow up if I should get anywhere with it. Thanks to everyone who replied to this thread for their help/advice. Kind regards, -- Chris Sykes Next Step Solutions Limited Unit K6 Liners Industrial Estate, Pitt Road Freemantle, Southampton, UK, SO15 3FQ Tel: 02380 224200 Mob: 07726 305061 From pixel at mandriva.com Sun Dec 2 02:40:46 2007 From: pixel at mandriva.com (Pixel) Date: Sun, 02 Dec 2007 11:40:46 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <1196544714.28623.19.camel@localhost.localdomain> (Sergio Monteiro Basto's message of "Sat\, 01 Dec 2007 21\:31\:54 +0000") References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> Message-ID: Sergio Monteiro Basto writes: > you write "set keycodes/xfree86 based model on evdev keyboard > breaks ...", so, have we some command to unset keycodes/xfree86 based > model ? sure: "setxkbmap -model evdev", et voila ! by the way, setxkbmap modifies both evdev keyboards (when you have more than one configured), i don't know if there is a way to change only one keyboard on a running X. ? From xhejtman at ics.muni.cz Sun Dec 2 03:32:26 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Sun, 2 Dec 2007 12:32:26 +0100 Subject: Memory allocator in Intel driver on X3100 card Message-ID: <20071202113226.GA26573@ics.muni.cz> Hello, the latest driver with the latest dri stuff (libdrm and kernel driver) fails to allocate memory for textures and then it fails to setup tiling. Is this a known problem currently? -- Luk?? Hejtm?nek From xhejtman at ics.muni.cz Sun Dec 2 03:38:03 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Sun, 2 Dec 2007 12:38:03 +0100 Subject: INPUT problems on ThinkPad T61 Message-ID: <20071202113803.GB26573@ics.muni.cz> Hello, I have Xserver 1.4.1 (git20071119) with synaptics driver 0.14.6. I have Lenovo ThinkPad T61 which has touchpad and trackpoint. I tried many configurations but none worked so that both touchpad and trackpoint works. Here is the log, I guess that the default pointer messes up things. (II) Synaptics touchpad driver version 0.14.6 (1406) (--) Configured Mouse auto-dev sets device to /dev/input/event6 (**) Option "Device" "/dev/input/event6" (**) Option "SHMConfig" "on" (--) Configured Mouse touchpad found (**) Option "CorePointer" (**) Configured Mouse: always reports core events (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/input/mice" (--) : Device: "/dev/input/mice" (==) : Protocol: "Auto" (**) Option "AlwaysCore" (**) : doesn't report core events (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (**) : Sensitivity: 1 (II) evaluating device () (II) XINPUT: Adding extended input device "" (type: MOUSE) (II) evaluating device (Configured Mouse) (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (II) evaluating device (keyboard0) (II) XINPUT: Adding extended input device "keyboard0" (type: KEYBOARD) (--) : PnP-detected protocol: "ExplorerPS/2" (II) : ps2EnableDataReporting: succeeded (--) Configured Mouse auto-dev sets device to /dev/input/event6 (**) Option "Device" "/dev/input/event6" (--) Configured Mouse touchpad found This is my config regadring the InputDevice: Section "InputDevice" Driver "synaptics" Identifier "Configured Mouse" Option "Device" "/dev/input/mice" Option "CorePointer" Option "SHMConfig" "on" EndSection -- Luk?? Hejtm?nek From daniel at fooishbar.org Sun Dec 2 04:36:13 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 2 Dec 2007 12:36:13 +0000 Subject: Xorg Input Hotplugging In-Reply-To: References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> Message-ID: <20071202123613.GM6534@fooishbar.org> On Sun, Dec 02, 2007 at 11:40:46AM +0100, Pixel wrote: > Sergio Monteiro Basto writes: > > you write "set keycodes/xfree86 based model on evdev keyboard > > breaks ...", so, have we some command to unset keycodes/xfree86 based > > model ? > > sure: "setxkbmap -model evdev", et voila ! > > by the way, setxkbmap modifies both evdev keyboards (when you have > more than one configured), i don't know if there is a way to change > only one keyboard on a running X. ? man setxkbmap /device -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Sun Dec 2 06:07:53 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 2 Dec 2007 14:07:53 +0000 Subject: Xorg Input Hotplugging In-Reply-To: <200712021556.00341.arvidjaar@mail.ru> References: <1192412762.10563.14.camel@mercury> <20071202123613.GM6534@fooishbar.org> <200712021556.00341.arvidjaar@mail.ru> Message-ID: <20071202140753.GN6534@fooishbar.org> On Sun, Dec 02, 2007 at 03:53:19PM +0300, Andrey Borzenkov wrote: > On Sunday 02 December 2007, Daniel Stone wrote: > > On Sun, Dec 02, 2007 at 11:40:46AM +0100, Pixel wrote: > > > sure: "setxkbmap -model evdev", et voila ! > > > > > > by the way, setxkbmap modifies both evdev keyboards (when you have > > > more than one configured), i don't know if there is a way to change > > > only one keyboard on a running X. ? > > > > man setxkbmap > > /device > > well, it says about "Specifies the numeric device id of the input device" > but does not actually explain how to find it out. How can I determine this > "numeric device id"? You can look it up with xsetpointer -l. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From SirRichard at fascinationsoftware.com Sun Dec 2 07:15:45 2007 From: SirRichard at fascinationsoftware.com (Richard Goedeken) Date: Sun, 02 Dec 2007 10:15:45 -0500 Subject: Intel driver problem with TV output In-Reply-To: References: Message-ID: <4752CC21.8090701@fascinationsoftware.com> Hello, I am setting up an HTPC using an AOpen MiniPC (GM965 chipset, X3100 accelerator) loaded with Fedora 8 and I'm having numerous problems with the video drivers. The major problem is that I can't get the TV output working. I have tried with both the current software in the Fedora 8 repository (xorg server 1.3.0.0-33.fc8 and xorg-drv-i810 2.1.1-7.fc8) and the latest in the Fedora 9 (rawhide) repository (xorg server 1.4.99.1-0.10.fc9 and xorg-drv-i810 2.2.0-1.fc9). I have attached the config and log files from the Fedora 8 setup. As far as I can tell, everything in the log files look good. Compiz is disabled. I can even drag windows off the desktop to the right (where the TV screen should be) and can move them totally off the screen, but the TV display is always blank. I've tried both the composite and component outputs. I know the electrical path is good because the TV flashes when starting the X server (with the newer drivers). At one point when I was loading and bringing up the new drivers, I had booted in init level 3 (text only) and did a 'telinit 5' to bring up X, and I actually got a cursor on the TV. But there was only the cursor on the TV (with a small Fedora blue dot animation) and the main CRT monitor was blank, so I couldn't log in. I restarted the X server and then lost the cursor display on the TV. I was unable to replicate this condition. Has anyone been successful getting TV output to work on this chipset/hardware? There are other major bugs that I've found as well. Is there a Bugzilla server where I can log these? In particular: 1. With the F9 (rawhide) drivers, the monitor goes into power-save mode when switching to a text VT. Switching back to X gives a blank screen (monitor powers up though), and requires an X restart or reboot to bring the display back. 2. With the F8 drivers, switching to a text VT works fine, but sometimes when switching back to X the screen is blank. After switching back and forth several times the graphical display will appear correctly, without having to restart X. Thanks, Richard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.log.fc8 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.fc8 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xrandr.out.fc8 URL: From pcpa at mandriva.com.br Sun Dec 2 07:30:54 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Sun, 02 Dec 2007 13:30:54 -0200 Subject: Anybody please reply:Is it possible to have keyboard or mouse with Xvfb ? In-Reply-To: <47b5508f0712012006h66103fb4m8f8d4914d1c26564@mail.gmail.com> References: <47b5508f0712012006h66103fb4m8f8d4914d1c26564@mail.gmail.com> Message-ID: <20071202133054.virthhtqw60csssg@webmail.conectiva.com.br> Quoting jenny tc : > Hi > Is it possible to have a keyboard or mouse or any input device with Xvfb? > I am using Xvfb with the X11R7.3. If possible , any special configuration > needed? If not any modifiction of the vfb code will do it? Maybe it could be easier to give a better response if you describe how you are using Xvfb. But I believe it should not be too much hard to implement as I guess you just want to send a few events, probably with something like XSendEvent. Otherwise, you probably would be better with Kdrive, Xephyr, Xnest, etc, or maybe hacking one of those to map to a "special" memory device. The Xvfb code is basically 1k lines of C source. I suggest checking how Xnest, as a X client handles events, and replicate appropriatelly in your Xfvb variant. > -Jenny Paulo From brice.goglin at gmail.com Sun Dec 2 08:00:00 2007 From: brice.goglin at gmail.com (Brice Goglin) Date: Sun, 02 Dec 2007 17:00:00 +0100 Subject: [PATCH] Fix XKB options passed from HAL Message-ID: <4752D680.3020004@gmail.com> Hi Daniel, Kanru Chen sent the attached patch to fix the XKB options that are passed to the server from HAL. Without this, he gets (**) Option "xkb_options" "," I guess we need such a fix in master and 1.4.1. Full details available at the beginning of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453683 Brice -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 94_hal_strlist URL: From jbarnes at virtuousgeek.org Sun Dec 2 08:36:02 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sun, 2 Dec 2007 08:36:02 -0800 Subject: i810/intel drivers with VGA SDVO In-Reply-To: <1196591101.8697.8.camel@x60.newforest-technology.co.uk> References: <47501012020000E400000AC2@amaftp1.amatic1.com> <1196473279.3899.5.camel@toddl> <1196591101.8697.8.camel@x60.newforest-technology.co.uk> Message-ID: <200712020836.02213.jbarnes@virtuousgeek.org> On Sunday, December 02, 2007 2:25 am Chris Sykes wrote: > On Fri, 2007-11-30 at 19:41 -0600, Todd Johnson wrote: > > I've gotten it working on my work PC at work. It does have many > > problems like not being able to restart X or logout. However it > > works kindof. This is on Fedora Core 8 but should be similar. > > If this was for my own personal desktop then I could live with it, > but unfortunately it is intended for use in a control system > "appliance" so it needs to work reliably. This is also why I'm not > keen on recompiling/packaging the whole X11 setup to get it working, > or move to another platform. I was planning on testing out Fedora 8, > but it sounds like that is unlikely to solve the intel issues > completely. > > I was hoping to get away with using the SDVO PCIe card rather than a > full blown graphics card, but it looks like that might be the most > cost efficient way forward for me right now. > > I will continue to look into the intel issues on a test system, and > will post a follow up if I should get anywhere with it. > > Thanks to everyone who replied to this thread for their help/advice. Our SDVO based systems work well with the F8 driver version, so I'd expect them to work well for you too. If it's possible for you to upgrade, I'd recommend giving it a try. If it doesn't work, please file a bug and include your X log, configuration, and whatever other details you can provide. Thanks, Jesse From jbarnes at virtuousgeek.org Sun Dec 2 08:37:46 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sun, 2 Dec 2007 08:37:46 -0800 Subject: Memory allocator in Intel driver on X3100 card In-Reply-To: <20071202113226.GA26573@ics.muni.cz> References: <20071202113226.GA26573@ics.muni.cz> Message-ID: <200712020837.46493.jbarnes@virtuousgeek.org> On Sunday, December 02, 2007 3:32 am Lukas Hejtmanek wrote: > Hello, > > the latest driver with the latest dri stuff (libdrm and kernel > driver) fails to allocate memory for textures and then it fails to > setup tiling. Is this a known problem currently? I think airlied reported some problems like this, so yeah sounds like it might be a bug in the master tree right now. I don't think we have a bug filed for it yet though, with the logs and such. Jesse From jbarnes at virtuousgeek.org Sun Dec 2 08:43:07 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sun, 2 Dec 2007 08:43:07 -0800 Subject: Intel driver problem with TV output In-Reply-To: <4752CC21.8090701@fascinationsoftware.com> References: <4752CC21.8090701@fascinationsoftware.com> Message-ID: <200712020843.07967.jbarnes@virtuousgeek.org> On Sunday, December 02, 2007 7:15 am Richard Goedeken wrote: > There are other major bugs that I've found as well. Is there a > Bugzilla server where I can log these? In particular: 1. With the F9 > (rawhide) drivers, the monitor goes into power-save mode when > switching to a text VT. Switching back to X gives a blank screen > (monitor powers up though), and requires an X restart or reboot to > bring the display back. 2. With the F8 drivers, switching to a text > VT works fine, but sometimes when switching back to X the screen is > blank. After switching back and forth several times the graphical > display will appear correctly, without having to restart X. Some people reported TV out related problems prior to the 2.2 relese, but I was hoping we'd quashed the major bugs for that release. If it's possible for you to build a new driver yourself (should be fairly easy if you're running rawhide), you can try applying the attached patch to tweak your TV output properties. It may be that the brightness or other values are wrong for your configuration. Once it's installed, you can use 'xrandr --prop' to see the current values and 'xrandr --output TV --set CONTRAST 20' for example to set the contrast. Jesse -------------- next part -------------- A non-text attachment was scrubbed... Name: i830-tv-properties-4.patch Type: text/x-diff Size: 6250 bytes Desc: not available URL: From jra at baylink.com Sun Dec 2 09:24:32 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 2 Dec 2007 12:24:32 -0500 Subject: Website maintenance volunteers? In-Reply-To: <200712010029.lB10TWCO005009@adara.cs.pdx.edu> References: <226dee610711300409y6e6e2681h6509243538e37d90@mail.gmail.com> <20071128183851.GM3067@fooishbar.org> <20071128200439.GE30794@bryceharrington.org> <200712010029.lB10TWCO005009@adara.cs.pdx.edu> Message-ID: <20071202172432.GE21078@cgi.jachomes.com> On Fri, Nov 30, 2007 at 04:29:32PM -0800, Barton C Massey wrote: > I'm not sure what the status is of embedding arbitrary HTML > in MW pages; any wiki that doesn't let me do that is a > non-starter for me, as the wacky markup languages that most > things support just aren't powerful enough for the corner > cases. I know there are potential XSS issues, but see the > next paragraph... MW will permit users to embed some HTML in pages; some is tidied out as "unsafe". I believe the list is configurable. > The big showstoppers for MW, as I see it, are > severalfold. (1) Hosting: AFAIK no one at freedesktop.org, > with its limited staff resources, is very excited about > trying to maintain a complex and evolving PHP/SQL app. I've run MW. On the scale X.org will need, there's effectively no administration work at all, in the backend. The wiki itself will need a few watchers, of course. > 2) Content conversion: AFAIK there is no automated way to move > our Moin content over. David Greaves used to host wiki.mythtv.org on Moin; scripts were writen to port it to MW. If it becomes useful, I can grab those scripts from him; ISTR they worked pretty decently. > (3) Experience: Unless someone with > experience running MW sites steps up and volunteers to run > the whole mess, I don't think we have anybody already signed > up who's done that. It's not all that difficult to wrangle a Mediawiki site; as I note above, keeping the engine working is pretty trivial, but the above-the-line work isn't too bad either. > (4) Target: MW really isn't designed > for technical development work. It's got quite a bit of > structure, and some of that structure seems to me > inappropriate for what we're Doing, presumably. I haven't dug very deeply into x.org, but IME, MW can be stretched to do quite a bit of non-obvious stuff, out of the box. And, of course, there's Wikipedia from which to steal implementations of cool stuff, if you need it and can't think up how to do it on your own. > I think MW is a definite possibility, but I'd like to see > these issues addressed. On all of the counts above, I think > that ikiwiki is superior. I agree that sticking with Moin > is a possibility, and I agree with those who say the problem > is more content than delivery infrastructure. Daniel's > argument as I understand it, though, is that perhaps more > folks would be willing to work on the content if they didn't > have to do it through the horrid wiki-editing interface. I haven't worked on the current wiki, but I did do some work on the Myth wiki while it was still on Moin, and I was, in fact, not as impressed with the interaction as I was with MW, which was one of the reasons that I was the chief agitator for the switch. Isaac, the project lead there, is allergic to extra infrastructural work, and I don't recall that he's had to do anything more strenuous than turn on "only registered users can post", in the 2 years-ish since it went in. > I can speak from personal experience here, and say that I have > done much more and more rapid content development and > maintenance under ikiwiki than any of the several other > systems I've worked with, for precisely this reason. > > > and about git updating a page under ikiwiki, seriously > > ;-0.... (you might was well just put the website home > > directory under git) > > I have no idea what you mean by all this. I certainly have > lots of web pages that are git-controlled outside of any > wiki---what's the problem? Ikiwiki provides some > convenience and wiki-style editing on top of this mechanism; > this is a good thing, no? Or are you just referring to the > fact that git+ikiwiki seems to hose itself fairly frequently > and painfully, which I have to agree with... I think he was guffawing at the idea of far-offline wiki editing, in general, and I'm not sure I disagree with him. Near-offline, maybe. > Anyway, thanks to all for the feedback! I'm probably going > to try to do something about it once we've reached enough > consensus that I can decide what that something should > be---so keep those cards and letters coming! Sure. As I noted to Daniel off list, I'd be happy to contribute whatever I can in the vein of site management; I have some little experience in that from several years contributing to WP as well as the wiki.mythtv.org work and setting up bestpractices.wikia.com. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From sim0n at trypill.org Sun Dec 2 09:28:46 2007 From: sim0n at trypill.org (sim0n) Date: Sun, 02 Dec 2007 18:28:46 +0100 Subject: G35/33 X3500/3100 HDMI Message-ID: <4752EB4E.9000002@trypill.org> Hi, I would be interested in buying a "Asus P5E-VM HDMI" motherboard, which has the G35 chipset and a X3500 graphics chip on-board including an HDMI connector. Is that chipset and graphics chip already supported (stable or devel) ? If not, is the G33 / X3100 supported, and does HDMI work ? -- regards, sim0n From xhejtman at ics.muni.cz Sun Dec 2 10:41:29 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Sun, 2 Dec 2007 19:41:29 +0100 Subject: Memory allocator in Intel driver on X3100 card In-Reply-To: <200712020837.46493.jbarnes@virtuousgeek.org> References: <20071202113226.GA26573@ics.muni.cz> <200712020837.46493.jbarnes@virtuousgeek.org> Message-ID: <20071202184129.GE26573@ics.muni.cz> On Sun, Dec 02, 2007 at 08:37:46AM -0800, Jesse Barnes wrote: > > the latest driver with the latest dri stuff (libdrm and kernel > > driver) fails to allocate memory for textures and then it fails to > > setup tiling. Is this a known problem currently? > > I think airlied reported some problems like this, so yeah sounds like it > might be a bug in the master tree right now. I don't think we have a > bug filed for it yet though, with the logs and such. so I filled one. -- Luk?? Hejtm?nek From i.r.wezeman at hetnet.nl Sun Dec 2 10:41:39 2007 From: i.r.wezeman at hetnet.nl (i.r.wezeman at hetnet.nl) Date: Sun, 2 Dec 2007 19:41:39 +0100 Subject: xm_api & too few arguments to function 'v->display->CreatePixmap' Message-ID: build with module_autogenargs['xserver'] = autogenargs + ' --enable-xgl --enable-xglx --with-mesa-source=/SOURCE/mesa --enable-glx ' Trying with two git branches: master and xgl-0.0.1 with error: see subject bash-3.1# git branch master * xgl-0.0.1 bash-3.1# cd GL/mesa/X/ bash-3.1# make /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c -o xm_api.lo xm_api.c /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c -o xm_buffer.lo xm_buffer.c gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c xm_api.c -fPIC -DPIC -o .libs/xm_api.o gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c xm_buffer.c -fPIC -DPIC -o .libs/xm_buffer.o xm_api.c: In function 'setup_8bit_hpcr': xm_api.c:877: error: too few arguments to function 'v->display->CreatePixmap' xm_buffer.c: In function 'alloc_back_buffer': xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' make: *** [xm_buffer.lo] Error 1 make: *** Waiting for unfinished jobs.... make: *** [xm_api.lo] Error 1 bash-3.1# bash-3.1# git branch * master xgl-0.0.1 bash-3.1# cd GL/mesa/ bash-3.1# make Making all in main make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/main' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/main' Making all in math make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/math' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/math' Making all in swrast make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/swrast' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/swrast' Making all in swrast_setup make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/swrast_setup' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/swrast_setup' Making all in tnl make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/tnl' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/tnl' Making all in shader make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/shader' Making all in grammar make[2]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/shader/grammar' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/shader/grammar' Making all in slang make[2]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/shader/slang' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/shader/slang' make[2]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/shader' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/shader' make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/shader' Making all in X make[1]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/X' /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c -o xm_api.lo xm_api.c /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c -o xm_buffer.lo xm_buffer.c gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c xm_buffer.c -fPIC -DPIC -o .libs/xm_buffer.o gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c xm_api.c -fPIC -DPIC -o .libs/xm_api.o xm_api.c: In function 'setup_8bit_hpcr': xm_api.c:877: error: too few arguments to function 'v->display->CreatePixmap' make[1]: *** [xm_api.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... xm_buffer.c: In function 'alloc_back_buffer': xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' make[1]: *** [xm_buffer.lo] Error 1 make[1]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/X' make: *** [all-recursive] Error 1 bash-3.1# -------------- next part -------------- An HTML attachment was scrubbed... URL: From dant at cdkkt.com Sun Dec 2 11:08:07 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Sun, 2 Dec 2007 11:08:07 -0800 Subject: xorg.conf Message-ID: <021126B987E43D44A860139823C079110E2BC9@orion.cdkkt.com> Hello, This is my first email message to this group, so please bear with me or direct me to where I need to go to report this "bug". My Hardware: ========== PC: VA Linux System, 600Mhz PIII RAM: 396MB Video: Cirrus GD5480 OS: Fedora releases 6/7/8. GDM was able to locate the cirrus chipset and xorg.conf shows: ==================================== Section "Device" Identifier "Screen0" Driver "cirrus" EndSection Section "Screen0" Device "Videocard0" DefaultDepth 24 EndSection ==================================== The problem here, is that the DefaultDepth is too high for cirrus chipsets that cannot support color depths higher than it is capable of, so GDM will fail to find a working screen resolution it can support. The following shows what had to be done to get the GDM working and I have found that even with the DefaultDepth set to 16, it is not sufficient to ignore the Modes as it must specify supported screen resolutions to ensure a successful GDM startup. #==================================== Section "Screen0" Device "Videocard0" DefaultDepth 16 SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" "640x480 EndSubSection EndSection #==================================== Thank you for your time, Dan Thurman No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.12/1163 - Release Date: 12/1/2007 12:05 PM From dbn.lists at gmail.com Sun Dec 2 11:49:06 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sun, 2 Dec 2007 11:49:06 -0800 Subject: xm_api & too few arguments to function 'v->display->CreatePixmap' In-Reply-To: References: Message-ID: <91705d080712021149y3e7f45fbl970a5b88d6652684@mail.gmail.com> On Dec 2, 2007 10:41 AM, wrote: > > build with module_autogenargs['xserver'] = autogenargs + ' --enable-xgl > --enable-xglx --with-mesa-source=/SOURCE/mesa --enable-glx ' > > Trying with two git branches: master and xgl-0.0.1 > > with error: see subject > > > bash-3.1# git branch > master > * xgl-0.0.1 > bash-3.1# cd GL/mesa/X/ > bash-3.1# make > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main > -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. > -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include > -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal > -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite -I../../../damageext > -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow > -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb > -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c -o > xm_api.lo xm_api.c > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main > -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. > -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include > -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal > -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite -I../../../damageext > -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow > -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb > -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c > -o xm_buffer.lo xm_buffer.c > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X > -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup > -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include > -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal > -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite -I../../../damageext > -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow > -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb > -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c > xm_api.c -fPIC -DPIC -o .libs/xm_api.o > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X > -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup > -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include > -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal > -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite -I../../../damageext > -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow > -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb > -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c > xm_buffer.c -fPIC -DPIC -o .libs/xm_buffer.o > xm_api.c: In function 'setup_8bit_hpcr': > xm_api.c:877: error: too few arguments to function > 'v->display->CreatePixmap' > xm_buffer.c: In function 'alloc_back_buffer': > xm_buffer.c:226: error: too few arguments to function > 'b->xm_visual->display->CreatePixmap' > make: *** [xm_buffer.lo] Error 1 > make: *** Waiting for unfinished jobs.... > make: *** [xm_api.lo] Error 1 > bash-3.1# What version of mesa are you using for --with-mesa-source? It has to be git master if you're trying to use xserver master. -- Dan From sergio at sergiomb.no-ip.org Sun Dec 2 11:53:53 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sun, 02 Dec 2007 19:53:53 +0000 Subject: xf86-video-intel In-Reply-To: <1196573139.17672.4.camel@localhost.localdomain> References: <20071120203931.GA9092@ics.muni.cz> <1195875297.9744.34.camel@localhost.localdomain> <20071128090856.GM4365@ics.muni.cz> <200711281235.41211.jbarnes@virtuousgeek.org> <1196573139.17672.4.camel@localhost.localdomain> Message-ID: <1196625234.17363.12.camel@localhost.localdomain> On Sun, 2007-12-02 at 05:25 +0000, Sergio Monteiro Basto wrote: > On Wed, 2007-11-28 at 12:35 -0800, Jesse Barnes wrote: > > On Wednesday, November 28, 2007 1:08 am Lukas Hejtmanek wrote: > > > On Sat, Nov 24, 2007 at 03:34:57AM +0000, Sergio Monteiro Basto > wrote: > > > > Lukas, I see 3 patches in this tread, what is the best > combination ? > > > > "also something" say that is this patch more something, should I > apply > > > > all of the 3 or just yours 2 ? > > > > I have applied yours 2 and no crash nor flicks. > > > > > > You should apply all 3 patches to have the backlight behaving > mostly > > > correct. > > > > Does this patch work for you guys? > Sorry no, > > @@ -363,6 +363,7 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool > on) > > dev_priv->set_backlight(output, dev_priv->backlight_duty_cycle); > } else { > + dev_priv->backlight_duty_cycle = dev_priv->get_backlight(output); > dev_priv->set_backlight(output, 0); > > OUTREG(PP_CONTROL, INREG(PP_CONTROL) & ~POWER_TARGET_ON); > > put my screen all back (or in blacklight permanently ) > > > I'm using this instead : > > diff --git a/src/i830_lvds.c b/src/i830_lvds.c > index a3a56f7..ab6b472 100644 > --- a/src/i830_lvds.c > +++ b/src/i830_lvds.c > @@ -355,6 +354,14 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool > on) > I830Ptr pI830 = I830PTR(pScrn); > CARD32 pp_status; > > + /* We need to save current backlight level which can be different > from > + * the server start up so that we restore it correctly. > + * We assume that if LVDS is turned on, it contains also correct > backlight > + * level. > + */ > + if (INREG(PP_CONTROL) & POWER_TARGET_ON) > + dev_priv->backlight_duty_cycle = > dev_priv->get_backlight(output); > + > if (on) { > OUTREG(PP_CONTROL, INREG(PP_CONTROL) | POWER_TARGET_ON); > do { > > > > > > It properly gets the backlight at startup time, saves and restores > it across > > DPMS on/off calls, and doesn't mess with it at startup time (iow it > assumes > > you have it where you want it when you start X). > > My proposing patch ( includes all patches floating around on this thread ) , things works quite good for me. ah , Jesse , about coding style, I think at X , has been adopt, has in Linus kernel, the tab are replace by 4 spaces. This make emacs and vi more compatible. I am not sure that do it but anyway ... for .vimrc: set expandtab set softtabstop=4 set ts=4 set sw=4 http://www.x.org/wiki/CodingStyle Thanks, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: i810.v3.patch Type: text/x-patch Size: 1423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From irwin at beluga.phys.uvic.ca Sun Dec 2 12:31:27 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 02 Dec 2007 12:31:27 -0800 (PST) Subject: G35/33 X3500/3100 HDMI In-Reply-To: <4752EB4E.9000002@trypill.org> References: <4752EB4E.9000002@trypill.org> Message-ID: On 2007-12-02 18:28+0100 sim0n wrote: > Hi, > > I would be interested in buying a "Asus P5E-VM HDMI" motherboard, which > has the G35 chipset and a X3500 graphics chip on-board including an HDMI > connector. > > Is that chipset and graphics chip already supported (stable or devel) ? > > > If not, is the G33 / X3100 supported Here's my perspective as a user/bug reporter for the g33/ich9 chipset from Intel. My experience has been for the ASUS P5K-V Motherboard. The embedded video chip for g33 is still pretty near the cutting edge so expect some fairly long X outages like I experienced recently until a fix was found (see http://lists.freedesktop.org/archives/xorg/2007-November/030623.html). BTW, I think the g33 actually has a GMA 3100 not GMA X3100, see http://en.wikipedia.org/wiki/Intel_GMA . > and does HDMI work ? The ASUS P5K-V only has VGA output by default (which is what I bought). You can buy a cheap ADD-on Intel card to give you digital output, and I believe Intel has promised full xorg support for such solutions, but I am not sure how mature that support is at this time. The other issue with the g33/ich9 chipset for the ASUS P5K-V is the sound which has only recently become supported by Alsa. It works, but the quality is pretty poor (irritating hum) at this time for kernel-2.6.22. Again, I think this is the result of hardware uncomfortably close to the cutting edge, and I fully expect that this problem will disappear in the future (perhaps even already with kernel-2.6.23, but Debian has not deployed that kernel yet even for the unstable version of that distro). Everything else with the ASUS P5K-V Motherboard works well including the atl1 gigabit on-board LAN, the internal SATA ich9 interface, and the external SATA JMicron interface which I use for esata drive backups. I don't think you could have said that for kernels much earlier than 2.6.22, though. Hope my recent experiences help you with your buying decision. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sim0n at trypill.org Sun Dec 2 13:04:17 2007 From: sim0n at trypill.org (sim0n) Date: Sun, 02 Dec 2007 22:04:17 +0100 Subject: G35/33 X3500/3100 HDMI In-Reply-To: References: <4752EB4E.9000002@trypill.org> Message-ID: <47531DD1.80106@trypill.org> The two models I'd be interested in are these: P5E-VM HDMI http://www.asus.com/products.aspx?l1=3&l2=11&l3=584&l4=0&model=1912&modelmenu=1 GA-G33M-S2H http://www.giga-byte.com/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=2600&ProductName=GA-G33M-S2H > Here's my perspective as a user/bug reporter for the g33/ich9 chipset from > Intel. My experience has been for the ASUS P5K-V Motherboard. > > The embedded video chip for g33 is still pretty near the cutting edge so > expect some fairly long X outages like I experienced recently until a fix > was found (see > http://lists.freedesktop.org/archives/xorg/2007-November/030623.html). BTW, I have xorg7.3, and am running a 2.6.23 kernel. I have no problem with building the driver for the GMA 3100 from a git repository, as long as it works :-). So does a recent version of the driver work for you, including video playback, or is it still pretty much broken ? ...I would hate to go once a again with an nvidia based solution. > I think the g33 actually has a GMA 3100 not GMA X3100, see > http://en.wikipedia.org/wiki/Intel_GMA . Yes, you're right. Was wrongly listed in the shop... >> and does HDMI work ? > > The ASUS P5K-V only has VGA output by default (which is what I bought). You > can buy a cheap ADD-on Intel card to give you digital output, and I believe > Intel has promised full xorg support for such solutions, but I am not sure > how mature that support is at this time. The Gigabyte model I mentioned above has a VGA and an HDMI port, which can be converted to DVI with an adapter. And apparently HDMI should work. So that's no problem. Thank you very much for your detailed information. I guess unless you say that the GMA 3100 basically works now I will have to go with a different solution :-(. -- regards, sim0n From Juliusz.Chroboczek at pps.jussieu.fr Sun Dec 2 13:29:56 2007 From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek) Date: Sun, 02 Dec 2007 22:29:56 +0100 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> (Barton C. Massey's message of "Wed\, 28 Nov 2007 23\:11\:31 -0800") References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> Message-ID: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> > Date: Fri, 30 Nov 2007 21:42:53 -0800 > Nominations for the 2007 election are currently open and > will remain open until 23.59 GMT on Saturday 1 December > 2007. Dear Barton, dear Keith, I think there is a serious problem with a nomination process that is announced on a Friday evening, with the deadline on Saturday. I am fully convinced that this is simply a mistake, and that there is no intention to limit the nominees. However, I believe that this mistake should be fixed, lest the governance process of X.Org go the way of XFree86. I would like to request that the nominations deadline should be extended by a week at least. Juliusz From Juliusz.Chroboczek at pps.jussieu.fr Sun Dec 2 13:29:56 2007 From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek) Date: Sun, 02 Dec 2007 22:29:56 +0100 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> (Barton C. Massey's message of "Wed\, 28 Nov 2007 23\:11\:31 -0800") References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> Message-ID: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> > Date: Fri, 30 Nov 2007 21:42:53 -0800 > Nominations for the 2007 election are currently open and > will remain open until 23.59 GMT on Saturday 1 December > 2007. Dear Barton, dear Keith, I think there is a serious problem with a nomination process that is announced on a Friday evening, with the deadline on Saturday. I am fully convinced that this is simply a mistake, and that there is no intention to limit the nominees. However, I believe that this mistake should be fixed, lest the governance process of X.Org go the way of XFree86. I would like to request that the nominations deadline should be extended by a week at least. Juliusz From dbn.lists at gmail.com Sun Dec 2 13:54:44 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sun, 2 Dec 2007 13:54:44 -0800 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> Message-ID: <91705d080712021354u36b349aaud62b70a0d33a5836@mail.gmail.com> On Dec 2, 2007 1:29 PM, Juliusz Chroboczek wrote: > > Date: Fri, 30 Nov 2007 21:42:53 -0800 > > > Nominations for the 2007 election are currently open and > > will remain open until 23.59 GMT on Saturday 1 December > > 2007. > > I think there is a serious problem with a nomination process that is > announced on a Friday evening, with the deadline on Saturday. http://lists.freedesktop.org/archives/xorg/2007-November/030168.html That gave two and a half weeks for nominations. -- Dan From tom at dbservice.com Sun Dec 2 13:55:48 2007 From: tom at dbservice.com (Tomas Carnecky) Date: Sun, 02 Dec 2007 22:55:48 +0100 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> Message-ID: <475329E4.1020203@dbservice.com> Juliusz Chroboczek wrote: > I think there is a serious problem with a nomination process that is > announced on a Friday evening, with the deadline on Saturday. Date: 11/14/07 04:42 Subject: Nominations for X.Org Foundation Board of Directors are OPEN Date: 11/19/07 20:59 Subject: Second call: Nominations for X.Org Foundation Board This is merely the 'Final call'. tom From irwin at beluga.phys.uvic.ca Sun Dec 2 15:03:30 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 02 Dec 2007 15:03:30 -0800 (PST) Subject: G35/33 X3500/3100 HDMI In-Reply-To: <47531DD1.80106@trypill.org> References: <4752EB4E.9000002@trypill.org> <47531DD1.80106@trypill.org> Message-ID: On 2007-12-02 22:04+0100 sim0n wrote: > Thank you very much for your detailed information. > I guess unless you say that the GMA 3100 basically works now I will have to > go with a different solution :-(. Aside from the one-week outage due to an introduced issue in the cutting-edge version of the driver, it has been working well. I run KDE 3.x (i.e., 2D desktop) with no problems, and also ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here is the glxgears rating results as given by the offical http://www.free3d.org/ script 2.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) model name : Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz cpu MHz : 2337.650 model name : Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz cpu MHz : 2337.650 X.Org version: 1.4.0 dimensions: 1024x768 pixels (260x195 millimeters) depth of root window: 16 planes direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 -- OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) G33 20061017 OpenGL version string: 1.3 Mesa 7.0.2 [1] 18157 12390 frames in 5.0 seconds = 2477.976 FPS 12444 frames in 5.0 seconds = 2488.676 FPS 12443 frames in 5.0 seconds = 2488.600 FPS 12435 frames in 5.0 seconds = 2486.994 FPS 12444 frames in 5.0 seconds = 2488.789 FPS 12444 frames in 5.0 seconds = 2488.792 FPS That rating is roughly 3rd in the 1024x768 class which is not bad for embedded graphics. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From rglowery at exemail.com.au Sun Dec 2 16:02:22 2007 From: rglowery at exemail.com.au (rglowery at exemail.com.au) Date: Mon, 3 Dec 2007 11:02:22 +1100 (EST) Subject: Intel driver problem with TV output In-Reply-To: <4752CC21.8090701@fascinationsoftware.com> References: <4752CC21.8090701@fascinationsoftware.com> Message-ID: <37826.64.213.30.2.1196640142.squirrel@webmail.exetel.com.au> > Hello, > > I am setting up an HTPC using an AOpen MiniPC (GM965 chipset, X3100 > accelerator) loaded with Fedora 8 and I'm having > numerous problems with the video drivers. The major problem is that I > can't get the TV output working. I have tried > with both the current software in the Fedora 8 repository (xorg server > 1.3.0.0-33.fc8 and xorg-drv-i810 2.1.1-7.fc8) and > the latest in the Fedora 9 (rawhide) repository (xorg server > 1.4.99.1-0.10.fc9 and xorg-drv-i810 2.2.0-1.fc9). I have > attached the config and log files from the Fedora 8 setup. Hi Richard, I am using the AOpen MP965-DR MiniPC with Ubuntu Gutsy and MythTV. There were various issues with TVOut I had to work through in the 2.1.0 intel driver to get things going including 1) XServer crash due to the prev field being uinitialized in i830_tv_get_modes() 2) LVDS output being enabled (This PC does not have a local display) 3) Washed out colours due to incorrect default brightness 4) Missing 1920x1080 TV Out mode (if this is relvant to you) All of these fixes have been incorporated into the 2.2.0 release. There still seems to be some instability with the TV output not coming up all of the time. Disabling the VGA output in xorg.conf seems to help (I only use TMDS-1 (DVI) and TV outputs), although perhaps 20% of the time, it still does not come up for me. Restarting X a few times usually resolves this issue. There also seems to be some geometry/black bar issues that I am still investigating. To enable TV Output over component, I use the following command xrandr --output TV --set TV_FORMAT 576p --auto substituting 576p for PAL also works for me. These are the only 2 modes my CRT TV supports. HTH -Rob From daniel at fooishbar.org Sun Dec 2 16:30:17 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 00:30:17 +0000 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> Message-ID: <20071203003017.GS6534@fooishbar.org> On Sun, Dec 02, 2007 at 10:29:56PM +0100, Juliusz Chroboczek wrote: > > Nominations for the 2007 election are currently open and > > will remain open until 23.59 GMT on Saturday 1 December > > 2007. > > Dear Barton, dear Keith, > > I think there is a serious problem with a nomination process that is > announced on a Friday evening, with the deadline on Saturday. > > I am fully convinced that this is simply a mistake, and that there is > no intention to limit the nominees. However, I believe that this > mistake should be fixed, lest the governance process of X.Org go the > way of XFree86. > > I would like to request that the nominations deadline should be > extended by a week at least. Hi Juliusz, Very sorry about this. Bart announced the nominations a couple of weeks ago to xorg at l.fd.o, but simply forgot to mail xf_members. A genuine oversight (indeed, it was available on the _publicly archived_ list rather than the private one, so there's no real lust for secrecy) rather than malice. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From keithp at keithp.com Sun Dec 2 19:02:47 2007 From: keithp at keithp.com (Keith Packard) Date: Sun, 02 Dec 2007 19:02:47 -0800 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> Message-ID: <1196650967.4698.39.camel@koto.keithp.com> On Sun, 2007-12-02 at 22:29 +0100, Juliusz Chroboczek wrote: > > Date: Fri, 30 Nov 2007 21:42:53 -0800 > > > Nominations for the 2007 election are currently open and > > will remain open until 23.59 GMT on Saturday 1 December > > 2007. > > Dear Barton, dear Keith, > > I think there is a serious problem with a nomination process that is > announced on a Friday evening, with the deadline on Saturday. Perhaps you missed the earlier announcements then, or perhaps you were caught by our mistake in sending the announcements only to the xorg@ list and not the members@ list. > I am fully convinced that this is simply a mistake, and that there is > no intention to limit the nominees. However, I believe that this > mistake should be fixed, lest the governance process of X.Org go the > way of XFree86. There certainly wasn't any intention to restrict nominations; such are welcome for any X.org member (and, if necessary, can even be sent in conjunction with a membership application). In past elections, we've had trouble finding enough people willing to serve; we're fortunate this time not to have this particular problem, but even still, having real choices can only serve to improve the content and performance of the board. > I would like to request that the nominations deadline should be > extended by a week at least. This is certainly possible, especially given our own error mentioned above. We're interested in having as wide a representation as possible, a broad range of views has certainly helped our organization already. If you do have nomination suggestions, please send them along in any case. -- keith.packard at intel.com -------------- 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 dan at entropy.homelinux.org Sun Dec 2 20:53:30 2007 From: dan at entropy.homelinux.org (Daniel Kasak) Date: Mon, 03 Dec 2007 15:53:30 +1100 Subject: r300, amd64, svideo Message-ID: <1196657610.3883.53.camel@dkasak.nusconsulting.com.au> Hi all. Should tv-out via the svideo connector work on amd64 systems? I've got a Radeon X700 Mobility chip. I did some testing over the weekend. I tried pretty much all the suggestions I found in the mailing list by searching for 'tv', including the obvious: xrandr --output S-video --auto ... or: xrandr --output S-video --mode 800x600 ... then: xrandr --output S-video --mode 800x600 Nothing happens :( xrandr -v --query says that I have an SVideo port, but it *always* says it's disconnected. I've also tried booting with the SVideo cable connected ( used to work on an older radeon ). Dan From xhejtman at ics.muni.cz Mon Dec 3 00:41:37 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Mon, 3 Dec 2007 09:41:37 +0100 Subject: memory leaks in the current Xserver Message-ID: <20071203084137.GF26573@ics.muni.cz> Hello, I'm using Xserver 1.4.1 () that consumes about 190MB of RAM (resident not virtual) after running couple of days. xrestop reports that pixmaps consume only 7MB RAM. Does it mean that there are some memory leaks? I have integrated graphic card with shared memory so it could mean that the Intel driver just wastes graphic memory.. -- Luk?? Hejtm?nek From daniel at fooishbar.org Mon Dec 3 00:58:45 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 08:58:45 +0000 Subject: memory leaks in the current Xserver In-Reply-To: <20071203084137.GF26573@ics.muni.cz> References: <20071203084137.GF26573@ics.muni.cz> Message-ID: <20071203085845.GT6534@fooishbar.org> On Mon, Dec 03, 2007 at 09:41:37AM +0100, Lukas Hejtmanek wrote: > I'm using Xserver 1.4.1 () that consumes about 190MB of RAM (resident not > virtual) after running couple of days. xrestop reports that pixmaps consume > only 7MB RAM. Does it mean that there are some memory leaks? I believe there's a pretty serious leak, and I'm trying to track it down before I release 1.4.1. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From geopal at hotmail.com Mon Dec 3 01:01:37 2007 From: geopal at hotmail.com (Ford Prefect) Date: Mon, 3 Dec 2007 09:01:37 +0000 Subject: RandR module version, cant get V1.2 Message-ID: > And now comes the question, randr is stiff-necked in reporting an older version: > > xrandr -v --verbose > > Server reports RandR version 1.1 > ... I have found out under what circumstances the server does this: it happens when XGL is enabled. De-activating XGL leads to xrandr -v Server reports RandR version 1.2 ... and I can use all the fancy features V1.2 offers over V1.1. This is good news, but still a little bit unsatisfying. I know now HOW to use a work-around, but still don't know WHY exactly this happens. Any ideas from you guys? _________________________________________________________________ Windows Live Fotogalerie: So einfach organisieren Sie Ihre Fotos! http://get.live.com/photogallery/overview From bernie at codewiz.org Mon Dec 3 01:17:44 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 03 Dec 2007 04:17:44 -0500 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <4752D680.3020004@gmail.com> References: <4752D680.3020004@gmail.com> Message-ID: <4753C9B8.2070104@codewiz.org> Brice Goglin wrote: > Kanru Chen sent the attached patch to fix the XKB options that are > passed to the server from HAL. Without this, he gets > (**) Option "xkb_options" "," Uh, I'm picking it up on OLPC. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From Juliusz.Chroboczek at pps.jussieu.fr Mon Dec 3 01:32:48 2007 From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek) Date: Mon, 03 Dec 2007 10:32:48 +0100 Subject: Final call: Nominations for X.Org Foundation Board In-Reply-To: <1196650967.4698.39.camel@koto.keithp.com> (Keith Packard's message of "Sun\, 02 Dec 2007 19\:02\:47 -0800") References: <200711290711.lAT7BV1X005180@adara.cs.pdx.edu> <7izlwspyy3.fsf@lanthane.pps.jussieu.fr> <1196650967.4698.39.camel@koto.keithp.com> Message-ID: <7isl2kjf7j.fsf@lanthane.pps.jussieu.fr> >> I think there is a serious problem with a nomination process that is >> announced on a Friday evening, with the deadline on Saturday. > Perhaps you missed the earlier announcements then, or perhaps you were > caught by our mistake in sending the announcements only to the xorg@ > list and not the members@ list. Yes, I was. The traffic on xorg@ is rather important, and I only check that list every month or so. >> I am fully convinced that this is simply a mistake, and that there is >> no intention to limit the nominees. > There certainly wasn't any intention to restrict nominations; I am fully convinced of that, and I am glad to have your confirmation. >> I would like to request that the nominations deadline should be >> extended by a week at least. > This is certainly possible, especially given our own error mentioned above. Please do add at least a token delay. Doing otherwise might generate some bad press for X.Org. Juliusz From tassilo at member.fsf.org Mon Dec 3 01:35:54 2007 From: tassilo at member.fsf.org (Tassilo Horn) Date: Mon, 03 Dec 2007 10:35:54 +0100 Subject: Control blocks Alt in keybindings Message-ID: <8763zgp1c5.fsf@member.fsf.org> Hi, I use Xorg 7.3 on a Gentoo GNU/Linux machine. When I want to enter keybindings involving both Control (C) and Alt (M) it seems that Control is blocking the Alt key if I press it first. Let's say I want to type the binding C-M-a by first pressing Control, then Alt and then "a", it's translated to only C-a. With xev I get the following order: KP-C, KP-a, KR-a, KP-M, KR-M, KR-C where KP is KeyPress and KR is KeyRelease. I can type C-M-a by first pressing Alt, then Control and then "a". I tried this with both stumpwm and twm, so it shouldn't be the window manager stealing the keys. I use a German Dvorak layout, but tested with setxkblayout "us" too and got the same results. Is this a bug or what can be the culprit? Bye, Tassilo -- Chuck Norris CAN believe it's not butter. From bernie at codewiz.org Mon Dec 3 01:41:56 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 03 Dec 2007 04:41:56 -0500 Subject: Xorg Input Hotplugging In-Reply-To: <1196567138.5738.25.camel@localhost.localdomain> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196544714.28623.19.camel@localhost.localdomain> <1196551459.4351.12.camel@rousalka.dyndns.org> <1196567138.5738.25.camel@localhost.localdomain> Message-ID: <4753CF64.9010207@codewiz.org> Sergio Monteiro Basto wrote: >> Most of the people complaining of evdev tried b. because evdev is >> underdocumented, it's a natural mistake to make and it's f* stupid to >> have made it a valid config in the first place. >> > Agree, evdev , shouldn't try use old xkbmodels Is it possible to change the XKB model from within an input driver? If not, is it at least possible to make the X server fail? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From tech at tnet.no Mon Dec 3 02:52:42 2007 From: tech at tnet.no (tech at tnet.no) Date: Mon, 3 Dec 2007 11:52:42 +0100 Subject: Fwd: Re: Multi X-session setup Message-ID: <1c2939ceafd51a6462a848ed081641e5@localhost> Hello. Thanks for your reply! How would I switch between these two sessions? Are the two screens indepdendent of eachother? Sorry for HTML and CSS, I do not have access to a computer currently, so I use a webmail that apparently is broken. On Mon, 3 Dec 2007 11:02:09 +0530, "JoJo jojo" wrote: > Hi Thomas > > If I understand correctly, here are your requirements, > -2 independent GDM sessions, (i.e play a movie on 1 screen & a browser > on another screen, example) > -1 keyboard & 1 mouse > > The simplest solution is to setup ATI big desktop(aticonfig > --dtop=horizontal etc) & disable xinerama(xorg.conf) > the down side is that you only get user login on 1 screen & both > screen are under the same user login. > > -Jojo > PS: your valid HTML isnt, your valid css isnt. > > On Dec 2, 2007 11:05 AM, wrote: >> I do not speak this language, but it seems to be a multiseat setup, and > seems to require to keyboards, which is not exactly what I want :( >> If I'm interepting this wrongly, could you explain how this concept is? >> Because I do not want to keyboards, I want two sessions active at both > sessions with one keyboard/mouse, with ability to disable/activate them on > each sessions. >> >> If this is not a suitable solution for this, is there anyone else than > can help? >> >> Thanks you. >> >> On Sat, 01 Dec 2007 07:41:12 -0200, Marcio Kleber Torres > wrote: >> > Hello. >> > >> > See this link, I think this is what you want, in any way it is the >> > beginning. >> > >> > Thank you. >> > >> > > http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu_7.04 >> > >> > >> > >> > >> > Em S?b, 2007-12-01 ?s 06:30 +0100, tech at tnet.no escreveu: >> >> Hello. >> >> >> >> I don't have this equipment yet, but I will get it later today >> > hopefully. >> >> >> >> Motherboard: MSI K9AG NEO2-Digital, AMD 690G+SB600, Socket-AM2, >> > ATX,DDR2, DVI+HDMI, PCI-Ex16 with integrated ATI Radeon X1250 GPU. >> >> PCI-Expreses video-card: Sapphire Radeon HD 2400 PRO 256MB DDR2, >> > DVI-I/Tv-out/HDMI >> >> >> >> What I want is two have two seperate X sessions, with two displays, > one >> > with tv or projector, the other my LCD monitor. Also, only one set of >> > keyboard and mouse. >> >> >> >> The tv/projector one will be mainly be used to view high-quality > video >> > (1280p or 720i in xvid or x264) through mplayer, the other monitor > will >> > just be for general stuff. >> >> >> >> I want the video/picture at the X-sessions to be active at the same >> > time, but with ability to switch between what X-session mouse and > keyboard >> > will be active/controlling to. >> >> >> >> I know there's an option for dual screen set-up, but this is not >> > something I quite feel comfortable with. >> >> >> >> What driver that will be used for whatever card is not something I > worry >> > about either, I don't mind if there's two different drivers or if any > of >> > them is closed source. >> >> >> >> Is this possible and if so could someone hint me to how to do it, > either >> > in an explanation or a reference to documentation? >> >> If it is not, could someone please list similiar options I could try? >> >> >> >> Thank you. >> >> >> >> >> >> >> _______________________________________________ >> >> 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 tom at dbservice.com Mon Dec 3 03:26:23 2007 From: tom at dbservice.com (tom at dbservice.com) Date: Mon, 03 Dec 2007 12:26:23 +0100 Subject: Fwd: Re: Multi X-session setup In-Reply-To: <1c2939ceafd51a6462a848ed081641e5@localhost> References: <1c2939ceafd51a6462a848ed081641e5@localhost> Message-ID: <20071203122623.vb3h3ee6xws88ooo@dbservice.com> > On Mon, 3 Dec 2007 11:02:09 +0530, "JoJo jojo" wrote: >> If I understand correctly, here are your requirements, >> -2 independent GDM sessions, (i.e play a movie on 1 screen & a browser >> on another screen, example) >> -1 keyboard & 1 mouse >> >> The simplest solution is to setup ATI big desktop(aticonfig >> --dtop=horizontal etc) & disable xinerama(xorg.conf) >> the down side is that you only get user login on 1 screen & both >> screen are under the same user login. How would that be two independent GDM sessions? Big desktop is nothing more that what nvidia calls TwinView, eg. two monitors presented to the xserver as one. You'd still be using one GDM session... even just one screen! I already suggested a Dual-Screen setup, but for some reason the OP doesn't want that. tech, please explain why you need two independent sessions. tom From mgedmin at b4net.lt Mon Dec 3 04:33:18 2007 From: mgedmin at b4net.lt (Marius Gedminas) Date: Mon, 3 Dec 2007 14:33:18 +0200 Subject: memory leaks in the current Xserver In-Reply-To: <20071203084137.GF26573@ics.muni.cz> References: <20071203084137.GF26573@ics.muni.cz> Message-ID: <20071203123318.GB4303@platonas> On Mon, Dec 03, 2007 at 09:41:37AM +0100, Lukas Hejtmanek wrote: > I'm using Xserver 1.4.1 () that consumes about 190MB of RAM (resident not > virtual) after running couple of days. xrestop reports that pixmaps consume > only 7MB RAM. Does it mean that there are some memory leaks? > > I have integrated graphic card with shared memory so it could mean that the > Intel driver just wastes graphic memory.. Once I had my X server eat 528 megs RSS, while xrestop claimed the clients were claiming 18 megs. I restarted compiz and X's memory usage shrank to 137 megs RSS. Apparently the memory used by textures or whatnot is not seen by xrestop. Marius Gedminas -- Writing about music is like dancing about architecture. -- Frank Zappa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From xhejtman at ics.muni.cz Mon Dec 3 04:45:37 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Mon, 3 Dec 2007 13:45:37 +0100 Subject: memory leaks in the current Xserver In-Reply-To: <20071203123318.GB4303@platonas> References: <20071203084137.GF26573@ics.muni.cz> <20071203123318.GB4303@platonas> Message-ID: <20071203124537.GI26573@ics.muni.cz> On Mon, Dec 03, 2007 at 02:33:18PM +0200, Marius Gedminas wrote: > Once I had my X server eat 528 megs RSS, while xrestop claimed the > clients were claiming 18 megs. I restarted compiz and X's memory usage > shrank to 137 megs RSS. Apparently the memory used by textures or > whatnot is not seen by xrestop. I do not use compiz or any other composite manager. I suspect these leaks are induced by firefox. -- Luk?? Hejtm?nek From daniel at fooishbar.org Mon Dec 3 04:45:13 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 12:45:13 +0000 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <4752D680.3020004@gmail.com> References: <4752D680.3020004@gmail.com> Message-ID: <20071203124513.GU6534@fooishbar.org> On Sun, Dec 02, 2007 at 05:00:00PM +0100, Brice Goglin wrote: > Kanru Chen sent the attached patch to fix the XKB options that are > passed to the server from HAL. Without this, he gets > (**) Option "xkb_options" "," > > I guess we need such a fix in master and 1.4.1. > > Full details available at the beginning of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453683 Thanks a bunch (and apologies for being so monumentally dumb: it's not only wrong, but quite obviously so by inspection alone). I've merged this to master and 1.4 branch. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Mon Dec 3 04:49:21 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 12:49:21 +0000 Subject: Control blocks Alt in keybindings In-Reply-To: <8763zgp1c5.fsf@member.fsf.org> References: <8763zgp1c5.fsf@member.fsf.org> Message-ID: <20071203124921.GV6534@fooishbar.org> On Mon, Dec 03, 2007 at 10:35:54AM +0100, Tassilo Horn wrote: > I use Xorg 7.3 on a Gentoo GNU/Linux machine. When I want to enter > keybindings involving both Control (C) and Alt (M) it seems that Control > is blocking the Alt key if I press it first. > > Let's say I want to type the binding C-M-a by first pressing Control, > then Alt and then "a", it's translated to only C-a. With xev I get the > following order: > > KP-C, KP-a, KR-a, KP-M, KR-M, KR-C > > where KP is KeyPress and KR is KeyRelease. > > I can type C-M-a by first pressing Alt, then Control and then "a". > > I tried this with both stumpwm and twm, so it shouldn't be the window > manager stealing the keys. > > I use a German Dvorak layout, but tested with > > setxkblayout "us" > > too and got the same results. > > Is this a bug or what can be the culprit? http://bugs.freedesktop.org/show_bug.cgi?id=865 will come into play if you have certain XKB options such as grp:ctrl_shift_toggle. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From RG.Schneider at t-online.de Mon Dec 3 08:41:02 2007 From: RG.Schneider at t-online.de (Ralf Schneider) Date: Mon, 03 Dec 2007 17:41:02 +0100 Subject: Question/Proposal for multiple X-Servers with multiple Graphic cards and input devices. Message-ID: <1196700063.2916.18.camel@ralaptop.se-engineering.de> Hello, currently I'm trying to set up a System as 'RDP' / 'Citrix' Client Station for 4 Users on one single Computer. Basically it is easy to configure and run. BUT:: 1. My computer has a build in graphic adapter -- which I want to use as a Administration console with the ordinary way of running the X server on a vt ( e.g. 21 ) and normal text consoles on vt's 1 to 6. For that I use the PS/2 mouse and keyboard connectors as input devices. 2. I've installed 4 more PCI graphic cards and for each grafic card additional USB mouse and keybords. The problem is that all X servers MUST be connected to a vt and vt switching must be disabled in order to run the X servers. Therefore the text vt's are not accessable anymore. ( if vt switching is enabled and one switches to one of the text vt's, ALL X servers are disabled ). QUESTION / PROPOSAL:: ===================== Why is it ( is it ? ) neccessary to assign a vt to a X server ? Would it be possible to run one X server in the usual way on (e.g.) vt 21 WITH vt switching enabled to have access to the text/framebuffer consoles AND simultaniously multiple additional x servers on onther vt without vt switching so that those users can alwayws work without being interfered by the 'Admin' user ? I hope my description is sufficiant to understand by someone else. If not, please ask back. Regards /RalfS From tassilo at member.fsf.org Mon Dec 3 05:44:07 2007 From: tassilo at member.fsf.org (Tassilo Horn) Date: Mon, 03 Dec 2007 14:44:07 +0100 Subject: Control blocks Alt in keybindings References: <8763zgp1c5.fsf@member.fsf.org> <20071203124921.GV6534@fooishbar.org> Message-ID: <87wsrvopug.fsf@member.fsf.org> Daniel Stone writes: >> [Control blocks Alt in keybindings] >> >> Is this a bug or what can be the culprit? > > http://bugs.freedesktop.org/show_bug.cgi?id=865 will come into play if > you have certain XKB options such as grp:ctrl_shift_toggle. My only option is Option "XkbOptions" "ctrl:nocaps" and indeed, if I disable it I can type C-M-a (in this order). I'll add my observations to this bug report. Bye, Tassilo From daniel at fooishbar.org Mon Dec 3 06:06:26 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 14:06:26 +0000 Subject: Question/Proposal for multiple X-Servers with multiple Graphic cards and input devices. In-Reply-To: <1196700063.2916.18.camel@ralaptop.se-engineering.de> References: <1196700063.2916.18.camel@ralaptop.se-engineering.de> Message-ID: <20071203140626.GX6534@fooishbar.org> On Mon, Dec 03, 2007 at 05:41:02PM +0100, Ralf Schneider wrote: > Why is it ( is it ? ) neccessary to assign a vt to a X server ? Because of the way the kernel's VT subsystem is designed: it's simply not built for multi-user operation. > Would it be possible to run one X server in the usual way on > (e.g.) vt 21 WITH vt switching enabled to have access to the > text/framebuffer consoles > AND > simultaniously multiple additional x servers on onther vt without vt > switching so that those users can alwayws work without being interfered > by the 'Admin' user ? Not at the moment, but it will be at some point in the future. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From pcpa at mandriva.com.br Mon Dec 3 07:40:45 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Mon, 03 Dec 2007 13:40:45 -0200 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <20071203124513.GU6534@fooishbar.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> Message-ID: <4754237D.7000206@mandriva.com.br> Daniel Stone wrote: > On Sun, Dec 02, 2007 at 05:00:00PM +0100, Brice Goglin wrote: > >> Kanru Chen sent the attached patch to fix the XKB options that are >> passed to the server from HAL. Without this, he gets >> (**) Option "xkb_options" "," >> >> I guess we need such a fix in master and 1.4.1. >> >> Full details available at the beginning of >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453683 >> > > Thanks a bunch (and apologies for being so monumentally dumb: it's not > only wrong, but quite obviously so by inspection alone). I've merged > this to master and 1.4 branch. > It is fine, we still love you :-) But I believe the code in config/hal.c needs some more rework. It must be compatible with xorg.conf, or refuse to load if xorg.conf specifies a conflicting input device, and hal should work with the kbd and mouse drivers, otherwise, if it only works with evdev, there is no point in all the configuration code. Maybe the code should just "pass" the hal options to the driver. I.e. instead of expecting a option named xkb_options of type string list, just use this code to all string_list properties. This has the advantage that the code in hal/config.c doesn't need to be update if an option changes type (or is incorrectly configured like the xkb_layout option that should be a string_list) and hal options could change type/name easily (unless there are configuration tools depending on values there), and only the input driver would need to actually "parse" the option value. If the input driver has, and will use the normal XF86Options, you could also check if the XF86Option matches the hal option type/name. > > Cheers, > Daniel > Paulo From bernie at codewiz.org Mon Dec 3 07:53:29 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 03 Dec 2007 10:53:29 -0500 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <20071203124513.GU6534@fooishbar.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> Message-ID: <47542679.10805@codewiz.org> Daniel Stone wrote: > Thanks a bunch (and apologies for being so monumentally dumb: it's not > only wrong, but quite obviously so by inspection alone). I've merged > this to master and 1.4 branch. Please also consider these two attached patches which affect the same subsystem. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: xserver-1.4-hal-really-pass-xkb_rules-plug-leak-on-xkb.patch Type: text/x-patch Size: 1574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xserver-1.4-hal-touchpad.patch Type: text/x-patch Size: 2576 bytes Desc: not available URL: From daniel at fooishbar.org Mon Dec 3 08:02:04 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 16:02:04 +0000 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <4754237D.7000206@mandriva.com.br> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> Message-ID: <20071203160204.GZ6534@fooishbar.org> On Mon, Dec 03, 2007 at 01:40:45PM -0200, Paulo Cesar Pereira de Andrade wrote: > But I believe the code in config/hal.c needs some more rework. It > must be compatible with xorg.conf, or refuse to load if xorg.conf > specifies a conflicting input device, and hal should work with the > kbd and mouse drivers, otherwise, if it only works with evdev, there > is no point in all the configuration code. Again, this isn't config/hal.c, this is hw/xfree86. NewInputDeviceRequest should just walk the config tree and DTRT, potentially calling down into the drivers to ask, 'are you handling this?'. This is why NIDR exists. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From xhejtman at ics.muni.cz Mon Dec 3 08:26:26 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Mon, 3 Dec 2007 17:26:26 +0100 Subject: INPUT problems on ThinkPad T61 In-Reply-To: <20071202113803.GB26573@ics.muni.cz> References: <20071202113803.GB26573@ics.muni.cz> Message-ID: <20071203162626.GL26573@ics.muni.cz> So, I found that both touchpad and trackpoint works fine with only default configuration (i.e., I do not have Configured mouse at all). Unfortunately, the default driver selects only the mouse driver instead of synaptics. Can I either force default driver to select another driver or disable default driver? On Sun, Dec 02, 2007 at 12:38:03PM +0100, Lukas Hejtmanek wrote: > I have Xserver 1.4.1 (git20071119) with synaptics driver 0.14.6. I have Lenovo > ThinkPad T61 which has touchpad and trackpoint. I tried many configurations > but none worked so that both touchpad and trackpoint works. > > Here is the log, I guess that the default pointer messes up things. > > (II) Synaptics touchpad driver version 0.14.6 (1406) > (--) Configured Mouse auto-dev sets device to /dev/input/event6 > (**) Option "Device" "/dev/input/event6" > (**) Option "SHMConfig" "on" > (--) Configured Mouse touchpad found > (**) Option "CorePointer" > (**) Configured Mouse: always reports core events > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/input/mice" > (--) : Device: "/dev/input/mice" > (==) : Protocol: "Auto" > (**) Option "AlwaysCore" > (**) : doesn't report core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) evaluating device () > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (II) evaluating device (Configured Mouse) > (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) > (II) evaluating device (keyboard0) > (II) XINPUT: Adding extended input device "keyboard0" (type: KEYBOARD) > (--) : PnP-detected protocol: "ExplorerPS/2" > (II) : ps2EnableDataReporting: succeeded > (--) Configured Mouse auto-dev sets device to /dev/input/event6 > (**) Option "Device" "/dev/input/event6" > (--) Configured Mouse touchpad found > > This is my config regadring the InputDevice: > Section "InputDevice" > Driver "synaptics" > Identifier "Configured Mouse" > Option "Device" "/dev/input/mice" > Option "CorePointer" > Option "SHMConfig" "on" > EndSection > > -- > Luk?? Hejtm?nek > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > -- Luk?? Hejtm?nek From pcpa at mandriva.com.br Mon Dec 3 08:34:49 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Mon, 03 Dec 2007 14:34:49 -0200 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <20071203160204.GZ6534@fooishbar.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <20071203160204.GZ6534@fooishbar.org> Message-ID: <47543029.3000109@mandriva.com.br> Daniel Stone wrote: > On Mon, Dec 03, 2007 at 01:40:45PM -0200, Paulo Cesar Pereira de Andrade wrote: > >> But I believe the code in config/hal.c needs some more rework. It >> must be compatible with xorg.conf, or refuse to load if xorg.conf >> specifies a conflicting input device, and hal should work with the >> kbd and mouse drivers, otherwise, if it only works with evdev, there >> is no point in all the configuration code. >> > > Again, this isn't config/hal.c, this is hw/xfree86. > NewInputDeviceRequest should just walk the config tree and DTRT, > potentially calling down into the drivers to ask, 'are you handling > this?'. This is why NIDR exists. > > Cheers, > Daniel > This maybe a bit late (or too early if one changes the code to load hal specified devices before xorg.conf ones). And expecting NewInputDeviceRequest to fix the fact that hal devices cannot map to xorg.conf devices may be too much to ask. IMO the proper fix is to match the xorg.conf input device section with the hal section (don't ask me how to do it, I don't know, that's why I filled the bug report https://bugs.freedesktop.org/show_bug.cgi?id=13361), if the xorg.conf code and hal code coexist in the X Server, and "one doesn't know about the other" and both load one module to handle the same input device, things are unlikely to work properly. And the EVIOCGRAB ioctl should not be a justification to have 2 different modules handling the same device. It works with evdev, but the mouse driver, as I reported earlier will generate duplicated events, and mixing evdev with kbd and mouse is wrong. Paulo From daniel at fooishbar.org Mon Dec 3 08:53:31 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 16:53:31 +0000 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <47543029.3000109@mandriva.com.br> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <20071203160204.GZ6534@fooishbar.org> <47543029.3000109@mandriva.com.br> Message-ID: <20071203165331.GA6534@fooishbar.org> On Mon, Dec 03, 2007 at 02:34:49PM -0200, Paulo Cesar Pereira de Andrade wrote: > Daniel Stone wrote: >> Again, this isn't config/hal.c, this is hw/xfree86. >> NewInputDeviceRequest should just walk the config tree and DTRT, >> potentially calling down into the drivers to ask, 'are you handling >> this?'. This is why NIDR exists. > > This maybe a bit late (or too early if one changes the code to > load hal specified devices before xorg.conf ones). ??? config/hal.c doesn't add any devices at all: it merely suggests that the DDX may want to do so. If you parse the configuration first (and you do, because you only connect to D-Bus in your first run through WaitForSomething, as it's hanging off a timer), then you just make NewInputDeviceRequest check the list of configured devices from xorg.conf, and do nothing if there's already a matching device. > And expecting > NewInputDeviceRequest to fix the fact that hal devices cannot map > to xorg.conf devices may be too much to ask. Er? XFree86 devices are valid _only_ in hw/xfree86. NewInputDeviceRequest is in hw/xfree86. config/hal.c ... is not. This is in fact basically the only place where you could do this mapping. > IMO the proper fix is to match the xorg.conf input device > section with the hal section (don't ask me how to do it, I don't > know, that's why I filled the bug report > https://bugs.freedesktop.org/show_bug.cgi?id=13361), > if the xorg.conf code and hal code coexist in the X Server, and > "one doesn't know about the other" and both load one module to > handle the same input device, things are unlikely to work properly. Of course not. But the reason NewInputDeviceRequest _exists_ is so the DDX can decide what to do with hints as to whether to add input devices. For Xvfb, the answer is to ignore them completely. For KDrive, the answer is[0] to ignore them if you already have a similar device on the command line. For Xorg, the answer would be to ignore them if you've already got a very similar device configured. Doing it in config/hal.c is literally impossible, as the input infrastructure is DDX-specific. Just do it in NewInputDeviceRequest; it's actually really easy. There are a couple of options: * Add driver hooks to query a certain device if it already owns this, then query all devices at NIDR. For kbd and mouse, always return true; for evdev, return true if the paths are identical. * Do almost exactly the same inside NIDR itself. The only problem I see here is with symlinks, but, well, life's tough. > And the EVIOCGRAB ioctl should not be a justification to have > 2 different modules handling the same device. It works with > evdev, but the mouse driver, as I reported earlier will generate > duplicated events, and mixing evdev with kbd and mouse is wrong. Well, having kbd and mouse around at all is 'wrong', really. Cheers, Daniel [0]: An examination of the code shows that this is not currently the case, but I do have a firm recollection of writing that code. -------------- 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 Dec 3 09:01:52 2007 From: davidr at novell.com (David Reveman) Date: Mon, 03 Dec 2007 12:01:52 -0500 Subject: Faster window resize in a composite manager In-Reply-To: <200711180415.35581.onestone@opencompositing.org> References: <200710161454.29558.onestone@opencompositing.org> <1194989773.7367.124.camel@ion.ximian> <200711180415.35581.onestone@opencompositing.org> Message-ID: <1196701312.29127.111.camel@ion.ximian> On Sun, 2007-11-18 at 04:15 +0100, Dennis Kasprzyk wrote: > Am Dienstag, 13. November 2007 22:36:13 schrieb David Reveman: > > On Tue, 2007-10-16 at 14:54 +0200, Dennis Kasprzyk wrote: > > > Hi, > > > > > > I've implemented my idea from my "Idea how to fix slow window resize in a > > > composited desktop" post. My patches add a new function > > > XCompositeSetWindowPixmapSize to Xcomposite. The compositing manager can > > > use this function to set the window pixmap to the desired size, and the > > > xserver will not change the pixmap and it's size during a resize. If > > > XCompositeSetWindowPixmapSize is called with 0/0 as size, the xserver > > > switches back to it's current pixmap handling and resizes the current > > > pixmap back to the window size. > > > > I fail to see how this would improve performance while my suggestion of > > reparenting the window we're resizing to a larger temporary top level > > window doesn't. It should end up the same thing as far as the DDX care, > > or am I missing something? > > > > -David > > I've tried to implement your idea and I haven't seen any performance > improvement, but maybe this was caused by a mistake that I've made during the > implementation of your idea. After getting some responses for my idea on the > mailinglist/irc, I think that it would make more sense to improve the > composite extension and not to try to workaround our problems directly in the > composite manager. > > Currently we assume that the window pixmap matches also the window size and we > also assume that the window pixmap changes (and call > XCompositeNameWindowPixmap) with each window resize. Due to some hardware > limitations it could make sense to to keep the redirected window (and pixmap) > size, in limits that could be fully/better hardware accelerated. For example > it could make sense for some hardware platforms to make the window pixmap > dimensions always be an even number or divisible by 8, to achieve better > performance. The best solution to achieve this, would be a new event, that > informs the composite manager that the window pixmap has been changed. This > event could also contain all information's about the window pixmap, to avoid > the need to call XGetGeometry. An XCompositeSetWindowPixmapSize could then > inform the xserver/ddx that the window will be resized and that it would make > sense to resize the pixmap to the given dimensions, and the xserver/ddx could > decide what should be done. Looking at the current resize performance in Xgl > for example there should be no need to resize the window pixmap because > resizing in Xgl seams to be fast enough (on my hardware). For the current > AIGLX/Nvidia texture-from-pixmap implementations (tested with nvidia & fglrx > aiglx) it would make more sense to resize the window pixmap to big dimesions > if the composite manager thinks that the window size will changed multiple > times. > > Even if we could workaround the current bad resize performance directly in > compiz, I still think that it would make more sense to provide flexible > window pixmap system directly in the xserver. > I know that my patches may be not fully correct, but maybe someone with enough > knowledge about the xserver will find the time to do it right. Sure, I'm all for improving the server if it makes sense. An window-pixmap changed event might be a good solution. You can't really add XCompositeSetWindowPixmapSize without such an event as it wouldn't be possible for other clients than the one who sent the pixmap-size request to use the window pixmap otherwise... -David From nicolas.mailhot at laposte.net Mon Dec 3 09:22:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Dec 2007 18:22:35 +0100 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <4754237D.7000206@mandriva.com.br> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> Message-ID: <1196702555.16394.8.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 13:40 -0200, Paulo Cesar Pereira de Andrade a ?crit : > and hal should work with the > kbd and mouse drivers, otherwise, if it only works with evdev, there > is no point in all the configuration code. Of course there is XkbModel is useless with evdev but XkbLayout, XkbVariant and XkbOptions still need to be set. kbd and mouse are mostly not needed and trying to support them in addition to evdev is a large part of the current mess. Efforts would be better spent fixing the few bits evdev is missing instead of retrofitting X different input drivers in a single server. And evdev works just fine when configured properly, if only because it's the kernel input view, and if the kernel was wrong the console would not work in the first place. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jcristau at debian.org Mon Dec 3 09:35:07 2007 From: jcristau at debian.org (Julien Cristau) Date: Mon, 3 Dec 2007 18:35:07 +0100 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <1196702555.16394.8.camel@rousalka.dyndns.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> Message-ID: <20071203173507.GA24032@patate.is-a-geek.org> On Mon, Dec 3, 2007 at 18:22:35 +0100, Nicolas Mailhot wrote: > And evdev works just fine when configured properly, if only because it's > the kernel input view, and if the kernel was wrong the console would not > work in the first place. > "Just fine" except after a few suspend/resume cycles and hot-(un)plugs, where I get: usb 2-2: configuration #1 chosen from 1 choice input: Logitech USB-PS/2 Optical Mouse as /class/input/input64 evdev: no more free evdev devices input: failed to attach handler evdev to device input64, error: -23 input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.1-2 in dmesg, and can't use my mouse in X. Cheers, Julien From daniel.stone at nokia.com Mon Dec 3 09:37:30 2007 From: daniel.stone at nokia.com (Daniel Stone) Date: Mon, 3 Dec 2007 19:37:30 +0200 Subject: Xorg Input Hotplugging In-Reply-To: <200711302115.21487.arvidjaar@mail.ru> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> Message-ID: <20071203173730.GA5124@intune.research.nokia.com> On Fri, Nov 30, 2007 at 09:15:19PM +0300, ext Andrey Borzenkov wrote: > On Thursday 15 November 2007, Nicolas Mailhot wrote: > > > at least one of the properties for your devices should contain their > > > usb vendor/product IDs. > > > > > > other properties xorg understands for keyboards: > > > - input.xkb.rules > > > - input.xkb.model > > Should not it be actually "evdev" always? As evdev is really the only driver > that would work? evdev is Linux-specific, and even then, hardware-specific drivers like wacom work too. > > > - input.xkb.options > > Does not work; results in empty string with commas, something like ",," > and X loops taking almost all CPU time. This is fixed in git. > > > xorg will look for devices with these capabilities (info.capabilities): > > > - input.keys > > > - input.keyboard (deprecated) > > > - input.mouse > > > - input.touchpad > > > > > > xorg expects these properties to be set on these devices: > > > - input.x11_driver > > Can I really set anything besides evdev, given, that ... Yes, see above. > > in the brave new hotplug world? > > And how I resurrect my 3rd button emulation on notebook with 2 buttons? This looks like a missing feature in evdev. > Anyway here is what I tried as FDI: > > {pts/0}% cat /etc/hal/fdi/policy/x11-keyboard.fdi > > > > > > xorg > gb,ru(winkeys) gb,ru ,winkeys > grp:menu_toggle > grp_led:scroll > > > Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel.stone at nokia.com Mon Dec 3 09:38:51 2007 From: daniel.stone at nokia.com (Daniel Stone) Date: Mon, 3 Dec 2007 19:38:51 +0200 Subject: Xorg Input Hotplugging In-Reply-To: References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> Message-ID: <20071203173851.GB5124@intune.research.nokia.com> On Sat, Dec 01, 2007 at 08:17:01PM +0100, ext Pixel wrote: > agreed. IMO XkbModel should not even be supported by evdev driver Except that it should. The current xkeyboard-config ruleset only supports model 'evdev', but in the future, this should be fixed. Particularly given that model information is used for geometry, which does actually vary from keyboard to keyboard. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nicolas.mailhot at laposte.net Mon Dec 3 09:22:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Dec 2007 18:22:35 +0100 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <4754237D.7000206@mandriva.com.br> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> Message-ID: <1196702555.16394.8.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 13:40 -0200, Paulo Cesar Pereira de Andrade a ?crit : > and hal should work with the > kbd and mouse drivers, otherwise, if it only works with evdev, there > is no point in all the configuration code. Of course there is XkbModel is useless with evdev but XkbLayout, XkbVariant and XkbOptions still need to be set. kbd and mouse are mostly not needed and trying to support them in addition to evdev is a large part of the current mess. Efforts would be better spent fixing the few bits evdev is missing instead of retrofitting X different input drivers in a single server. And evdev works just fine when configured properly, if only because it's the kernel input view, and if the kernel was wrong the console would not work in the first place. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Dec 3 09:53:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Dec 2007 18:53:26 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <20071203173730.GA5124@intune.research.nokia.com> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <20071203173730.GA5124@intune.research.nokia.com> Message-ID: <1196704406.22059.1.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 19:37 +0200, Daniel Stone a ?crit : > > > > > > > > xorg > > gb,ru(winkeys) > gb,ru > ,winkeys Is the , before winkeys needed? > > grp:menu_toggle > > grp_led:scroll > > > > > > -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Dec 3 09:56:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Dec 2007 18:56:45 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <20071203173851.GB5124@intune.research.nokia.com> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <20071203173851.GB5124@intune.research.nokia.com> Message-ID: <1196704605.22059.6.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 19:38 +0200, Daniel Stone a ?crit : > On Sat, Dec 01, 2007 at 08:17:01PM +0100, ext Pixel wrote: > > agreed. IMO XkbModel should not even be supported by evdev driver > > Except that it should. The current xkeyboard-config ruleset only > supports model 'evdev', but in the future, this should be fixed. > Particularly given that model information is used for geometry, which > does actually vary from keyboard to keyboard. If more evdev models are actually wanted and creating them is documented somewhere I may contribute mine then as soon as ajax restores evdev to rawhide (hint, hint) by linking rawhide against dbus and hal. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From daniel.stone at nokia.com Mon Dec 3 09:59:20 2007 From: daniel.stone at nokia.com (Daniel Stone) Date: Mon, 3 Dec 2007 19:59:20 +0200 Subject: Xorg Input Hotplugging In-Reply-To: <1196704406.22059.1.camel@rousalka.dyndns.org> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <20071203173730.GA5124@intune.research.nokia.com> <1196704406.22059.1.camel@rousalka.dyndns.org> Message-ID: <20071203175920.GA5775@intune.research.nokia.com> On Mon, Dec 03, 2007 at 06:53:26PM +0100, ext Nicolas Mailhot wrote: > Le lundi 03 d?cembre 2007 ? 19:37 +0200, Daniel Stone a ?crit : > > gb,ru > > ,winkeys > > Is the , before winkeys needed? Yes, otherwise you'll have gb(winkeys) and ru; not gb and ru(winkeys). Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nicolas.mailhot at laposte.net Mon Dec 3 10:15:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Dec 2007 19:15:21 +0100 Subject: Xorg Input Hotplugging In-Reply-To: <20071203175920.GA5775@intune.research.nokia.com> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <20071203173730.GA5124@intune.research.nokia.com> <1196704406.22059.1.camel@rousalka.dyndns.org> <20071203175920.GA5775@intune.research.nokia.com> Message-ID: <1196705721.22059.20.camel@rousalka.dyndns.org> Le lundi 03 d?cembre 2007 ? 19:59 +0200, Daniel Stone a ?crit : > On Mon, Dec 03, 2007 at 06:53:26PM +0100, ext Nicolas Mailhot wrote: > > Le lundi 03 d?cembre 2007 ? 19:37 +0200, Daniel Stone a ?crit : > > > gb,ru > > > ,winkeys > > > > Is the , before winkeys needed? > > Yes, otherwise you'll have gb(winkeys) and ru; not gb and ru(winkeys). That is seriously broken and user-unfriendly XML :(. Has it been written by gconf developers? Is it not possible to do something more intuitive like ? ? ie something that actually uses XML hierachical nature to describe hierarchies? I mean what's the point of inflicting tags on users if they're not even used to tokenise properties properly. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From daniel at fooishbar.org Mon Dec 3 10:35:46 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 3 Dec 2007 18:35:46 +0000 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <20071203173507.GA24032@patate.is-a-geek.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> <20071203173507.GA24032@patate.is-a-geek.org> Message-ID: <20071203183546.GB6534@fooishbar.org> On Mon, Dec 03, 2007 at 06:35:07PM +0100, Julien Cristau wrote: > On Mon, Dec 3, 2007 at 18:22:35 +0100, Nicolas Mailhot wrote: > > And evdev works just fine when configured properly, if only because it's > > the kernel input view, and if the kernel was wrong the console would not > > work in the first place. > > "Just fine" except after a few suspend/resume cycles and hot-(un)plugs, > where I get: > usb 2-2: configuration #1 chosen from 1 choice > input: Logitech USB-PS/2 Optical Mouse as /class/input/input64 > evdev: no more free evdev devices > input: failed to attach handler evdev to device input64, error: -23 > input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.1-2 > in dmesg, and can't use my mouse in X. That should be pretty trivially fixable. I'm sure the kernel guys would welcome the bug report ... Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From krh at bitplanet.net Mon Dec 3 10:40:58 2007 From: krh at bitplanet.net (=?utf-8?q?Kristian=20H=C3=B8gsberg?=) Date: Mon, 3 Dec 2007 13:40:58 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. Message-ID: <1196707258-8688-1-git-send-email-krh@bitplanet.net> From: Kristian H?gsberg The driver uses MI_SET_CONTEXT to save the current state before emitting the invariant 3d state. Nothing ever restores this state though, so this patch removes that. This was also the only remaining use of the ring buffer in TTM mode, so we're one step closer to a ring-buffer free DDX driver. --- src/common.h | 2 +- src/i830.h | 2 -- src/i830_driver.c | 11 ----------- src/i830_memory.c | 10 ---------- 4 files changed, 1 insertions(+), 24 deletions(-) diff --git a/src/common.h b/src/common.h index f558e8f..46bfa8e 100644 --- a/src/common.h +++ b/src/common.h @@ -232,7 +232,7 @@ union intfloat { #define BEGIN_LP_RING(n) \ RING_LOCALS \ - DO_LP_RING(n) \ + DO_LP_RING(n) /* Memory mapped register access macros */ #define INREG8(addr) *(volatile CARD8 *)(RecPtr->MMIOBase + (addr)) diff --git a/src/i830.h b/src/i830.h index 9387651..cbc1b93 100644 --- a/src/i830.h +++ b/src/i830.h @@ -404,8 +404,6 @@ typedef struct _I830Rec { void (*PointerMoved)(int, int, int); CreateScreenResourcesProcPtr CreateScreenResources; - i830_memory *logical_context; - #ifdef XF86DRI i830_memory *back_buffer; i830_memory *third_buffer; diff --git a/src/i830_driver.c b/src/i830_driver.c index 6393a61..27df05b 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -2254,17 +2254,6 @@ IntelEmitInvarientState(ScrnInfoPtr pScrn) if (*pI830->last_3d != LAST_3D_OTHER) return; - ctx_addr = pI830->logical_context->offset; - assert((pI830->logical_context->offset & 2047) == 0); - { - BEGIN_LP_RING(2); - OUT_RING(MI_SET_CONTEXT); - OUT_RING(pI830->logical_context->offset | - CTXT_NO_RESTORE | - CTXT_PALETTE_SAVE_DISABLE | CTXT_PALETTE_RESTORE_DISABLE); - ADVANCE_LP_RING(); - } - if (!IS_I965G(pI830)) { if (IS_I9XX(pI830)) diff --git a/src/i830_memory.c b/src/i830_memory.c index 85b6528..6287bab 100644 --- a/src/i830_memory.c +++ b/src/i830_memory.c @@ -347,7 +347,6 @@ i830_reset_allocations(ScrnInfoPtr pScrn) pI830->exa_offscreen = NULL; pI830->exa_965_state = NULL; pI830->overlay_regs = NULL; - pI830->logical_context = NULL; #ifdef XF86DRI pI830->back_buffer = NULL; pI830->third_buffer = NULL; @@ -1356,15 +1355,6 @@ i830_allocate_2d_memory(ScrnInfoPtr pScrn) pI830->SWCursor = TRUE; } - /* Space for the X Server's 3D context. 32k is fine for right now. */ - pI830->logical_context = i830_allocate_memory(pScrn, "logical 3D context", - KB(32), GTT_PAGE_SIZE, 0); - if (pI830->logical_context == NULL) { - xf86DrvMsg(pScrn->scrnIndex, X_WARNING, - "Failed to allocate logical context space.\n"); - return FALSE; - } - /* even in XAA, 965G needs state mem buffer for rendering */ if (IS_I965G(pI830) && !pI830->noAccel && pI830->exa_965_state == NULL) { pI830->exa_965_state = -- 1.5.3.4 From onetwojojo at gmail.com Mon Dec 3 10:44:07 2007 From: onetwojojo at gmail.com (JoJo jojo) Date: Tue, 4 Dec 2007 00:14:07 +0530 Subject: Multi X-session setup In-Reply-To: <1c2939ceafd51a6462a848ed081641e5@localhost> References: <1c2939ceafd51a6462a848ed081641e5@localhost> Message-ID: <226dee610712031044l18fb86e7ufb127be3eea95c0f@mail.gmail.com> Hi I stand corrected, that was technically 1 GDM session, with 2 screens, the way I see it the problem is now this:- If we run 2 X servers using both GFX, then sharing Keyboard & Mouse is a problem, If we run 1 X server on 1 GFX with 2 Screens, then we get only 1 GDM session. I would suggest to go along with the 2nd option, get only 1 GDM session, "How would I switch between these two sessions?" Generally we can setup 2 screens right next to each other, when mouse goes over the edge it appears on the next screen(keyboard focus follows the mouse click) "Are the two screens independent of each other?" I dunno what you mean by that, with xinerama enabled the two screens merge seamlessly(one big desktop, fullscreen application half visible on one screen, half on the other screen), with xinerama disabled they act independently(two desktops, fullscreen applications occupy). If you still decide to go with 2 X servers, you could hardcode via udev rules, the exact USB ports(for keyboard mouse, to each seat, yup multiseat) then to use one seat, you plug in the input marked for that seat, to use the TV/Projector seat you plugin the inputs marked for the other seat I believe Two Screens is what you are after, instead of two X servers. -Jojo On Dec 3, 2007 4:22 PM, wrote: > > Hello. > Thanks for your reply! > > How would I switch between these two sessions? > Are the two screens indepdendent of eachother? > > Sorry for HTML and CSS, I do not have access to a computer currently, so I use > a webmail that apparently is broken. > > On Mon, 3 Dec 2007 11:02:09 +0530, "JoJo jojo" wrote: > > Hi Thomas > > > > If I understand correctly, here are your requirements, > > -2 independent GDM sessions, (i.e play a movie on 1 screen & a browser > > on another screen, example) > > -1 keyboard & 1 mouse > > > > The simplest solution is to setup ATI big desktop(aticonfig > > --dtop=horizontal etc) & disable xinerama(xorg.conf) > > the down side is that you only get user login on 1 screen & both > > screen are under the same user login. > > > > -Jojo > > PS: your valid HTML isnt, your valid css isnt. > > > > On Dec 2, 2007 11:05 AM, wrote: > >> I do not speak this language, but it seems to be a multiseat setup, and > > seems to require to keyboards, which is not exactly what I want :( > >> If I'm interepting this wrongly, could you explain how this concept is? > >> Because I do not want to keyboards, I want two sessions active at both > > sessions with one keyboard/mouse, with ability to disable/activate them on > > each sessions. > >> > >> If this is not a suitable solution for this, is there anyone else than > > can help? > >> > >> Thanks you. > >> > >> On Sat, 01 Dec 2007 07:41:12 -0200, Marcio Kleber Torres > > wrote: > >> > Hello. > >> > > >> > See this link, I think this is what you want, in any way it is the > >> > beginning. > >> > > >> > Thank you. > >> > > >> > > > > http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu_7.04 > >> > > >> > > >> > > >> > > >> > Em S?b, 2007-12-01 ?s 06:30 +0100, tech at tnet.no escreveu: > >> >> Hello. > >> >> > >> >> I don't have this equipment yet, but I will get it later today > >> > hopefully. > >> >> > >> >> Motherboard: MSI K9AG NEO2-Digital, AMD 690G+SB600, Socket-AM2, > >> > ATX,DDR2, DVI+HDMI, PCI-Ex16 with integrated ATI Radeon X1250 GPU. > >> >> PCI-Expreses video-card: Sapphire Radeon HD 2400 PRO 256MB DDR2, > >> > DVI-I/Tv-out/HDMI > >> >> > >> >> What I want is two have two seperate X sessions, with two displays, > > one > >> > with tv or projector, the other my LCD monitor. Also, only one set of > >> > keyboard and mouse. > >> >> > >> >> The tv/projector one will be mainly be used to view high-quality > > video > >> > (1280p or 720i in xvid or x264) through mplayer, the other monitor > > will > >> > just be for general stuff. > >> >> > >> >> I want the video/picture at the X-sessions to be active at the same > >> > time, but with ability to switch between what X-session mouse and > > keyboard > >> > will be active/controlling to. > >> >> > >> >> I know there's an option for dual screen set-up, but this is not > >> > something I quite feel comfortable with. > >> >> > >> >> What driver that will be used for whatever card is not something I > > worry > >> > about either, I don't mind if there's two different drivers or if any > > of > >> > them is closed source. > >> >> > >> >> Is this possible and if so could someone hint me to how to do it, > > either > >> > in an explanation or a reference to documentation? > >> >> If it is not, could someone please list similiar options I could try? > >> >> > >> >> Thank you. > >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From daniel.stone at nokia.com Mon Dec 3 10:37:20 2007 From: daniel.stone at nokia.com (Daniel Stone) Date: Mon, 3 Dec 2007 20:37:20 +0200 Subject: Xorg Input Hotplugging In-Reply-To: <1196705721.22059.20.camel@rousalka.dyndns.org> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <20071203173730.GA5124@intune.research.nokia.com> <1196704406.22059.1.camel@rousalka.dyndns.org> <20071203175920.GA5775@intune.research.nokia.com> <1196705721.22059.20.camel@rousalka.dyndns.org> Message-ID: <20071203183720.GA6340@intune.research.nokia.com> On Mon, Dec 03, 2007 at 07:15:21PM +0100, ext Nicolas Mailhot wrote: > Le lundi 03 d?cembre 2007 ? 19:59 +0200, Daniel Stone a ?crit : > > On Mon, Dec 03, 2007 at 06:53:26PM +0100, ext Nicolas Mailhot wrote: > > > Le lundi 03 d?cembre 2007 ? 19:37 +0200, Daniel Stone a ?crit : > > > > gb,ru > > > > ,winkeys > > > > > > Is the , before winkeys needed? > > > > Yes, otherwise you'll have gb(winkeys) and ru; not gb and ru(winkeys). > > That is seriously broken and user-unfriendly XML :(. Has it been written > by gconf developers? Is it not possible to do something more intuitive > like > > > > ? > ? > > > > ie something that actually uses XML hierachical nature to describe > hierarchies? I mean what's the point of inflicting tags on users if > they're not even used to tokenise properties properly. Right now, it merely maps one to one to the existing XKB properties of the same name. I agree that a better hierachical mapping would be more than welcome (especially with model-specific layouts), and am definitely happy to take patches. :) Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From keith at tungstengraphics.com Mon Dec 3 11:22:08 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Mon, 03 Dec 2007 19:22:08 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <1196707258-8688-1-git-send-email-krh@bitplanet.net> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> Message-ID: <47545760.4080404@tungstengraphics.com> It is necessary to do at least on MI_SET_CONTEXT on driver initialization, otherwise hardware will hang. Possibly you've only tested on hardware that has run an older version of the driver once already, or possibly there is now another component (eg the EXA driver) emitting these. It is also necessary to do an MI_SET_CONTEXT in case there is a 3d client out there *really using* MI_SET_CONTEXT. IE. if I modify the EXA driver to use MI_SET_CONTEXT, and you remove this code from the 3d driver, you will get unexpected results. This MI_SET_CONTEXT would cause the other context to be saved -- ie the hardware only does something on transitions between different hardware contexts, and it is only with this packet that it knows there is a context switch... In other words, I don't think this is a good idea... Keith Kristian H?gsberg wrote: > From: Kristian H?gsberg > > The driver uses MI_SET_CONTEXT to save the current state before > emitting the invariant 3d state. Nothing ever restores this state though, > so this patch removes that. This was also the only remaining use of > the ring buffer in TTM mode, so we're one step closer to a ring-buffer > free DDX driver. > --- > src/common.h | 2 +- > src/i830.h | 2 -- > src/i830_driver.c | 11 ----------- > src/i830_memory.c | 10 ---------- > 4 files changed, 1 insertions(+), 24 deletions(-) > > diff --git a/src/common.h b/src/common.h > index f558e8f..46bfa8e 100644 > --- a/src/common.h > +++ b/src/common.h > @@ -232,7 +232,7 @@ union intfloat { > > #define BEGIN_LP_RING(n) \ > RING_LOCALS \ > - DO_LP_RING(n) \ > + DO_LP_RING(n) > > /* Memory mapped register access macros */ > #define INREG8(addr) *(volatile CARD8 *)(RecPtr->MMIOBase + (addr)) > diff --git a/src/i830.h b/src/i830.h > index 9387651..cbc1b93 100644 > --- a/src/i830.h > +++ b/src/i830.h > @@ -404,8 +404,6 @@ typedef struct _I830Rec { > void (*PointerMoved)(int, int, int); > CreateScreenResourcesProcPtr CreateScreenResources; > > - i830_memory *logical_context; > - > #ifdef XF86DRI > i830_memory *back_buffer; > i830_memory *third_buffer; > diff --git a/src/i830_driver.c b/src/i830_driver.c > index 6393a61..27df05b 100644 > --- a/src/i830_driver.c > +++ b/src/i830_driver.c > @@ -2254,17 +2254,6 @@ IntelEmitInvarientState(ScrnInfoPtr pScrn) > if (*pI830->last_3d != LAST_3D_OTHER) > return; > > - ctx_addr = pI830->logical_context->offset; > - assert((pI830->logical_context->offset & 2047) == 0); > - { > - BEGIN_LP_RING(2); > - OUT_RING(MI_SET_CONTEXT); > - OUT_RING(pI830->logical_context->offset | > - CTXT_NO_RESTORE | > - CTXT_PALETTE_SAVE_DISABLE | CTXT_PALETTE_RESTORE_DISABLE); > - ADVANCE_LP_RING(); > - } > - > if (!IS_I965G(pI830)) > { > if (IS_I9XX(pI830)) > diff --git a/src/i830_memory.c b/src/i830_memory.c > index 85b6528..6287bab 100644 > --- a/src/i830_memory.c > +++ b/src/i830_memory.c > @@ -347,7 +347,6 @@ i830_reset_allocations(ScrnInfoPtr pScrn) > pI830->exa_offscreen = NULL; > pI830->exa_965_state = NULL; > pI830->overlay_regs = NULL; > - pI830->logical_context = NULL; > #ifdef XF86DRI > pI830->back_buffer = NULL; > pI830->third_buffer = NULL; > @@ -1356,15 +1355,6 @@ i830_allocate_2d_memory(ScrnInfoPtr pScrn) > pI830->SWCursor = TRUE; > } > > - /* Space for the X Server's 3D context. 32k is fine for right now. */ > - pI830->logical_context = i830_allocate_memory(pScrn, "logical 3D context", > - KB(32), GTT_PAGE_SIZE, 0); > - if (pI830->logical_context == NULL) { > - xf86DrvMsg(pScrn->scrnIndex, X_WARNING, > - "Failed to allocate logical context space.\n"); > - return FALSE; > - } > - > /* even in XAA, 965G needs state mem buffer for rendering */ > if (IS_I965G(pI830) && !pI830->noAccel && pI830->exa_965_state == NULL) { > pI830->exa_965_state = From irwin at beluga.phys.uvic.ca Mon Dec 3 11:21:06 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 03 Dec 2007 11:21:06 -0800 (PST) Subject: memory leaks in the current Xserver In-Reply-To: <20071203124537.GI26573@ics.muni.cz> References: <20071203084137.GF26573@ics.muni.cz> <20071203123318.GB4303@platonas> <20071203124537.GI26573@ics.muni.cz> Message-ID: On 2007-12-03 13:45+0100 Lukas Hejtmanek wrote: > On Mon, Dec 03, 2007 at 02:33:18PM +0200, Marius Gedminas wrote: >> Once I had my X server eat 528 megs RSS, while xrestop claimed the >> clients were claiming 18 megs. I restarted compiz and X's memory usage >> shrank to 137 megs RSS. Apparently the memory used by textures or >> whatnot is not seen by xrestop. > > I do not use compiz or any other composite manager. I suspect these leaks are > induced by firefox. The memory-leak behaviour I am seeing is that roughly 2MB/hour is added to the Res column in "top" for Xorg for a completely inactive KDE desktop. This was an overnight test with akregator and all instances of browsers turned off and no special 3D desktop effects configured. For example, my screensaver was just the blank screen. For an active KDE desktop the 2MB/hour leak continues with no substantial change in the memory-leak rate. So I think this memory leak is in some commonly used part of the the X server as opposed to being a memory leak that is induced only by certain individual X clients such as firefox. Daniel, you might want to just try invoking bare X (with no clients) to see if you get the leak in that circumstance. If bare X has the memory leak, then that should substantially narrow your search for the cause. I am running a lightly patched (see previous thread) version 2.2.0 of the xf86-video-intel driver module on the Intel g33 chipset. This is for the Debian unstable version of xorg which (for package xserver-xorg-core) is version 2:1.4.1~git20071119-1. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From keith at tungstengraphics.com Mon Dec 3 11:23:25 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Mon, 03 Dec 2007 19:23:25 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <1196707258-8688-1-git-send-email-krh@bitplanet.net> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> Message-ID: <475457AD.7020502@tungstengraphics.com> Kristian -- following up on myself, this should probably be part of the invarient state, rather than removed altogether. Keith Kristian H?gsberg wrote: > From: Kristian H?gsberg > > The driver uses MI_SET_CONTEXT to save the current state before > emitting the invariant 3d state. Nothing ever restores this state though, > so this patch removes that. This was also the only remaining use of > the ring buffer in TTM mode, so we're one step closer to a ring-buffer > free DDX driver. > --- > src/common.h | 2 +- > src/i830.h | 2 -- > src/i830_driver.c | 11 ----------- > src/i830_memory.c | 10 ---------- > 4 files changed, 1 insertions(+), 24 deletions(-) > > diff --git a/src/common.h b/src/common.h > index f558e8f..46bfa8e 100644 > --- a/src/common.h > +++ b/src/common.h > @@ -232,7 +232,7 @@ union intfloat { > > #define BEGIN_LP_RING(n) \ > RING_LOCALS \ > - DO_LP_RING(n) \ > + DO_LP_RING(n) > > /* Memory mapped register access macros */ > #define INREG8(addr) *(volatile CARD8 *)(RecPtr->MMIOBase + (addr)) > diff --git a/src/i830.h b/src/i830.h > index 9387651..cbc1b93 100644 > --- a/src/i830.h > +++ b/src/i830.h > @@ -404,8 +404,6 @@ typedef struct _I830Rec { > void (*PointerMoved)(int, int, int); > CreateScreenResourcesProcPtr CreateScreenResources; > > - i830_memory *logical_context; > - > #ifdef XF86DRI > i830_memory *back_buffer; > i830_memory *third_buffer; > diff --git a/src/i830_driver.c b/src/i830_driver.c > index 6393a61..27df05b 100644 > --- a/src/i830_driver.c > +++ b/src/i830_driver.c > @@ -2254,17 +2254,6 @@ IntelEmitInvarientState(ScrnInfoPtr pScrn) > if (*pI830->last_3d != LAST_3D_OTHER) > return; > > - ctx_addr = pI830->logical_context->offset; > - assert((pI830->logical_context->offset & 2047) == 0); > - { > - BEGIN_LP_RING(2); > - OUT_RING(MI_SET_CONTEXT); > - OUT_RING(pI830->logical_context->offset | > - CTXT_NO_RESTORE | > - CTXT_PALETTE_SAVE_DISABLE | CTXT_PALETTE_RESTORE_DISABLE); > - ADVANCE_LP_RING(); > - } > - > if (!IS_I965G(pI830)) > { > if (IS_I9XX(pI830)) > diff --git a/src/i830_memory.c b/src/i830_memory.c > index 85b6528..6287bab 100644 > --- a/src/i830_memory.c > +++ b/src/i830_memory.c > @@ -347,7 +347,6 @@ i830_reset_allocations(ScrnInfoPtr pScrn) > pI830->exa_offscreen = NULL; > pI830->exa_965_state = NULL; > pI830->overlay_regs = NULL; > - pI830->logical_context = NULL; > #ifdef XF86DRI > pI830->back_buffer = NULL; > pI830->third_buffer = NULL; > @@ -1356,15 +1355,6 @@ i830_allocate_2d_memory(ScrnInfoPtr pScrn) > pI830->SWCursor = TRUE; > } > > - /* Space for the X Server's 3D context. 32k is fine for right now. */ > - pI830->logical_context = i830_allocate_memory(pScrn, "logical 3D context", > - KB(32), GTT_PAGE_SIZE, 0); > - if (pI830->logical_context == NULL) { > - xf86DrvMsg(pScrn->scrnIndex, X_WARNING, > - "Failed to allocate logical context space.\n"); > - return FALSE; > - } > - > /* even in XAA, 965G needs state mem buffer for rendering */ > if (IS_I965G(pI830) && !pI830->noAccel && pI830->exa_965_state == NULL) { > pI830->exa_965_state = From jbarnes at virtuousgeek.org Mon Dec 3 11:53:05 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 3 Dec 2007 11:53:05 -0800 Subject: G35/33 X3500/3100 HDMI In-Reply-To: References: <4752EB4E.9000002@trypill.org> <47531DD1.80106@trypill.org> Message-ID: <200712031153.05621.jbarnes@virtuousgeek.org> On Sunday, December 02, 2007 3:03 Alan W. Irwin wrote: > On 2007-12-02 22:04+0100 sim0n wrote: > > Thank you very much for your detailed information. > > I guess unless you say that the GMA 3100 basically works now I will > > have to go with a different solution :-(. > > Aside from the one-week outage due to an introduced issue in the > cutting-edge version of the driver, it has been working > well. I run KDE 3.x (i.e., 2D desktop) with no problems, and also > ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here is the > glxgears rating results as given by the offical > http://www.free3d.org/ script Yeah, and that outage was purely my fault. Prior to the 2.2 release, G33 worked fine, but I introduced the regression you found in fixing another bug for 8xx users. So in general, G33 should be in good shape (video, 3D and 2D and mode setting support for SDVO VGA, DVI, and builtin VGA & TV outputs). Jesse From krh at bitplanet.net Mon Dec 3 12:16:22 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 3 Dec 2007 15:16:22 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <47545760.4080404@tungstengraphics.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> Message-ID: <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> On Dec 3, 2007 2:22 PM, Keith Whitwell wrote: Hi Keith, First off: are you talking about MI_SET_CONTEXT as specified in the docs, or are you referring to bugs in the hardware you've come across? > It is necessary to do at least on MI_SET_CONTEXT on driver > initialization, otherwise hardware will hang. Possibly you've only > tested on hardware that has run an older version of the driver once > already, or possibly there is now another component (eg the EXA driver) > emitting these. The patch is against the DDX driver to remove the use of MI_SET_CONTEXT there. As far as I can tell, there is no use of MI_SET_CONTEXT in the DRI driver (except the instruction decoder). So the DRI driver does not emit any, and with the patch above, no part of the system emits MI_SET_CONTEXT. I've tested it on a G33 directly from power-up, and I don't see anything in the docs that imply this is necessary. Also the use of MI_SET_CONTEXT here has the CTXT_NO_RESTORE bit set, which means it doesn't restore anything, it only save the context into a DDX driver private area and it's the only part of the driver that touches the logical_context buffer. Not mesa, nor the drm has access to this buffer and doesn't use MI_SET_CONTEXT anyway. All this code does is to save the state off into a buffer and nothing ever looks at it again. > It is also necessary to do an MI_SET_CONTEXT in case there is a 3d > client out there *really using* MI_SET_CONTEXT. Yes, but for that to work there has to be a MI_SET_CONTEXT somewhere in the system that actually restores the saved state. The patch removes the only MI_SET_CONTEXT use in the entires stack and all it ever did was to save the state. > IE. if I modify the EXA driver to use MI_SET_CONTEXT, and you remove > this code from the 3d driver, you will get unexpected results. This > MI_SET_CONTEXT would cause the other context to be saved -- ie the > hardware only does something on transitions between different hardware > contexts, and it is only with this packet that it knows there is a > context switch... If we want to use MI_SET_CONTEXT from userspace to swap contexts, both the dri and ddx drivers have to be careful to swap in their state (while saving the old state) before changing the state, and they have to do it under the lock to make sure that they don't get scheduled out between restoring their state and manipulating it. Of course, right now, nothing relies on MI_SET_CONTEXT, but both the ddx and dri drivers do full state emission when they detect that they lost the context. I don't think using it from userspace is that interesting though. I'd like to move the MI_SET_CONTEXT use to the drm, so that each batch buffer command is prefixed by a MI_SET_CONTEXT command. The batch buffer is stored as part of the kernel side drm_context_t and userspace needs to specify the context in the super-ioctl. This way, nothing in userspace will need to touch the ring and having the DRM enforce context switches like this prevents state changes ending up in the wrong context. And doing an MI_SET_CONTEXT is free if it's not actually switching to a new context. > In other words, I don't think this is a good idea... But I think it's an excellent idea :) Kristian > Keith > > > Kristian H?gsberg wrote: > > From: Kristian H?gsberg > > > > The driver uses MI_SET_CONTEXT to save the current state before > > emitting the invariant 3d state. Nothing ever restores this state though, > > so this patch removes that. This was also the only remaining use of > > the ring buffer in TTM mode, so we're one step closer to a ring-buffer > > free DDX driver. > > --- > > src/common.h | 2 +- > > src/i830.h | 2 -- > > src/i830_driver.c | 11 ----------- > > src/i830_memory.c | 10 ---------- > > 4 files changed, 1 insertions(+), 24 deletions(-) > > > > diff --git a/src/common.h b/src/common.h > > index f558e8f..46bfa8e 100644 > > --- a/src/common.h > > +++ b/src/common.h > > @@ -232,7 +232,7 @@ union intfloat { > > > > #define BEGIN_LP_RING(n) \ > > RING_LOCALS \ > > - DO_LP_RING(n) \ > > + DO_LP_RING(n) > > > > /* Memory mapped register access macros */ > > #define INREG8(addr) *(volatile CARD8 *)(RecPtr->MMIOBase + (addr)) > > diff --git a/src/i830.h b/src/i830.h > > index 9387651..cbc1b93 100644 > > --- a/src/i830.h > > +++ b/src/i830.h > > @@ -404,8 +404,6 @@ typedef struct _I830Rec { > > void (*PointerMoved)(int, int, int); > > CreateScreenResourcesProcPtr CreateScreenResources; > > > > - i830_memory *logical_context; > > - > > #ifdef XF86DRI > > i830_memory *back_buffer; > > i830_memory *third_buffer; > > diff --git a/src/i830_driver.c b/src/i830_driver.c > > index 6393a61..27df05b 100644 > > --- a/src/i830_driver.c > > +++ b/src/i830_driver.c > > @@ -2254,17 +2254,6 @@ IntelEmitInvarientState(ScrnInfoPtr pScrn) > > if (*pI830->last_3d != LAST_3D_OTHER) > > return; > > > > - ctx_addr = pI830->logical_context->offset; > > - assert((pI830->logical_context->offset & 2047) == 0); > > - { > > - BEGIN_LP_RING(2); > > - OUT_RING(MI_SET_CONTEXT); > > - OUT_RING(pI830->logical_context->offset | > > - CTXT_NO_RESTORE | > > - CTXT_PALETTE_SAVE_DISABLE | CTXT_PALETTE_RESTORE_DISABLE); > > - ADVANCE_LP_RING(); > > - } > > - > > if (!IS_I965G(pI830)) > > { > > if (IS_I9XX(pI830)) > > diff --git a/src/i830_memory.c b/src/i830_memory.c > > index 85b6528..6287bab 100644 > > --- a/src/i830_memory.c > > +++ b/src/i830_memory.c > > @@ -347,7 +347,6 @@ i830_reset_allocations(ScrnInfoPtr pScrn) > > pI830->exa_offscreen = NULL; > > pI830->exa_965_state = NULL; > > pI830->overlay_regs = NULL; > > - pI830->logical_context = NULL; > > #ifdef XF86DRI > > pI830->back_buffer = NULL; > > pI830->third_buffer = NULL; > > @@ -1356,15 +1355,6 @@ i830_allocate_2d_memory(ScrnInfoPtr pScrn) > > pI830->SWCursor = TRUE; > > } > > > > - /* Space for the X Server's 3D context. 32k is fine for right now. */ > > - pI830->logical_context = i830_allocate_memory(pScrn, "logical 3D context", > > - KB(32), GTT_PAGE_SIZE, 0); > > - if (pI830->logical_context == NULL) { > > - xf86DrvMsg(pScrn->scrnIndex, X_WARNING, > > - "Failed to allocate logical context space.\n"); > > - return FALSE; > > - } > > - > > /* even in XAA, 965G needs state mem buffer for rendering */ > > if (IS_I965G(pI830) && !pI830->noAccel && pI830->exa_965_state == NULL) { > > pI830->exa_965_state = > > > From irwin at beluga.phys.uvic.ca Mon Dec 3 12:20:14 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 03 Dec 2007 12:20:14 -0800 (PST) Subject: Request to reconfigure the list with [xorg] in subject line Message-ID: The reason why I ask for [xorg] (or any other appropriate short unique descriptor) in the subject line is it makes it much easier to sort out this list traffic from other lists I am subscribed to. This is a pretty standard convention that most lists use, and I would very much appreciate it if this list was configured to follow that convention as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From arekm at maven.pl Mon Dec 3 12:30:34 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 3 Dec 2007 21:30:34 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: <200712032130.34559.arekm@maven.pl> On Monday 03 of December 2007, Alan W. Irwin wrote: > The reason why I ask for [xorg] (or any other appropriate short unique > descriptor) in the subject line is it makes it much easier to sort out this > list traffic from other lists I am subscribed to. This is a pretty standard > convention that most lists use, and I would very much appreciate it if this > list was configured to follow that convention as well. There is constant header: List-Id: Discuss issues related to the xorg tree Filter by that. > > Alan > __________________________ > Alan W. Irwin -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From krh at bitplanet.net Mon Dec 3 12:37:26 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 3 Dec 2007 15:37:26 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> Message-ID: <59ad55d30712031237o1f707593oa0489a4257c9b62b@mail.gmail.com> On Dec 3, 2007 3:16 PM, Kristian H?gsberg wrote: > On Dec 3, 2007 2:22 PM, Keith Whitwell wrote: ... > > It is also necessary to do an MI_SET_CONTEXT in case there is a 3d > > client out there *really using* MI_SET_CONTEXT. > > Yes, but for that to work there has to be a MI_SET_CONTEXT somewhere > in the system that actually restores the saved state. The patch > removes the only MI_SET_CONTEXT use in the entires stack and all it > ever did was to save the state. Oh, let me just retract that. You're right of course, if a 3d client relied on MI_SET_CONTEXT to restore its state, the 2d driver will have to do this step, even though the 2d driver does use the state-restoring feature on MI_SET_CONTEXT. Having this kind of assumptions spread across the stack is too fragile though, and I think enforcing this in the DRM as I described above is a much better way to go. That's what I'm currently trying to get running here. Kristian From keith at tungstengraphics.com Mon Dec 3 12:37:05 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Mon, 03 Dec 2007 20:37:05 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> Message-ID: <475468F1.9040807@tungstengraphics.com> Kristian H?gsberg wrote: > On Dec 3, 2007 2:22 PM, Keith Whitwell wrote: > > Hi Keith, > > First off: are you talking about MI_SET_CONTEXT as specified in the > docs, or are you referring to bugs in the hardware you've come across? This is just by memory -- which is pretty fallible. But -- it's always been the case that leaving any bit of hardware state uninitialized is asking for trouble, and I'm sure that one of the cases where I've tracked down hangs on startup was attributed to MI_SET_CONTEXT. Things differ from machine to machine, and in this case I believe the driver worked fine with development hardware, but the release version set things up differently somehow, and required this state to be initialized by hand. I guess I'm saying that you should make sure at least that this gets set once to NULL at system startup, no matter what else you do. >> It is necessary to do at least on MI_SET_CONTEXT on driver >> initialization, otherwise hardware will hang. Possibly you've only >> tested on hardware that has run an older version of the driver once >> already, or possibly there is now another component (eg the EXA driver) >> emitting these. > > The patch is against the DDX driver to remove the use of > MI_SET_CONTEXT there. As far as I can tell, there is no use of > MI_SET_CONTEXT in the DRI driver (except the instruction decoder). Yes, but this may change. Keith's indicated he's interested in it, and now that we have ttm, the possibility is there for this instruction to be of some use. > So > the DRI driver does not emit any, and with the patch above, no part of > the system emits MI_SET_CONTEXT. I've tested it on a G33 directly > from power-up, and I don't see anything in the docs that imply this is > necessary. Also the use of MI_SET_CONTEXT here has the > CTXT_NO_RESTORE bit set, which means it doesn't restore anything, it > only save the context into a DDX driver private area and it's the only > part of the driver that touches the logical_context buffer. Not mesa, > nor the drm has access to this buffer and doesn't use MI_SET_CONTEXT > anyway. All this code does is to save the state off into a buffer and > nothing ever looks at it again. > >> It is also necessary to do an MI_SET_CONTEXT in case there is a 3d >> client out there *really using* MI_SET_CONTEXT. > > Yes, but for that to work there has to be a MI_SET_CONTEXT somewhere > in the system that actually restores the saved state. The patch > removes the only MI_SET_CONTEXT use in the entires stack and all it > ever did was to save the state. OK. >> IE. if I modify the EXA driver to use MI_SET_CONTEXT, and you remove >> this code from the 3d driver, you will get unexpected results. This >> MI_SET_CONTEXT would cause the other context to be saved -- ie the >> hardware only does something on transitions between different hardware >> contexts, and it is only with this packet that it knows there is a >> context switch... > > If we want to use MI_SET_CONTEXT from userspace to swap contexts, both > the dri and ddx drivers have to be careful to swap in their state > (while saving the old state) before changing the state, and they have > to do it under the lock to make sure that they don't get scheduled out > between restoring their state and manipulating it. Of course, right > now, nothing relies on MI_SET_CONTEXT, but both the ddx and dri > drivers do full state emission when they detect that they lost the > context. I think there's a misunderstanding here -- why would they need the lock? Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. Nothing can interrupt a batchbuffer half-way through in our system. > > I don't think using it from userspace is that interesting though. I'd > like to move the MI_SET_CONTEXT use to the drm, so that each batch > buffer command is prefixed by a MI_SET_CONTEXT command. The batch > buffer is stored as part of the kernel side drm_context_t and > userspace needs to specify the context in the super-ioctl. This way, > nothing in userspace will need to touch the ring and having the DRM > enforce context switches like this prevents state changes ending up in > the wrong context. And doing an MI_SET_CONTEXT is free if it's not > actually switching to a new context. Why not just have the userspace do this? IE, userspace allocates a page-sized buffer to hold the context and always emits MI_SET_CONTEXT and a relocation itself. I don't see why the kernel needs to have anything to do with it - there's nothing special about this operation that I can see requiring kernel supervision, and no need to use the lock. >> In other words, I don't think this is a good idea... > > But I think it's an excellent idea :) As long as you run the packet once, somewhere, I don't mind. But humor me and at least do it one time with NULL parameters at startup. Keith From alan at lxorguk.ukuu.org.uk Mon Dec 3 12:52:27 2007 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Mon, 3 Dec 2007 20:52:27 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: <20071203205227.3f70957c@the-village.bc.nu> On Mon, 03 Dec 2007 12:20:14 -0800 (PST) "Alan W. Irwin" wrote: > The reason why I ask for [xorg] (or any other appropriate short unique > descriptor) in the subject line is it makes it much easier to sort out this > list traffic from other lists I am subscribed to. This is a pretty standard > convention that most lists use, and I would very much appreciate it if this > list was configured to follow that convention as well. All mail from the list has a consistent To: xorg at lists.freedesktop.org X-BeenThere: xorg at lists.freedesktop.org So you can sort on either of those instead of cluttering up the subject lines. From irwin at beluga.phys.uvic.ca Mon Dec 3 12:59:50 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 03 Dec 2007 12:59:50 -0800 (PST) Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <200712032130.34559.arekm@maven.pl> References: <200712032130.34559.arekm@maven.pl> Message-ID: On 2007-12-03 21:30+0100 Arkadiusz Miskiewicz wrote: > On Monday 03 of December 2007, Alan W. Irwin wrote: >> The reason why I ask for [xorg] (or any other appropriate short unique >> descriptor) in the subject line is it makes it much easier to sort out this >> list traffic from other lists I am subscribed to. This is a pretty standard >> convention that most lists use, and I would very much appreciate it if this >> list was configured to follow that convention as well. > > There is constant header: > > List-Id: Discuss issues related to the xorg tree > > Filter by that. That works for automatic filtering, but is not nearly as convenient for filtering by humans as a simple descriptor in the subject line. I assume that is why most lists have such a subject-line descriptor enabled. So I renew my request that this list conform to that convention. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From jra at baylink.com Mon Dec 3 13:06:00 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 3 Dec 2007 16:06:00 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> Message-ID: <20071203210600.GE25785@cgi.jachomes.com> On Mon, Dec 03, 2007 at 12:59:50PM -0800, Alan W. Irwin wrote: > On 2007-12-03 21:30+0100 Arkadiusz Miskiewicz wrote: > > On Monday 03 of December 2007, Alan W. Irwin wrote: > >> The reason why I ask for [xorg] (or any other appropriate short unique > >> descriptor) in the subject line is it makes it much easier to sort out this > >> list traffic from other lists I am subscribed to. This is a pretty standard > >> convention that most lists use, and I would very much appreciate it if this > >> list was configured to follow that convention as well. > > > > There is constant header: > > > > List-Id: Discuss issues related to the xorg tree > > Filter by that. > > That works for automatic filtering, but is not nearly as convenient for > filtering by humans as a simple descriptor in the subject line. I assume > that is why most lists have such a subject-line descriptor enabled. So I > renew my request that this list conform to that convention. I doubt you'll win, though I can see both sides. procmail can be convinced to do what you want. Most lists have such tags because they're for civilians, who can't be assumed to have reasonable MUA processing available to them. So in a perverse sort of way, it's a compliment. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From krh at bitplanet.net Mon Dec 3 13:07:24 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 3 Dec 2007 16:07:24 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <475468F1.9040807@tungstengraphics.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> Message-ID: <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> On Dec 3, 2007 3:37 PM, Keith Whitwell wrote: > Kristian H?gsberg wrote: > > On Dec 3, 2007 2:22 PM, Keith Whitwell wrote: > > > > Hi Keith, > > > > First off: are you talking about MI_SET_CONTEXT as specified in the > > docs, or are you referring to bugs in the hardware you've come across? > > This is just by memory -- which is pretty fallible. > > But -- it's always been the case that leaving any bit of hardware state > uninitialized is asking for trouble, and I'm sure that one of the cases > where I've tracked down hangs on startup was attributed to MI_SET_CONTEXT. > > Things differ from machine to machine, and in this case I believe the > driver worked fine with development hardware, but the release version > set things up differently somehow, and required this state to be > initialized by hand. > > I guess I'm saying that you should make sure at least that this gets set > once to NULL at system startup, no matter what else you do. > > > >> It is necessary to do at least on MI_SET_CONTEXT on driver > >> initialization, otherwise hardware will hang. Possibly you've only > >> tested on hardware that has run an older version of the driver once > >> already, or possibly there is now another component (eg the EXA driver) > >> emitting these. > > > > The patch is against the DDX driver to remove the use of > > MI_SET_CONTEXT there. As far as I can tell, there is no use of > > MI_SET_CONTEXT in the DRI driver (except the instruction decoder). > > Yes, but this may change. Keith's indicated he's interested in it, and > now that we have ttm, the possibility is there for this instruction to > be of some use. > > > So > > the DRI driver does not emit any, and with the patch above, no part of > > the system emits MI_SET_CONTEXT. I've tested it on a G33 directly > > from power-up, and I don't see anything in the docs that imply this is > > necessary. Also the use of MI_SET_CONTEXT here has the > > CTXT_NO_RESTORE bit set, which means it doesn't restore anything, it > > only save the context into a DDX driver private area and it's the only > > part of the driver that touches the logical_context buffer. Not mesa, > > nor the drm has access to this buffer and doesn't use MI_SET_CONTEXT > > anyway. All this code does is to save the state off into a buffer and > > nothing ever looks at it again. > > > >> It is also necessary to do an MI_SET_CONTEXT in case there is a 3d > >> client out there *really using* MI_SET_CONTEXT. > > > > Yes, but for that to work there has to be a MI_SET_CONTEXT somewhere > > in the system that actually restores the saved state. The patch > > removes the only MI_SET_CONTEXT use in the entires stack and all it > > ever did was to save the state. > > OK. > > > >> IE. if I modify the EXA driver to use MI_SET_CONTEXT, and you remove > >> this code from the 3d driver, you will get unexpected results. This > >> MI_SET_CONTEXT would cause the other context to be saved -- ie the > >> hardware only does something on transitions between different hardware > >> contexts, and it is only with this packet that it knows there is a > >> context switch... > > > > If we want to use MI_SET_CONTEXT from userspace to swap contexts, both > > the dri and ddx drivers have to be careful to swap in their state > > (while saving the old state) before changing the state, and they have > > to do it under the lock to make sure that they don't get scheduled out > > between restoring their state and manipulating it. Of course, right > > now, nothing relies on MI_SET_CONTEXT, but both the ddx and dri > > drivers do full state emission when they detect that they lost the > > context. > > I think there's a misunderstanding here -- why would they need the lock? > > Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. > Nothing can interrupt a batchbuffer half-way through in our system. MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch buffer. I've only just started to read the docs, but there seem to be a distinction in the instruction set design that priviledged instructions has to go in a ring buffer, but regular rendering can go either place. Thus, if you restrict access to the ring buffer and require clients to submit batch buffers, you have a fair shot at implementing a sandboxed environment where clients can't mess up other clients state (ie with instructions such as MI_SET_CONTEXT). So the lock is needed to access the ring buffer in this case, even if you just submit a MI_SET_CONTEXT followed by a MI_START_BATCH_BUFFER. > > I don't think using it from userspace is that interesting though. I'd > > like to move the MI_SET_CONTEXT use to the drm, so that each batch > > buffer command is prefixed by a MI_SET_CONTEXT command. The batch > > buffer is stored as part of the kernel side drm_context_t and > > userspace needs to specify the context in the super-ioctl. This way, > > nothing in userspace will need to touch the ring and having the DRM > > enforce context switches like this prevents state changes ending up in > > the wrong context. And doing an MI_SET_CONTEXT is free if it's not > > actually switching to a new context. > > Why not just have the userspace do this? IE, userspace allocates a > page-sized buffer to hold the context and always emits MI_SET_CONTEXT > and a relocation itself. > > I don't see why the kernel needs to have anything to do with it - > there's nothing special about this operation that I can see requiring > kernel supervision, and no need to use the lock. As discussed above, to avoid user space ring buffer access and with it, user space locking. I agree that if we could use MI_SET_CONTEXT from a batch buffer, there would be no need for this, when you think about it, it makes sense that it's restricted to ring buffer usage, and it won't incur a lot of overhead/complexity in the kernel. > >> In other words, I don't think this is a good idea... > > > > But I think it's an excellent idea :) > > As long as you run the packet once, somewhere, I don't mind. But humor > me and at least do it one time with NULL parameters at startup. Yup, definitely. The docs detail the startup sequence, and explicity states that the first time a new context is used, MI_SET_CONTEXT has to be invoked with the NO_RESTORE flag to avoid restoring from uninitialized memory. When the context is later swapped out, its current state is written to the memory allocated to back it, at which point is it fully initialized and can be restored from. Kristian From cloos+pdx-xorg at jhcloos.com Mon Dec 3 13:14:41 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Mon, 03 Dec 2007 16:14:41 -0500 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <1196702555.16394.8.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Mon, 03 Dec 2007 18:22:35 +0100") References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> Message-ID: >>>>> "Nicolas" == Nicolas Mailhot writes: Nicolas> kbd and mouse are mostly not needed and trying to support them Nicolas> in addition to evdev is a large part of the current mess. Mouse will continue to be needed even on evdev platforms until evdev has support for emulating button 2 (thinkpad users are not the only laptop users who want to do middle-button pasting) and probably support for emulating a wheel as well (based on comments in a recent post). Kbd may be mostly not needed, but we aren?t close to mostly for mouse. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From libv at skynet.be Mon Dec 3 13:19:33 2007 From: libv at skynet.be (Luc Verhaegen) Date: Mon, 3 Dec 2007 22:19:33 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203210600.GE25785@cgi.jachomes.com> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> Message-ID: <20071203211933.GA26078@skynet.be> On Mon, Dec 03, 2007 at 04:06:00PM -0500, Jay R. Ashworth wrote: > On Mon, Dec 03, 2007 at 12:59:50PM -0800, Alan W. Irwin wrote: > > On 2007-12-03 21:30+0100 Arkadiusz Miskiewicz wrote: > > > > > > There is constant header: > > > > > > List-Id: Discuss issues related to the xorg tree > > > Filter by that. > > > > That works for automatic filtering, but is not nearly as convenient for > > filtering by humans as a simple descriptor in the subject line. I assume > > that is why most lists have such a subject-line descriptor enabled. So I > > renew my request that this list conform to that convention. > > I doubt you'll win, though I can see both sides. > > procmail can be convinced to do what you want. > > Most lists have such tags because they're for civilians, who can't be > assumed to have reasonable MUA processing available to them. So in a > perverse sort of way, it's a compliment. > > Cheers, > -- jra Ah... I just missed most of this thread because my manual processing is not good enough. I would very much prefer [xorg] in front of everything. This would make me personally, with my inbox == TODO list kind of mail handling, much happier. Although i do tend to be quite good at author/subject based sorting, i've had quite a bit of practice, it is not perfect, and in this case the xorg bit fell off the end of my console. The most important reason is this: this change would mean that Xorg would become slightly less chauvinistic. Most projects i track do have [] in front, the only exceptions being lkml and some x related lists. Maybe it would be good if we stepped off our pedestal and acted like a normal open source project. Luc Verhaegen. SUSE/Novell X Driver Developer. From keith at tungstengraphics.com Mon Dec 3 13:20:39 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Mon, 03 Dec 2007 21:20:39 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> Message-ID: <47547327.7030605@tungstengraphics.com> Kristian H?gsberg wrote: > On Dec 3, 2007 3:37 PM, Keith Whitwell wrote: >> Kristian H?gsberg wrote: >>> On Dec 3, 2007 2:22 PM, Keith Whitwell wrote: >>> >>> Hi Keith, >>> >>> First off: are you talking about MI_SET_CONTEXT as specified in the >>> docs, or are you referring to bugs in the hardware you've come across? >> This is just by memory -- which is pretty fallible. >> >> But -- it's always been the case that leaving any bit of hardware state >> uninitialized is asking for trouble, and I'm sure that one of the cases >> where I've tracked down hangs on startup was attributed to MI_SET_CONTEXT. >> >> Things differ from machine to machine, and in this case I believe the >> driver worked fine with development hardware, but the release version >> set things up differently somehow, and required this state to be >> initialized by hand. >> >> I guess I'm saying that you should make sure at least that this gets set >> once to NULL at system startup, no matter what else you do. >> >> >>>> It is necessary to do at least on MI_SET_CONTEXT on driver >>>> initialization, otherwise hardware will hang. Possibly you've only >>>> tested on hardware that has run an older version of the driver once >>>> already, or possibly there is now another component (eg the EXA driver) >>>> emitting these. >>> The patch is against the DDX driver to remove the use of >>> MI_SET_CONTEXT there. As far as I can tell, there is no use of >>> MI_SET_CONTEXT in the DRI driver (except the instruction decoder). >> Yes, but this may change. Keith's indicated he's interested in it, and >> now that we have ttm, the possibility is there for this instruction to >> be of some use. >> >>> So >>> the DRI driver does not emit any, and with the patch above, no part of >>> the system emits MI_SET_CONTEXT. I've tested it on a G33 directly >>> from power-up, and I don't see anything in the docs that imply this is >>> necessary. Also the use of MI_SET_CONTEXT here has the >>> CTXT_NO_RESTORE bit set, which means it doesn't restore anything, it >>> only save the context into a DDX driver private area and it's the only >>> part of the driver that touches the logical_context buffer. Not mesa, >>> nor the drm has access to this buffer and doesn't use MI_SET_CONTEXT >>> anyway. All this code does is to save the state off into a buffer and >>> nothing ever looks at it again. >>> >>>> It is also necessary to do an MI_SET_CONTEXT in case there is a 3d >>>> client out there *really using* MI_SET_CONTEXT. >>> Yes, but for that to work there has to be a MI_SET_CONTEXT somewhere >>> in the system that actually restores the saved state. The patch >>> removes the only MI_SET_CONTEXT use in the entires stack and all it >>> ever did was to save the state. >> OK. >> >> >>>> IE. if I modify the EXA driver to use MI_SET_CONTEXT, and you remove >>>> this code from the 3d driver, you will get unexpected results. This >>>> MI_SET_CONTEXT would cause the other context to be saved -- ie the >>>> hardware only does something on transitions between different hardware >>>> contexts, and it is only with this packet that it knows there is a >>>> context switch... >>> If we want to use MI_SET_CONTEXT from userspace to swap contexts, both >>> the dri and ddx drivers have to be careful to swap in their state >>> (while saving the old state) before changing the state, and they have >>> to do it under the lock to make sure that they don't get scheduled out >>> between restoring their state and manipulating it. Of course, right >>> now, nothing relies on MI_SET_CONTEXT, but both the ddx and dri >>> drivers do full state emission when they detect that they lost the >>> context. >> I think there's a misunderstanding here -- why would they need the lock? >> >> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. >> Nothing can interrupt a batchbuffer half-way through in our system. > > MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch > buffer. I had trouble understanding this -- but indeed the address for the context is a *physical* address in system memory... Fabulous. That makes the whole scheme less interesting to me as it does rely on the kernel doing the state management, and at this point I don't really see this as being hugely worthwhile. Before you do this, it would be worthwhile to disable the preamble emit from the i915 driver and see if there is any measurable benefit. As long as you only run a single context and disable EXA, nothing bad should happen. Keith > I've only just started to read the docs, but there seem to be > a distinction in the instruction set design that priviledged > instructions has to go in a ring buffer, but regular rendering can go > either place. Thus, if you restrict access to the ring buffer and > require clients to submit batch buffers, you have a fair shot at > implementing a sandboxed environment where clients can't mess up other > clients state (ie with instructions such as MI_SET_CONTEXT). > > So the lock is needed to access the ring buffer in this case, even if > you just submit a MI_SET_CONTEXT followed by a MI_START_BATCH_BUFFER. > >>> I don't think using it from userspace is that interesting though. I'd >>> like to move the MI_SET_CONTEXT use to the drm, so that each batch >>> buffer command is prefixed by a MI_SET_CONTEXT command. The batch >>> buffer is stored as part of the kernel side drm_context_t and >>> userspace needs to specify the context in the super-ioctl. This way, >>> nothing in userspace will need to touch the ring and having the DRM >>> enforce context switches like this prevents state changes ending up in >>> the wrong context. And doing an MI_SET_CONTEXT is free if it's not >>> actually switching to a new context. >> Why not just have the userspace do this? IE, userspace allocates a >> page-sized buffer to hold the context and always emits MI_SET_CONTEXT >> and a relocation itself. >> >> I don't see why the kernel needs to have anything to do with it - >> there's nothing special about this operation that I can see requiring >> kernel supervision, and no need to use the lock. > > As discussed above, to avoid user space ring buffer access and with > it, user space locking. I agree that if we could use MI_SET_CONTEXT > from a batch buffer, there would be no need for this, when you think > about it, it makes sense that it's restricted to ring buffer usage, > and it won't incur a lot of overhead/complexity in the kernel. > >>>> In other words, I don't think this is a good idea... >>> But I think it's an excellent idea :) >> As long as you run the packet once, somewhere, I don't mind. But humor >> me and at least do it one time with NULL parameters at startup. > > Yup, definitely. The docs detail the startup sequence, and explicity > states that the first time a new context is used, MI_SET_CONTEXT has > to be invoked with the NO_RESTORE flag to avoid restoring from > uninitialized memory. When the context is later swapped out, its > current state is written to the memory allocated to back it, at which > point is it fully initialized and can be restored from. > > Kristian From sim0n at trypill.org Mon Dec 3 13:25:04 2007 From: sim0n at trypill.org (sim0n) Date: Mon, 03 Dec 2007 22:25:04 +0100 Subject: G35/33 X3500/3100 HDMI In-Reply-To: <200712031153.05621.jbarnes@virtuousgeek.org> References: <4752EB4E.9000002@trypill.org> <47531DD1.80106@trypill.org> <200712031153.05621.jbarnes@virtuousgeek.org> Message-ID: <47547430.7050909@trypill.org> Jesse Barnes wrote: > On Sunday, December 02, 2007 3:03 Alan W. Irwin wrote: >> On 2007-12-02 22:04+0100 sim0n wrote: >>> Thank you very much for your detailed information. >>> I guess unless you say that the GMA 3100 basically works now I will >>> have to go with a different solution :-(. >> Aside from the one-week outage due to an introduced issue in the >> cutting-edge version of the driver, it has been working >> well. I run KDE 3.x (i.e., 2D desktop) with no problems, and also >> ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here is the >> glxgears rating results as given by the offical >> http://www.free3d.org/ script > > Yeah, and that outage was purely my fault. Prior to the 2.2 release, > G33 worked fine, but I introduced the regression you found in fixing > another bug for 8xx users. > > So in general, G33 should be in good shape (video, 3D and 2D and mode > setting support for SDVO VGA, DVI, and builtin VGA & TV outputs). Sounds good, thnx. Any idea about mpeg2 acceleration support ? (There is hardware support for that, according to wikipedia) -- regards, sim0n From jbarnes at virtuousgeek.org Mon Dec 3 13:31:45 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 3 Dec 2007 13:31:45 -0800 Subject: G35/33 X3500/3100 HDMI In-Reply-To: <47547430.7050909@trypill.org> References: <4752EB4E.9000002@trypill.org> <200712031153.05621.jbarnes@virtuousgeek.org> <47547430.7050909@trypill.org> Message-ID: <200712031331.46600.jbarnes@virtuousgeek.org> On Monday, December 03, 2007 1:25 sim0n wrote: > Jesse Barnes wrote: > > On Sunday, December 02, 2007 3:03 Alan W. Irwin wrote: > >> On 2007-12-02 22:04+0100 sim0n wrote: > >>> Thank you very much for your detailed information. > >>> I guess unless you say that the GMA 3100 basically works now I > >>> will have to go with a different solution :-(. > >> > >> Aside from the one-week outage due to an introduced issue in the > >> cutting-edge version of the driver, it has been working > >> well. I run KDE 3.x (i.e., 2D desktop) with no problems, and > >> also ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here > >> is the glxgears rating results as given by the offical > >> http://www.free3d.org/ script > > > > Yeah, and that outage was purely my fault. Prior to the 2.2 > > release, G33 worked fine, but I introduced the regression you > > found in fixing another bug for 8xx users. > > > > So in general, G33 should be in good shape (video, 3D and 2D and > > mode setting support for SDVO VGA, DVI, and builtin VGA & TV > > outputs). > > Sounds good, thnx. > > Any idea about mpeg2 acceleration support ? > (There is hardware support for that, according to wikipedia) There's Xv support but XvMC is still a work in progress. Zhenyu's been working on the video stuff, he can probably provide a more detailed summary of the state of video accel support in the intel driver. From bart at cs.pdx.edu Mon Dec 3 13:37:12 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Mon, 03 Dec 2007 13:37:12 -0800 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: Message of "Mon, 03 Dec 2007 22:19:33 +0100." <20071203211933.GA26078@skynet.be> References: <20071203211933.GA26078@skynet.be> <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> Message-ID: <200712032137.lB3LbC1l004416@wezen.cs.pdx.edu> I doubt anyone will get to this issue (subject line [xorg]) until we're done running the Foundation Board election, which is taking most of the Board's bandwidth right now. Once that's done, I plan to propose some fairly serious changes to the email lists; we can fold this issue in with the others that will be addressed in that discussion. My offhand inclination is that "of course we should tag the subject", but there may be some reason I haven't thought of why it's a bad idea... Bart Massey bart at cs.pdx.edu From alan at lxorguk.ukuu.org.uk Mon Dec 3 13:35:05 2007 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Mon, 3 Dec 2007 21:35:05 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> Message-ID: <20071203213505.0a6b9eae@the-village.bc.nu> > That works for automatic filtering, but is not nearly as convenient for > filtering by humans as a simple descriptor in the subject line. I assume > that is why most lists have such a subject-line descriptor enabled. So I > renew my request that this list conform to that convention. Some of us humans also prefer not to have [thingsialreadyknow] taking up chunks of subject line hiding the real subject. You can use procmail to achieve what you want without messing it up for the rest of us From libv at skynet.be Mon Dec 3 13:43:13 2007 From: libv at skynet.be (Luc Verhaegen) Date: Mon, 3 Dec 2007 22:43:13 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203213505.0a6b9eae@the-village.bc.nu> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> Message-ID: <20071203214313.GA26326@skynet.be> On Mon, Dec 03, 2007 at 09:35:05PM +0000, Alan Cox wrote: > > That works for automatic filtering, but is not nearly as convenient for > > filtering by humans as a simple descriptor in the subject line. I assume > > that is why most lists have such a subject-line descriptor enabled. So I > > renew my request that this list conform to that convention. > > Some of us humans also prefer not to have [thingsialreadyknow] taking up > chunks of subject line hiding the real subject. > > You can use procmail to achieve what you want without messing it up for > the rest of us "[xorg] " is a full seven characters. Luc Verhaegen. SUSE/Novell X Driver Developer. From krh at bitplanet.net Mon Dec 3 13:43:03 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 3 Dec 2007 16:43:03 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <47547327.7030605@tungstengraphics.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> <47547327.7030605@tungstengraphics.com> Message-ID: <59ad55d30712031343y7adf072ah3c1bffe3b7258dd5@mail.gmail.com> On Dec 3, 2007 4:20 PM, Keith Whitwell wrote: ... > >> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. > >> Nothing can interrupt a batchbuffer half-way through in our system. > > > > MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch > > buffer. > > I had trouble understanding this -- but indeed the address for the > context is a *physical* address in system memory... Fabulous. No, it can be a GTT offset too, but it has to present when the context is swapped out. That is not under our control, because it happens when the next context is swapped in. So it has to be a no-evict buffer. We don't want to fragment the GTT with no-evict buffers for this stuff, so the physical address option looks more interesting. > That makes the whole scheme less interesting to me as it does rely on > the kernel doing the state management, and at this point I don't really > see this as being hugely worthwhile. What did you have in mind? The context buffers are opaque, it's just a cookie you hold on to for the hardware. You can't peek into them and manipulate the state anyway, so it doesn't seem to me that there's a big difference in whether the kernel or user space track the state buffers and issue the MI_SET_CONTEXT. > Before you do this, it would be worthwhile to disable the preamble emit > from the i915 driver and see if there is any measurable benefit. As > long as you only run a single context and disable EXA, nothing bad > should happen. I'll give that a try, and the thing to compare against is state emission on every batch buffer, which is what we'll be doing without the DRI lock. No matter how it turns out, I doubt it will be a performance regression, and will help with the EXA state tracking too. Kristian From dkasak at nusconsulting.com.au Mon Dec 3 13:50:05 2007 From: dkasak at nusconsulting.com.au (Daniel Kasak) Date: Tue, 04 Dec 2007 08:50:05 +1100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203211933.GA26078@skynet.be> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> Message-ID: <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> On Mon, 2007-12-03 at 22:19 +0100, Luc Verhaegen wrote: > The most important reason is this: this change would mean that Xorg > would become slightly less chauvinistic. Most projects i track do have > [] in front, the only exceptions being lkml and some x related lists. > Maybe it would be good if we stepped off our pedestal and acted like a > normal open source project. WTF? The only pedestal I see is the other way around, ie people who demand redundant text be placed in the subject of every message, just so *they* can then refuse to use filtering software that's now in every practically every email client ( and some IMAP servers ). I am honestly gobsmacked that some people insist on subscribing to mailing lists AND performing manual filtering. Anyway, let's spare a thought for people who can't afford brand new 22i LCD widescreen monitors, and would prefer to have the subject, just the subject, and nothing but the subject, in the 'subject' field. As for the bit about acting like normal open-source projects, I'm subscribed to 33 mailing lists, covering 24 projects, and the ONLY mailing lists that put the name of the mailing list in the subject field are the OpenOffice mailing lists, and they screw it up anyway ( they don't put the full name, but a single word such as 'users', 'discuss' ). -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: dkasak at nusconsulting.com.au website: http://www.nusconsulting.com.au From mjg59 at srcf.ucam.org Mon Dec 3 13:31:20 2007 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Mon, 3 Dec 2007 21:31:20 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> Message-ID: <20071203213120.GA7191@srcf.ucam.org> On Mon, Dec 03, 2007 at 12:59:50PM -0800, Alan W. Irwin wrote: > That works for automatic filtering, but is not nearly as convenient for > filtering by humans as a simple descriptor in the subject line. I assume > that is why most lists have such a subject-line descriptor enabled. So I > renew my request that this list conform to that convention. It tends to end up in some sort of indescribable mess whenever there's crossposting between two lists with this convention. -- Matthew Garrett | mjg59 at srcf.ucam.org From jcristau at debian.org Mon Dec 3 14:04:37 2007 From: jcristau at debian.org (Julien Cristau) Date: Mon, 3 Dec 2007 23:04:37 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203214313.GA26326@skynet.be> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071203214313.GA26326@skynet.be> Message-ID: <20071203220433.GC24032@patate.is-a-geek.org> On Mon, Dec 3, 2007 at 22:43:13 +0100, Luc Verhaegen wrote: > "[xorg] " is a full seven characters. > And when I'm reading =fdo/xorg, seven characters out of 80 filled with useless stuff I already know is a lot. Cheers, Julien From eikke at eikke.com Mon Dec 3 13:47:56 2007 From: eikke at eikke.com (Nicolas Trangez) Date: Mon, 03 Dec 2007 22:47:56 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> Message-ID: <1196718476.13688.118.camel@dyn-145116034060> On Tue, 2007-12-04 at 08:50 +1100, Daniel Kasak wrote: > I am honestly > gobsmacked that some people insist on subscribing to mailing lists AND > performing manual filtering. Actually, I'm subscribed to quite some lists, but really dislike to have mail folders (real or virtual, whatever), I like to have everything in one big inbox, no filtering whatsoever. Having a prefix on mailing list messages is pretty useful then. Anyway, guess that's just me. Nicolas -------------- 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 rayvd at bludgeon.org Mon Dec 3 14:08:17 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 3 Dec 2007 14:08:17 -0800 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <1196718476.13688.118.camel@dyn-145116034060> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> <1196718476.13688.118.camel@dyn-145116034060> Message-ID: <20071203220817.GA4898@bludgeon.org> On Mon, Dec 03, 2007 at 10:47:56PM +0100, Nicolas Trangez wrote: > On Tue, 2007-12-04 at 08:50 +1100, Daniel Kasak wrote: > > I am honestly > > gobsmacked that some people insist on subscribing to mailing lists AND > > performing manual filtering. > > Actually, I'm subscribed to quite some lists, but really dislike to have > mail folders (real or virtual, whatever), I like to have everything in > one big inbox, no filtering whatsoever. Having a prefix on mailing list > messages is pretty useful then. > > Anyway, guess that's just me. Since we're all sharing, I don't mind either way. I kinda like the brackets as well, but I also don't run my mutt in an 80 column wide xterm either. :) Either way, they're not going to change the config for this list, so use procmail or your MUA to rewrite the subject if you like. Pretty trivial :) Ray From dant at cdkkt.com Mon Dec 3 14:10:46 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 3 Dec 2007 14:10:46 -0800 Subject: xorg.conf for GD5480 Message-ID: <021126B987E43D44A860139823C079110E2BCF@orion.cdkkt.com> Hello, This is my first email message to this group, so please bear with me or direct me to where I need to go to report this "bug". My Hardware: ========== PC: VA Linux System, 600Mhz PIII RAM: 396MB Video: Cirrus GD5480 OS: Fedora releases 6/7/8. GDM was able to locate the cirrus chipset and xorg.conf shows: ==================================== Section "Device" Identifier "Screen0" Driver "cirrus" EndSection Section "Screen0" Device "Videocard0" DefaultDepth 24 EndSection ==================================== The problem here, is that the DefaultDepth is too high for cirrus chipsets that cannot support color depths higher than it is capable of, so GDM will fail to find a working screen resolution it can support. The following shows what had to be done to get the GDM working and I have found that even with the DefaultDepth set to 16, it is not sufficient to ignore the Modes as it must specify supported screen resolutions to ensure a successful GDM startup. #==================================== Section "Screen0" Device "Videocard0" DefaultDepth 16 SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" "640x480 EndSubSection EndSection #==================================== Thanks! No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.13/1165 - Release Date: 12/2/2007 8:34 PM From igor at hybrid-lab.co.uk Mon Dec 3 14:18:38 2007 From: igor at hybrid-lab.co.uk (Igor Mozolevsky) Date: Mon, 3 Dec 2007 22:18:38 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: On 03/12/2007, Alan W. Irwin wrote: > The reason why I ask for [xorg] (or any other appropriate short unique > descriptor) in the subject line is it makes it much easier to sort out this > list traffic from other lists I am subscribed to. This is a pretty standard > convention that most lists use, and I would very much appreciate it if this > list was configured to follow that convention as well. isn't there something in the RFCs about mangling headers?.. my 2c, Igor :-) From joerg at britannica.bec.de Mon Dec 3 14:27:49 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon, 3 Dec 2007 23:27:49 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: <20071203222749.GA17150@britannica.bec.de> On Mon, Dec 03, 2007 at 10:18:38PM +0000, Igor Mozolevsky wrote: > On 03/12/2007, Alan W. Irwin wrote: > > The reason why I ask for [xorg] (or any other appropriate short unique > > descriptor) in the subject line is it makes it much easier to sort out this > > list traffic from other lists I am subscribed to. This is a pretty standard > > convention that most lists use, and I would very much appreciate it if this > > list was configured to follow that convention as well. > > isn't there something in the RFCs about mangling headers?.. It breaks RE: processing, for example. Joerg From irwin at beluga.phys.uvic.ca Mon Dec 3 14:35:02 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 03 Dec 2007 14:35:02 -0800 (PST) Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203213505.0a6b9eae@the-village.bc.nu> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> Message-ID: On 2007-12-03 21:35-0000 Alan Cox wrote: >> That works for automatic filtering, but is not nearly as convenient for >> filtering by humans as a simple descriptor in the subject line. I assume >> that is why most lists have such a subject-line descriptor enabled. So I >> renew my request that this list conform to that convention. > > Some of us humans also prefer not to have [thingsialreadyknow] taking up > chunks of subject line hiding the real subject. > > You can use procmail to achieve what you want without messing it up for > the rest of us Thanks for that good idea. At first I thought you were referring to automatic filtering of this list into a separate e-mail folder (which I don't want), but now I realize you were suggesting a procmail rule just for subject-line tweaking. That works for me. So that is the end of this thread except for one off-topic remark. Alan, you have been my hero for a decade now due to your kernel work so I wanted to take this opportunity to thank you for that work. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bryce at bryceharrington.org Mon Dec 3 14:38:34 2007 From: bryce at bryceharrington.org (Bryce Harrington) Date: Mon, 3 Dec 2007 14:38:34 -0800 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203220817.GA4898@bludgeon.org> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> <1196718476.13688.118.camel@dyn-145116034060> <20071203220817.GA4898@bludgeon.org> Message-ID: <20071203223834.GI16823@bryceharrington.org> On Mon, Dec 03, 2007 at 02:08:17PM -0800, Ray Van Dolson wrote: > use procmail or your MUA to rewrite the subject if you like. Pretty > trivial :) Note that if people start doing this, we'll start seeing reply emails with "[xorg] Re: ..." in them. And if we're particularly unlucky, maybe "Re: [xorg] Re [X.org] RE: [xorg-devel] ..." If the official recommendation is "just use procmail to rewrite the subject line", then it would be wise to also point to an official procmail rule to use, designed to be easily cleaned up for those who *don't* want them. Bryce From mrmazda at ij.net Mon Dec 3 14:47:26 2007 From: mrmazda at ij.net (Felix Miata) Date: Mon, 03 Dec 2007 17:47:26 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203213120.GA7191@srcf.ucam.org> References: <200712032130.34559.arekm@maven.pl> <20071203213120.GA7191@srcf.ucam.org> Message-ID: <4754877E.3070503@ij.net> On 2007/12/03 16:31 (GMT-0500) Matthew Garrett apparently typed: > Alan W. Irwin wrote: ... >> This is a pretty standard convention that most lists use, and I would >> very much appreciate it if this list was configured to follow that >> convention as well. ... > It tends to end up in some sort of indescribable mess whenever there's > crossposting between two lists with this convention. As so few lists fail to prohibit crossposting, there's really no excuse for that to happen. Before sending each sender can, and should, remove any that don't belong. I'm on around 40 mailing lists, most of which have a [something] identifier, of which most are more than 7 characters. The 7 characters represented by an [xorg] appended is a pittance much preferred to the disadvantages of its absence. -- " Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other." John Adams Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From behdad at behdad.org Mon Dec 3 14:53:17 2007 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 03 Dec 2007 17:53:17 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: <1196722397.29088.26.camel@behdad.behdad.org> On Mon, 2007-12-03 at 12:20 -0800, Alan W. Irwin wrote: > The reason why I ask for [xorg] (or any other appropriate short unique > descriptor) in the subject line is it makes it much easier to sort out > this > list traffic from other lists I am subscribed to. This is a pretty > standard > convention that most lists use, and I would very much appreciate it if > this > list was configured to follow that convention as well. +1. Most of us process mail a first pass based on the subject. For example, any message directly sent to me should get read while mailing list messages with subject lines I'm not interested in are typically get deleted right away.... xorg is one of the few lists I'm on that doesn't have a subject line indicator. > Alan -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh From linuxhippy at gmail.com Mon Dec 3 15:46:14 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 4 Dec 2007 00:46:14 +0100 Subject: Benchmark of NVidia's new render accaleration :) Message-ID: <194f62550712031546r47487298maa4d446831a41665@mail.gmail.com> The new proprietary NVidia beta-drivers have hardware accaleration for even more advanced XRender operations, a benchmark has been published at: http://www.nvnews.net/vbulletin/attachment.php?attachmentid=29257&d=1196719662 Wow, the results look really promising. Even complex operations are accalerated :) I think its quite cool, with the rise of the EXA drivers and the proprietary drivers the time has come where using XRender does not mean software fallbacks everywhere. I hope I can find some time to adopt some applications to use XRender instead of the custom software rendering solutions. lg Clemens From keith at tungstengraphics.com Mon Dec 3 15:50:33 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Mon, 03 Dec 2007 23:50:33 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <59ad55d30712031343y7adf072ah3c1bffe3b7258dd5@mail.gmail.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> <47547327.7030605@tungstengraphics.com> <59ad55d30712031343y7adf072ah3c1bffe3b7258dd5@mail.gmail.com> Message-ID: <47549649.5070506@tungstengraphics.com> Kristian H?gsberg wrote: > On Dec 3, 2007 4:20 PM, Keith Whitwell wrote: > ... >>>> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. >>>> Nothing can interrupt a batchbuffer half-way through in our system. >>> MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch >>> buffer. >> I had trouble understanding this -- but indeed the address for the >> context is a *physical* address in system memory... Fabulous. > > No, it can be a GTT offset too, but it has to present when the context > is swapped out. That is not under our control, because it happens > when the next context is swapped in. So it has to be a no-evict > buffer. We don't want to fragment the GTT with no-evict buffers for > this stuff, so the physical address option looks more interesting. OK. >> That makes the whole scheme less interesting to me as it does rely on >> the kernel doing the state management, and at this point I don't really >> see this as being hugely worthwhile. > > What did you have in mind? The context buffers are opaque, it's just > a cookie you hold on to for the hardware. You can't peek into them and > manipulate the state anyway, so it doesn't seem to me that there's a > big difference in whether the kernel or user space track the state > buffers and issue the MI_SET_CONTEXT. I don't want to peek into the contexts (though if you do, you'll find they aren't all that opaque). I'm just saying I'd like to avoid adding complexity to the kernel module unless there's real evidence that 1) there's a performance gain and 2) that we can't achieve the same effect from userspace. >> Before you do this, it would be worthwhile to disable the preamble emit >> from the i915 driver and see if there is any measurable benefit. As >> long as you only run a single context and disable EXA, nothing bad >> should happen. > > I'll give that a try, and the thing to compare against is state > emission on every batch buffer, which is what we'll be doing without > the DRI lock. It's how the driver works at present. > No matter how it turns out, I doubt it will be a > performance regression, and will help with the EXA state tracking too. The smaller the average batchbuffer size is, the more it's likely to help. If exa is doing large numbers of tiny command streams, it could be a win. 3d tends to do large sequences of statechanges and rendering commands, so optimizing one away per batchbuffer isn't likely to be a huge win. The i915 swz code incorporates a state-differencer in the 3d driver that eliminates a large number of redundant state changes within the command stream in normal rendering -- it didn't seem to make a huge difference to performance in classic mode rendering. Most often it seems the hardware is gated on some rasterization bottleneck - either pure bandwidth in and out of the chip, or execution resources for the pixel shader. Keith From dberkholz at gentoo.org Mon Dec 3 16:23:22 2007 From: dberkholz at gentoo.org (Donnie Berkholz) Date: Mon, 3 Dec 2007 16:23:22 -0800 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> Message-ID: <20071204002322.GB29076@supernova> On 16:14 Mon 03 Dec , James Cloos wrote: > Mouse will continue to be needed even on evdev platforms until evdev has > support for emulating button 2 (thinkpad users are not the only laptop > users who want to do middle-button pasting) and probably support for > emulating a wheel as well (based on comments in a recent post). FWIW, inputd [1] is pretty nice for that. It's a userspace daemon to emulate keypresses with other ones using the kernel's uinput framework. I use it for ctrl+click as rightclick, and a couple function buttons as mouse 2&3. Thanks, Donnie 1. http://hansmi.ch/software/inputd From pcpa at mandriva.com.br Mon Dec 3 16:27:12 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Mon, 03 Dec 2007 22:27:12 -0200 Subject: About removing libc wrapper Message-ID: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> Hi, First forgive me if I am missing something. Would not it be better to keep/fix it? We already have modules depending on things like c99 math symbols, libdl symbols, libxfont* symbols, etc. And maybe soon depending on libhal, libdbus, etc, and anything else a module chooses to link with. If it works with libc variants, and compiles/works with other C compilers, it should not be a big problem. But besides there are some clear exceptions, like mesa that should not use wrappers for things like ``mathfuncf'' at least in software rendering mode, I think it should be better to have modules depending only on symbols in another module, or the X Server. I don't think we are going to have a sdk that would allow a vendor to distribe binaries that "just works" on Linux, FreeBSD, OpenBSD, NetBSD, Solaris, etc, anytime soon, and "killing" the libc wrapper basically gives up on the hope of having that working, unless something better is being worked on. "Binary only" vendor also usually provide their own libGL, video processing library, etc, so that is probably another reason to give up on hope about having a "binary compatible" api for different operating systems in the same processor architecture... There are other problems also, like modules using Linux only interfaces, or doing their own signal handling, creating pipes/fifos to communicate with other processes and the like. But a well thought api, that is another thing we are not likely to have anytime soon, would prevent problems like modules having a very small "lifetime" and needing to be rebuilt frequently. Paulo From daniel at fooishbar.org Mon Dec 3 16:36:56 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 4 Dec 2007 00:36:56 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203211933.GA26078@skynet.be> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> Message-ID: <20071204003656.GE6534@fooishbar.org> On Mon, Dec 03, 2007 at 10:19:33PM +0100, Luc Verhaegen wrote: > This would make > me personally, with my inbox == TODO list kind of mail handling, much > happier. Renaming all the files to hw_xfree86_common_xf86Xinput.c and similar would be very convenient for me, because I don't use directories. IOW, c'est la vie. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Mon Dec 3 17:06:14 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 4 Dec 2007 01:06:14 +0000 Subject: About removing libc wrapper In-Reply-To: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> References: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> Message-ID: <20071204010614.GF6534@fooishbar.org> On Mon, Dec 03, 2007 at 10:27:12PM -0200, pcpa at mandriva.com.br wrote: > I don't think we are going to have a sdk that would allow a > vendor to distribe binaries that "just works" on Linux, FreeBSD, > OpenBSD, NetBSD, Solaris, etc, anytime soon, and "killing" the > libc wrapper basically gives up on the hope of having that working, > unless something better is being worked on. I don't think this is really an interesting problem. > But a well thought api, that is another thing we are not likely > to have anytime soon, would prevent problems like modules > having a very small "lifetime" and needing to be rebuilt > frequently. These are not caused by people wanting to use a different libc every day of the week, or the definition of gettimeofday() changing. They're caused by the need to change internal structures, which we still expose because our API is fundamentally flawed. We can fix that and do better, regardless of the libcwrapper, which I'm personally happy to see dead. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From alan.coopersmith at sun.com Mon Dec 3 17:15:56 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Mon, 03 Dec 2007 17:15:56 -0800 Subject: About removing libc wrapper In-Reply-To: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> References: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> Message-ID: <4754AA4C.4040905@sun.com> pcpa at mandriva.com.br wrote: > I don't think we are going to have a sdk that would allow a > vendor to distribe binaries that "just works" on Linux, FreeBSD, > OpenBSD, NetBSD, Solaris, etc, anytime soon, and "killing" the > libc wrapper basically gives up on the hope of having that working, > unless something better is being worked on. > "Binary only" vendor also usually provide their own libGL, video > processing library, etc, so that is probably another reason to > give up on hope about having a "binary compatible" api for > different operating systems in the same processor architecture... Has any vendor ever produced an interesting closed binary driver that didn't have an associated kernel module? (I'm only familiar with the ones from ATI & nVidia, which both do.) I'm all for making it easier to support BSD & Solaris, but does this really do that? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From joerg at britannica.bec.de Mon Dec 3 17:24:05 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue, 4 Dec 2007 02:24:05 +0100 Subject: About removing libc wrapper In-Reply-To: <4754AA4C.4040905@sun.com> References: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> <4754AA4C.4040905@sun.com> Message-ID: <20071204012405.GA2128@britannica.bec.de> On Mon, Dec 03, 2007 at 05:15:56PM -0800, Alan Coopersmith wrote: > I'm all for making it easier to support BSD & Solaris, but does this > really do that? Speaking as someone who is maintaing support for at least two BSDs -- no, I don't think it helps very much. Making sure that all modules can be compiled with "-z defs" or the equivalent libtool option helps more than the restriction has. On the contrary it prevented e.g. Propolice from being usable out of the box. I agree, I still have to see a binary-only driver that doesn't depend on some kernel blob to work. Joerg From vignatti at c3sl.ufpr.br Mon Dec 3 17:33:07 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Mon, 03 Dec 2007 23:33:07 -0200 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <4754877E.3070503@ij.net> References: <200712032130.34559.arekm@maven.pl> <20071203213120.GA7191@srcf.ucam.org> <4754877E.3070503@ij.net> Message-ID: <4754AE53.5030100@c3sl.ufpr.br> There's no way to add that [blabla] identifier as a rule from procmail to includes it on the subject when someone receive an email? :) -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From pcpa at mandriva.com.br Mon Dec 3 18:03:41 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Tue, 04 Dec 2007 00:03:41 -0200 Subject: About removing libc wrapper In-Reply-To: <20071204012405.GA2128@britannica.bec.de> References: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> <4754AA4C.4040905@sun.com> <20071204012405.GA2128@britannica.bec.de> Message-ID: <20071204000341.sxr7melq560o888k@webmail.conectiva.com.br> Quoting Joerg Sonnenberger : > On Mon, Dec 03, 2007 at 05:15:56PM -0800, Alan Coopersmith wrote: >> I'm all for making it easier to support BSD & Solaris, but does this >> really do that? > > Speaking as someone who is maintaing support for at least two BSDs -- > no, I don't think it helps very much. Making sure that all modules can > be compiled with "-z defs" or the equivalent libtool option helps more > than the restriction has. On the contrary it prevented e.g. Propolice > from being usable out of the box. > > I agree, I still have to see a binary-only driver that doesn't depend on > some kernel blob to work. > > Joerg I am not advocating in favor or agains't libc wrapper. And it was causing more trouble than good, as several modules are compiled with a mix of libc wrapper and libc calls. If modules depends only on libc, libm and libdl (and vendor provided libraries) there should not exist problems, but if modules start depending on external apis that change frequently, things can become a mess, and this is already somewhat true now that we don't have a single tree and single "make World". A user space binary only for different operating systems, is possible (usually 2d), as well as an api that would make it easier to write the kernel portions (usually 3d) in an easier way. But easier said than done. Paulo From dant at cdkkt.com Mon Dec 3 19:40:49 2007 From: dant at cdkkt.com (Daniel B. Thurman) Date: Mon, 3 Dec 2007 19:40:49 -0800 Subject: [RESEND] xorg.conf - GD5480 Message-ID: <021126B987E43D44A860139823C079110E2BD6@orion.cdkkt.com> My apologies.... This is the 3rd time I am reposting because I did not get any response to this post. I discovered that my SPAM program was blocking all responses and I have now unblocked it. Please resend any replies or at least tell me where I can see the responses elsewhere (a website please?) Thanks- ============== REPOST =============== Hello, This is my first email message to this group, so please bear with me or direct me to where I need to go to report this "bug". My Hardware: ========== PC: VA Linux System, 600Mhz PIII RAM: 396MB Video: Cirrus GD5480 OS: Fedora releases 6/7/8. GDM was able to locate the cirrus chipset and xorg.conf shows: ==================================== Section "Device" Identifier "Screen0" Driver "cirrus" EndSection Section "Screen0" Device "Videocard0" DefaultDepth 24 EndSection ==================================== The problem here, is that the DefaultDepth is too high for cirrus chipsets that cannot support color depths higher than it is capable of, so GDM will fail to find a working screen resolution it can support. The following shows what had to be done to get the GDM working and I have found that even with the DefaultDepth set to 16, it is not sufficient to ignore the Modes as it must specify supported screen resolutions to ensure a successful GDM startup. #==================================== Section "Screen0" Device "Videocard0" DefaultDepth 16 SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" "640x480 EndSubSection EndSection #==================================== Thanks! No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.13/1165 - Release Date: 12/2/2007 8:34 PM From glynn at gclements.plus.com Mon Dec 3 22:59:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue, 4 Dec 2007 06:59:58 +0000 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <1196722397.29088.26.camel@behdad.behdad.org> References: <1196722397.29088.26.camel@behdad.behdad.org> Message-ID: <18260.64238.689313.737248@cerise.gclements.plus.com> Behdad Esfahbod wrote: > > The reason why I ask for [xorg] (or any other appropriate short unique > > descriptor) in the subject line is it makes it much easier to sort out > > this > > list traffic from other lists I am subscribed to. This is a pretty > > standard > > convention that most lists use, and I would very much appreciate it if > > this > > list was configured to follow that convention as well. > > +1. Most of us process mail a first pass based on the subject. You've conducted a survey? Or are you just assuming that most people work the way you do? > For > example, any message directly sent to me should get read while mailing > list messages with subject lines I'm not interested in are typically get > deleted right away.... The subject line won't tell you whether the mail was sent directly to you or came via the mailing list. Nothing stops someone from sending you a private reply with the [xorg] still in the subject line. > xorg is one of the few lists I'm on that doesn't > have a subject line indicator. For me, it's about 50/50. -- Glynn Clements From behdad at behdad.org Mon Dec 3 23:02:46 2007 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 04 Dec 2007 02:02:46 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <18260.64238.689313.737248@cerise.gclements.plus.com> References: <1196722397.29088.26.camel@behdad.behdad.org> <18260.64238.689313.737248@cerise.gclements.plus.com> Message-ID: <1196751766.10445.19.camel@behdad.behdad.org> On Tue, 2007-12-04 at 06:59 +0000, Glynn Clements wrote: > > > +1. Most of us process mail a first pass based on the subject. > > You've conducted a survey? Or are you just assuming that most people > work the way you do? Ok, you caught me. Excuse my ignorance. Whatever. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh From alexdeucher at gmail.com Mon Dec 3 23:12:16 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 4 Dec 2007 02:12:16 -0500 Subject: xorg.conf for GD5480 In-Reply-To: <021126B987E43D44A860139823C079110E2BCF@orion.cdkkt.com> References: <021126B987E43D44A860139823C079110E2BCF@orion.cdkkt.com> Message-ID: On Dec 3, 2007 5:10 PM, Daniel B. Thurman wrote: > Hello, > > This is my first email message to this group, so please bear with me or > direct me to where I need to go to report this "bug". You can open a bug on bugzilla (https://bugs.freedesktop.org), however, that chip is so ancient, I doubt you'll see anyone pick it up. Patches welcome of course :) Alex From tech at tnet.no Mon Dec 3 23:43:20 2007 From: tech at tnet.no (tech at tnet.no) Date: Tue, 4 Dec 2007 8:43:20 +0100 Subject: Multi X-session setup Message-ID: Oh, I see. Thanks for a great reply! I guess my two options are multiseat and use the void drivers for the other server, then control the second session remotely (by setting DISPLAY), or having one session disabling xinerema and just configuring mplayer to start on the other screen. I guess on second thought the latter would probably be best. I would by the way use the Sapphire Radeon HD 2400 PRO 256MB DDR2, PCI-Express, DVI-I/Tv-out/HDMI, Heatsink card at first since the X1250 does not have any s-video output and I have yet to afford a projector. I assume the X1250 is better qualiy right? On Tue, 4 Dec 2007 00:14:07 +0530, "JoJo jojo" wrote: > Hi > > I stand corrected, that was technically 1 GDM session, with 2 screens, > > the way I see it the problem is now this:- > > If we run 2 X servers using both GFX, then sharing Keyboard & Mouse is > a problem, > If we run 1 X server on 1 GFX with 2 Screens, then we get only 1 GDM > session. > > I would suggest to go along with the 2nd option, get only 1 GDM session, > > "How would I switch between these two sessions?" > Generally we can setup 2 screens right next to each other, > when mouse goes over the edge it appears on the next screen(keyboard > focus follows the mouse click) > > "Are the two screens independent of each other?" > I dunno what you mean by that, > with xinerama enabled the two screens merge seamlessly(one big > desktop, fullscreen application half visible on one screen, half on > the other screen), > with xinerama disabled they act independently(two desktops, fullscreen > applications occupy). > > If you still decide to go with 2 X servers, you could hardcode via udev > rules, > the exact USB ports(for keyboard mouse, to each seat, yup multiseat) > then to use one seat, you plug in the input marked for that seat, > to use the TV/Projector seat you plugin the inputs marked for the other > seat > > I believe Two Screens is what you are after, instead of two X servers. > > -Jojo > > On Dec 3, 2007 4:22 PM, wrote: >> >> Hello. >> Thanks for your reply! >> >> How would I switch between these two sessions? >> Are the two screens indepdendent of eachother? >> >> Sorry for HTML and CSS, I do not have access to a computer currently, so > I use >> a webmail that apparently is broken. >> >> On Mon, 3 Dec 2007 11:02:09 +0530, "JoJo jojo" > wrote: >> > Hi Thomas >> > >> > If I understand correctly, here are your requirements, >> > -2 independent GDM sessions, (i.e play a movie on 1 screen & a browser >> > on another screen, example) >> > -1 keyboard & 1 mouse >> > >> > The simplest solution is to setup ATI big desktop(aticonfig >> > --dtop=horizontal etc) & disable xinerama(xorg.conf) >> > the down side is that you only get user login on 1 screen & both >> > screen are under the same user login. >> > >> > -Jojo >> > PS: your valid HTML isnt, your valid css isnt. >> > >> > On Dec 2, 2007 11:05 AM, wrote: >> >> I do not speak this language, but it seems to be a multiseat setup, > and >> > seems to require to keyboards, which is not exactly what I want :( >> >> If I'm interepting this wrongly, could you explain how this concept > is? >> >> Because I do not want to keyboards, I want two sessions active at > both >> > sessions with one keyboard/mouse, with ability to disable/activate > them on >> > each sessions. >> >> >> >> If this is not a suitable solution for this, is there anyone else > than >> > can help? >> >> >> >> Thanks you. >> >> >> >> On Sat, 01 Dec 2007 07:41:12 -0200, Marcio Kleber Torres >> > wrote: >> >> > Hello. >> >> > >> >> > See this link, I think this is what you want, in any way it is the >> >> > beginning. >> >> > >> >> > Thank you. >> >> > >> >> > >> > >> > http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu_7.04 >> >> > >> >> > >> >> > >> >> > >> >> > Em S?b, 2007-12-01 ?s 06:30 +0100, tech at tnet.no escreveu: >> >> >> Hello. >> >> >> >> >> >> I don't have this equipment yet, but I will get it later today >> >> > hopefully. >> >> >> >> >> >> Motherboard: MSI K9AG NEO2-Digital, AMD 690G+SB600, Socket-AM2, >> >> > ATX,DDR2, DVI+HDMI, PCI-Ex16 with integrated ATI Radeon X1250 GPU. >> >> >> PCI-Expreses video-card: Sapphire Radeon HD 2400 PRO 256MB DDR2, >> >> > DVI-I/Tv-out/HDMI >> >> >> >> >> >> What I want is two have two seperate X sessions, with two > displays, >> > one >> >> > with tv or projector, the other my LCD monitor. Also, only one set > of >> >> > keyboard and mouse. >> >> >> >> >> >> The tv/projector one will be mainly be used to view high-quality >> > video >> >> > (1280p or 720i in xvid or x264) through mplayer, the other monitor >> > will >> >> > just be for general stuff. >> >> >> >> >> >> I want the video/picture at the X-sessions to be active at the > same >> >> > time, but with ability to switch between what X-session mouse and >> > keyboard >> >> > will be active/controlling to. >> >> >> >> >> >> I know there's an option for dual screen set-up, but this is not >> >> > something I quite feel comfortable with. >> >> >> >> >> >> What driver that will be used for whatever card is not something I >> > worry >> >> > about either, I don't mind if there's two different drivers or if > any >> > of >> >> > them is closed source. >> >> >> >> >> >> Is this possible and if so could someone hint me to how to do it, >> > either >> >> > in an explanation or a reference to documentation? >> >> >> If it is not, could someone please list similiar options I could > try? >> >> >> >> >> >> Thank you. >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> _______________________________________________ >> xorg mailing list >> xorg at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg From alexdeucher at gmail.com Mon Dec 3 23:30:19 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 4 Dec 2007 02:30:19 -0500 Subject: RandR module version, cant get V1.2 In-Reply-To: References: Message-ID: On Dec 3, 2007 4:01 AM, Ford Prefect wrote: > > > And now comes the question, randr is stiff-necked in reporting an older version: > > > > xrandr -v --verbose > > > > Server reports RandR version 1.1 > > ... > > I have found out under what circumstances the server does this: it happens when XGL is enabled. De-activating XGL leads to > > xrandr -v > > Server reports RandR version 1.2 > > ... and I can use all the fancy features V1.2 offers over V1.1. > > This is good news, but still a little bit unsatisfying. I know now HOW to use a work-around, but still don't know WHY exactly this happens. Any ideas from you guys? XGL is an xserver that runs on top of another xserver. Make sure you query the right display. Alex From tom at dbservice.com Mon Dec 3 23:32:59 2007 From: tom at dbservice.com (tom at dbservice.com) Date: Tue, 04 Dec 2007 08:32:59 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203222749.GA17150@britannica.bec.de> References: <20071203222749.GA17150@britannica.bec.de> Message-ID: <20071204083259.2244qzzgogowws4k@dbservice.com> Joerg Sonnenberger wrote: > On Mon, Dec 03, 2007 at 10:18:38PM +0000, Igor Mozolevsky wrote: >> On 03/12/2007, Alan W. Irwin wrote: >>> The reason why I ask for [xorg] (or any other appropriate short unique >>> descriptor) in the subject line is it makes it much easier to sort out this >>> list traffic from other lists I am subscribed to. This is a pretty standard >>> convention that most lists use, and I would very much appreciate it if this >>> list was configured to follow that convention as well. >> isn't there something in the RFCs about mangling headers?.. > > It breaks RE: processing, for example. > I haven't seen that happen in a long time. Most mailinglists don't prepend the prefix if the subject starts with Re: and the prefix is right after that, eg. Subject: Re: [compiz] object framework design. tom From bart at cs.pdx.edu Tue Dec 4 00:06:30 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Tue, 04 Dec 2007 00:06:30 -0800 Subject: X.Org Foundation Board Nominations Reopened Message-ID: <200712040806.lB486UN5028313@wezen.cs.pdx.edu> As many of you are aware, the initial announcements of the nomination period for the upcoming X.Org Foundation Board election were inadvertently not sent to the X.Org members' email list, although they were sent to the public list. Having received several complaints about this, the Election Committee has voted to reopen the nominations for a suitable period, so that those who were not aware of the earlier nomination period can participate. Also, to clarify the timeline a bit, nominees will have 24 hours from the time that nominations close to submit their personal statements and, if needed, membership applications. Thus, it is important that those who are nominating do so sooner rather than later. Nominations for the 2007 X.Org Foundation Board of Directors election are currently open and will remain open until 23.59 UTC on Sunday, 9 December 2007. All X.Org Foundation members are eligible for election to the board, and there is still time to apply for membership before the deadline. The Board consists of Directors elected from the membership. Each Director is elected to serve a two-year term. Each year, an election is held to bring the total number of Directors to eight. There are currently four Directors (Stuart Anderson, Stuart Kreitman, Kevin Martin, and Jim McQuillan) whose current term terminates in 2007, and four Directors (Egbert Eich, Bart Massey, Keith Packard, and Daniel Stone) whose current term continues through 2008. We thus need at least four nominees to fill the 2008 roster. Directors are expected to participate in regular email list discussions, IRC chats and conference calls to discuss current business. Directors are required to attend (at Foundation expense if necessary) the annual meeting of the X.Org Foundation, which will be held early in 2008 at a location to be determined by the Board of Directors. Directors are also encouraged to attend other official X.Org meetings and X-related events. Nominations must be made by a current X.Org member in good standing. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at: elections at x.org Nominees shall be required to be current members of the X.Org Foundation by the time the election is held, and to submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation submitted in the membership application, will be made available to all voters to help them make their voting decisions. Note that membership in the X.Org Foundation is required to be elected to the Board. Nominees must satisfy the membership criteria by the end of the nomination period. Nominations, membership application or renewal and completed personal statements must be received no later than 23.59 UTC on Sunday, 9 December 2007. Please feel free to forward or repost this message as appropriate. The Election Committee X.Org Foundation From alexdeucher at gmail.com Tue Dec 4 00:10:00 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 4 Dec 2007 03:10:00 -0500 Subject: r300, amd64, svideo In-Reply-To: <1196657610.3883.53.camel@dkasak.nusconsulting.com.au> References: <1196657610.3883.53.camel@dkasak.nusconsulting.com.au> Message-ID: On Dec 2, 2007 11:53 PM, Daniel Kasak wrote: > Hi all. > > Should tv-out via the svideo connector work on amd64 systems? I've got a > Radeon X700 Mobility chip. I don't know that anyone has tested an x700. It should work... in theory. > > I did some testing over the weekend. I tried pretty much all the > suggestions I found in the mailing list by searching for 'tv', including > the obvious: > > xrandr --output S-video --auto > ... or: > xrandr --output S-video --mode 800x600 > > ... then: > xrandr --output S-video --mode 800x600 > > Nothing happens :( > You'll need to add the mode to the output as well: xrandr --addmode S-video 800x600 xrandr --output S-video --mode 800x600 > xrandr -v --query says that I have an SVideo port, but it *always* says > it's disconnected. > > I've also tried booting with the SVideo cable connected ( used to work > on an older radeon ). You might try the most recent ati git master with Option "TVDACLoadDetect" "true" in your config. You can also force tv-out to always be detected as connected with Option "ForceTVOut" "true". Alex From khnz at gmx.de Tue Dec 4 04:40:40 2007 From: khnz at gmx.de (Robert Gerlach) Date: Tue, 4 Dec 2007 13:40:40 +0100 Subject: [RESEND] xorg.conf - GD5480 In-Reply-To: <021126B987E43D44A860139823C079110E2BD6@orion.cdkkt.com> References: <021126B987E43D44A860139823C079110E2BD6@orion.cdkkt.com> Message-ID: <200712041340.40687.khnz@gmx.de> Am Dienstag 04 Dezember 2007 04:40:49 schrieb Daniel B. Thurman: > This is the 3rd time I am reposting because I did not get any response > to this post. I discovered that my SPAM program was blocking all responses > and I have now unblocked it. Please resend any replies or at least tell me > where I can see the responses elsewhere (a website please?) Look into the mail header ;) List-Archive: From joerg at britannica.bec.de Tue Dec 4 06:45:27 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue, 4 Dec 2007 15:45:27 +0100 Subject: About removing libc wrapper In-Reply-To: <20071204000341.sxr7melq560o888k@webmail.conectiva.com.br> References: <20071203222712.sdse7txhqxywwco0@webmail.conectiva.com.br> <4754AA4C.4040905@sun.com> <20071204012405.GA2128@britannica.bec.de> <20071204000341.sxr7melq560o888k@webmail.conectiva.com.br> Message-ID: <20071204144527.GC27820@britannica.bec.de> On Tue, Dec 04, 2007 at 12:03:41AM -0200, pcpa at mandriva.com.br wrote: > If modules depends only on libc, libm and libdl (and vendor > provided libraries) there should not exist problems, but if modules > start depending on external apis that change frequently, things can > become a mess, and this is already somewhat true now that we > don't have a single tree and single "make World". It is not even as easy as that. libdl is a problem, because it doesn't exist on the BSDs. libc has a lot of functions and many don't provide an identical ABI on various platforms. Just to name a few things: - you can't use ctype.h without undefining all macros - you can't use stat(2) and friends - you can't even use read(2) and write(2) without care (32bit vs 64bit) - ... If anyone would ever want to make a binary userland driver, it should follow the approach used by Nvidia or Atheros for the kernel module. Provide a blob and a stub wrapper. Compile / modify the wrapper to match the target system and export a well defined ABI from it for the blob. Joerg From linuxhippy at gmail.com Tue Dec 4 07:44:39 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 4 Dec 2007 16:44:39 +0100 Subject: Looking for XRender examples Message-ID: <194f62550712040744i4d2eb8dfgc092b76cec6c9d5c@mail.gmail.com> Hello, Does anybody know tutorials for learning the XRender API? I found many tutorials for X11's primitive drawing but for XRender there is almost no developer documentation available. Thank you in advance, lg Clemens From j-engel at gmx.de Tue Dec 4 09:08:05 2007 From: j-engel at gmx.de (Johannes Engel) Date: Tue, 04 Dec 2007 18:08:05 +0100 Subject: removed launcher subdir in darwin Message-ID: <47558975.2090605@gmx.de> Maybe a little patch is needed for the Makefile.am in hw/darwin/, too. Greetings, Johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-remove-subdirectory-launcher-from-Makefile.am.patch Type: text/x-patch Size: 702 bytes Desc: not available URL: From lpe540 at yahoo.com Tue Dec 4 10:09:24 2007 From: lpe540 at yahoo.com (Joe Miller) Date: Tue, 4 Dec 2007 10:09:24 -0800 (PST) Subject: Xvfb problems with OpenGL feedback buffer Message-ID: <751359.65825.qm@web39605.mail.mud.yahoo.com> Hi, I'm having some problems running an opengl application in Xvfb, where the Xvfb server keeps dying. After some investigation, it looks like the problem occurs when I change the glFeedbackBuffer size from something very large (on order of 40,000,000 floating point array) to something smaller (4,000,000) and then change the glRenderMode from GL_FEEDBACK to GL_RENDER. I've included a small program below, which I think displays the problem I'm having (note this program was written explicitly to flush out the problems I'm having). While the program below segv's when I try to run it in Xvfb, a much more involved program where I first discovered the issue returns the following error message ChipsServer: Fatal IO error 14 (Bad address) on X server :6966.0. Both seemed to be caused by the same issue. I don't have any problems running either program with the standard X-Server. The problem only happens with a very large buffer size. I'm running on Redhat Enterprise 8, using X.Org version 6.8.2. I'd appreciate any thoughts or suggestions. If you need any more information please let me know. Thanks in advance. -joe I use the following command to run Xvfb g++ -g test.cc -lGL -lGLU -lglut setenv DISPLAY :01 Xvfb :01 -ac & ./a.out #include #include #include #include using namespace std; GLfloat *data = NULL; int numpnts = 5000000; int size = 2048*2048; bool feedbackmode = true; void RenderScene (void) { glClear (GL_COLOR_BUFFER_BIT); glColor3f (1, 0, 0); float col = 0.0; float indx = 1.0/1000; for (int ii=0; ii References: <751359.65825.qm@web39605.mail.mud.yahoo.com> Message-ID: <47559EA8.20301@tungstengraphics.com> Joe Miller wrote: > Hi, > > I'm having some problems running an opengl application in Xvfb, where > the Xvfb server keeps dying. After some investigation, it looks like the > problem occurs when I change the glFeedbackBuffer size from something > very large (on order of 40,000,000 floating point array) to something > smaller (4,000,000) and then change the glRenderMode from GL_FEEDBACK to > GL_RENDER. I've included a small program below, which I think displays > the problem I'm having (note this program was written explicitly to > flush out the problems I'm having). While the program below segv's when I > try to run it in Xvfb, a much more involved program where I first > discovered the issue returns the following error message > ChipsServer: Fatal IO error 14 (Bad address) on X server :6966.0. > Both seemed to be caused by the same issue. I don't have any problems > running either program with the standard X-Server. The problem only > happens with a very large buffer size. I'm running on Redhat Enterprise 8, > using X.Org version 6.8.2. > > I'd appreciate any thoughts or suggestions. If you need any more > information please let me know. Looks like a GLX protocol encode or decode bug. Seems to work fine with stand-alone Mesa and direct rendering. I may not get around to investigating for a bit though. Perhaps you could file a Mesa bug report so it doesn't get lost. -Brian From ggm at pobox.com Tue Dec 4 10:58:52 2007 From: ggm at pobox.com (George Michaelson) Date: Tue, 4 Dec 2007 10:58:52 -0800 Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? Message-ID: <20071204105852.56a9eec6@asmtp.apnic.net> https://bugs.freedesktop.org/show_bug.cgi?id=13107 bad outcome for some users from the XInput changes in between the old xf86-input-mouse and the 1.6.19x code. somewhere in the abstract model which has to take wscons events, and make synthetic X input events, we loose the dx/absx value and the mouse swishes over to the hard-left. Its triggered by a motion event over window decor, or during repaint of sub-elements in a complex (typically gnome) application I put it into bugzilla as a low priority problem, but it does make the system unusable. the remediation is not good: don't upgrade to 7.0. :-( Please, can I beg some brainpower? It might be finger-pointing between the OS and Xorg, but I think it needs Xorg consideration before I work on NetBSD to fix.. cheers -George From reed at reedmedia.net Tue Dec 4 11:36:09 2007 From: reed at reedmedia.net (reed at reedmedia.net) Date: Tue, 4 Dec 2007 13:36:09 -0600 (CST) Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? In-Reply-To: <20071204105852.56a9eec6@asmtp.apnic.net> References: <20071204105852.56a9eec6@asmtp.apnic.net> Message-ID: Is this the same as https://bugs.freedesktop.org/show_bug.cgi?id=3113 or https://bugs.freedesktop.org/show_bug.cgi?id=13010 What xorg-server are you using? I think it is fixed in 1.4. From krh at bitplanet.net Tue Dec 4 11:43:14 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Tue, 4 Dec 2007 14:43:14 -0500 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <47549649.5070506@tungstengraphics.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> <47547327.7030605@tungstengraphics.com> <59ad55d30712031343y7adf072ah3c1bffe3b7258dd5@mail.gmail.com> <47549649.5070506@tungstengraphics.com> Message-ID: <59ad55d30712041143i7cd84aag5abedab589ed051c@mail.gmail.com> On Dec 3, 2007 6:50 PM, Keith Whitwell wrote: > Kristian H?gsberg wrote: > > On Dec 3, 2007 4:20 PM, Keith Whitwell wrote: > > ... > >>>> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. > >>>> Nothing can interrupt a batchbuffer half-way through in our system. > >>> MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch > >>> buffer. > >> I had trouble understanding this -- but indeed the address for the > >> context is a *physical* address in system memory... Fabulous. > > > > No, it can be a GTT offset too, but it has to present when the context > > is swapped out. That is not under our control, because it happens > > when the next context is swapped in. So it has to be a no-evict > > buffer. We don't want to fragment the GTT with no-evict buffers for > > this stuff, so the physical address option looks more interesting. > > OK. > > >> That makes the whole scheme less interesting to me as it does rely on > >> the kernel doing the state management, and at this point I don't really > >> see this as being hugely worthwhile. > > > > What did you have in mind? The context buffers are opaque, it's just > > a cookie you hold on to for the hardware. You can't peek into them and > > manipulate the state anyway, so it doesn't seem to me that there's a > > big difference in whether the kernel or user space track the state > > buffers and issue the MI_SET_CONTEXT. > > I don't want to peek into the contexts (though if you do, you'll find > they aren't all that opaque). > > I'm just saying I'd like to avoid adding complexity to the kernel module > unless there's real evidence that 1) there's a performance gain and 2) > that we can't achieve the same effect from userspace. Right, we're on the same page here. However, since MI_SET_CONTEXT can not be used from a batch buffer, we have the following options: 1) Don't use MI_SET_CONTEXT, always emit full state 2) Use MI_SET_CONTEXT from the kernel, based on drm_context_t in super-ioctl 3) Emit MI_SET_CONTEXT from userspace Maybe 1) is feasible, I don't know for sure. I'm a little confused, to be honest, as I keep hearing that state emission is killing performance and Gallium is built around state caching and tries very hard to avoid superfluous state emission. At the same time, I hear that emitting full state is negligible and not worth optimizing... where's the disconnect? As for 3), this requires access to the ring buffer from userspace and thus locking, and I think we agree that that's not something we should design into the system. Which leaves us with 2) which isn't all that complicated, in fact I think I have something running here (patches forthcoming). In the meantime, do you have any objections to the original patch (removing DDX driver use of MI_SET_CONTEXT)? If nothing else this allows us to move forward on making the intel drivers lockless. cheers, Kristian From xavier.bestel at free.fr Tue Dec 4 11:48:03 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Tue, 04 Dec 2007 20:48:03 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: Message-ID: <1196797683.5029.4.camel@bip.parateam.prv> Le lundi 03 d?cembre 2007 ? 12:20 -0800, Alan W. Irwin a ?crit : > The reason why I ask for [xorg] (or any other appropriate short unique > descriptor) in the subject line is it makes it much easier to sort out this > list traffic from other lists I am subscribed to. This is a pretty standard > convention that most lists use, and I would very much appreciate it if this > list was configured to follow that convention as well. I'd prefer it if you could find an other way to filter. E.g. I apply a color filter on all my list mails, so each mailing-list has its own color. Very convenient. Xav From keith at tungstengraphics.com Tue Dec 4 12:32:00 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Tue, 04 Dec 2007 20:32:00 +0000 Subject: [PATCH] Remove spurious use of MI_SET_CONTEXT. In-Reply-To: <59ad55d30712041143i7cd84aag5abedab589ed051c@mail.gmail.com> References: <1196707258-8688-1-git-send-email-krh@bitplanet.net> <47545760.4080404@tungstengraphics.com> <59ad55d30712031216l108ec065pd7c9bca473fdbad6@mail.gmail.com> <475468F1.9040807@tungstengraphics.com> <59ad55d30712031307t7b3fef50kc73916028c49de26@mail.gmail.com> <47547327.7030605@tungstengraphics.com> <59ad55d30712031343y7adf072ah3c1bffe3b7258dd5@mail.gmail.com> <47549649.5070506@tungstengraphics.com> <59ad55d30712041143i7cd84aag5abedab589ed051c@mail.gmail.com> Message-ID: <4755B940.6060405@tungstengraphics.com> Kristian H?gsberg wrote: > On Dec 3, 2007 6:50 PM, Keith Whitwell wrote: >> Kristian H?gsberg wrote: >>> On Dec 3, 2007 4:20 PM, Keith Whitwell wrote: >>> ... >>>>>> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble. >>>>>> Nothing can interrupt a batchbuffer half-way through in our system. >>>>> MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch >>>>> buffer. >>>> I had trouble understanding this -- but indeed the address for the >>>> context is a *physical* address in system memory... Fabulous. >>> No, it can be a GTT offset too, but it has to present when the context >>> is swapped out. That is not under our control, because it happens >>> when the next context is swapped in. So it has to be a no-evict >>> buffer. We don't want to fragment the GTT with no-evict buffers for >>> this stuff, so the physical address option looks more interesting. >> OK. >> >>>> That makes the whole scheme less interesting to me as it does rely on >>>> the kernel doing the state management, and at this point I don't really >>>> see this as being hugely worthwhile. >>> What did you have in mind? The context buffers are opaque, it's just >>> a cookie you hold on to for the hardware. You can't peek into them and >>> manipulate the state anyway, so it doesn't seem to me that there's a >>> big difference in whether the kernel or user space track the state >>> buffers and issue the MI_SET_CONTEXT. >> I don't want to peek into the contexts (though if you do, you'll find >> they aren't all that opaque). >> >> I'm just saying I'd like to avoid adding complexity to the kernel module >> unless there's real evidence that 1) there's a performance gain and 2) >> that we can't achieve the same effect from userspace. > > Right, we're on the same page here. However, since MI_SET_CONTEXT can > not be used from a batch buffer, we have the following options: > > 1) Don't use MI_SET_CONTEXT, always emit full state > 2) Use MI_SET_CONTEXT from the kernel, based on drm_context_t in super-ioctl > 3) Emit MI_SET_CONTEXT from userspace > > Maybe 1) is feasible, I don't know for sure. I'm a little confused, > to be honest, as I keep hearing that state emission is killing > performance and Gallium is built around state caching and tries very > hard to avoid superfluous state emission. At the same time, I hear > that emitting full state is negligible and not worth optimizing... > where's the disconnect? I'm not against an MI_SET_CONTEXT approach. I'm a little disappointed that it requires kernel support to achieve it, otherwise it would be a no-brainer. Even requiring kernel changes, if there is a real benefit to performance, we probably want to do it -- but I'd like to figure out if that benefit is real or not first. Anway, regarding (1), we're talking about one statechange per batchbuffer, possibly one per frame in a reasonably optimized driver -- that is going to be negligible no matter what. I think the only time you'll start to notice it is if you get large numbers of tiny batchbuffers being emitted for some pathological reason. > As for 3), this requires access to the ring buffer from userspace and > thus locking, and I think we agree that that's not something we should > design into the system. It's utterly broken. It can't be made to work in fact as the 3d client cannot get to the ring even if it holds the lock. > Which leaves us with 2) which isn't all that > complicated, in fact I think I have something running here (patches > forthcoming). Do you see a performance gain for 3d? For EXA? > In the meantime, do you have any objections to the original patch > (removing DDX driver use of MI_SET_CONTEXT)? If nothing else this > allows us to move forward on making the intel drivers lockless. I've got no problem with removing that code. I had some concerns about running it once for safety at init time, but probably even that I'm OK with now. The fact that it has to be done from the ring means it's pretty unlikely that the bugs I saw related to this packet -- I think it's probably safe to remove it. Keith From jra at baylink.com Tue Dec 4 13:46:02 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 4 Dec 2007 16:46:02 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071203220817.GA4898@bludgeon.org> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> <1196718476.13688.118.camel@dyn-145116034060> <20071203220817.GA4898@bludgeon.org> Message-ID: <20071204214602.GC30249@cgi.jachomes.com> On Mon, Dec 03, 2007 at 02:08:17PM -0800, Ray Van Dolson wrote: > Since we're all sharing, I don't mind either way. I kinda like the > brackets as well, but I also don't run my mutt in an 80 column wide > xterm either. :) How, then do you get the vi's that it spawns to be only 80 columns wide, so that wm=9 does something sane for you? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From jra at baylink.com Tue Dec 4 13:48:08 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 4 Dec 2007 16:48:08 -0500 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071204083259.2244qzzgogowws4k@dbservice.com> References: <20071203222749.GA17150@britannica.bec.de> <20071204083259.2244qzzgogowws4k@dbservice.com> Message-ID: <20071204214808.GD30249@cgi.jachomes.com> On Tue, Dec 04, 2007 at 08:32:59AM +0100, tom at dbservice.com wrote: > I haven't seen that happen in a long time. Most mailinglists don't > prepend the prefix if the subject starts with Re: and the prefix is > right after that, eg. > Subject: Re: [compiz] object framework design. More properly, most mlm's (I believe this is how mailman works, and everyone should be using that anyway :-) don't tag the subject *if it contains the tag at all*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From ggm at pobox.com Tue Dec 4 13:50:20 2007 From: ggm at pobox.com (George Michaelson) Date: Tue, 4 Dec 2007 13:50:20 -0800 Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? In-Reply-To: References: <20071204105852.56a9eec6@asmtp.apnic.net> Message-ID: <20071204135020.5186600f@asmtp.apnic.net> On Tue, 4 Dec 2007 13:36:09 -0600 (CST) reed at reedmedia.net wrote: > Is this the same as > > https://bugs.freedesktop.org/show_bug.cgi?id=3113 yes. But, interestingly, I don't see how the subsequent comments about a patch can be true, because I can't see them in the code state I can fetch. (if you can help clue me up, thats good) > > or > > https://bugs.freedesktop.org/show_bug.cgi?id=13010 it *may* be the same. the symptom has a difference, but its in the same class. > > What xorg-server are you using? I think it is fixed in 1.4. I don't think it is. I have been testing with the modular-xorg-servers for 1.3.99, and 1.4, both Joerg and Blairs code in x11/ and wip/ and thats when this problem shows up: its on the OLDER server, I don't have the problem. I have just unpacked 1.4, and I have git head state, and I must be doing something wrong: I cannot find the patch that is attached to the above bug as being applied. neither by code looking, nor GIT logs. (thats what worries me. I did check git-log, and I cannot find the log of the applied patch that Eric and co say they applied, and back-ported to 1.4) the current state of hw/xfree86/common/xf86Xinput.c does not have any instances of pow() or float() and is substantially different to the one that patch appears to have been applied to. in the 1.3.99 and the 1.4 I can fetch. Have I gone badly wrong here? -George > From rayvd at bludgeon.org Tue Dec 4 13:57:12 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 4 Dec 2007 13:57:12 -0800 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071204214602.GC30249@cgi.jachomes.com> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <1196718606.3883.67.camel@dkasak.nusconsulting.com.au> <1196718476.13688.118.camel@dyn-145116034060> <20071203220817.GA4898@bludgeon.org> <20071204214602.GC30249@cgi.jachomes.com> Message-ID: <20071204215712.GA7945@bludgeon.org> On Tue, Dec 04, 2007 at 04:46:02PM -0500, Jay R. Ashworth wrote: > On Mon, Dec 03, 2007 at 02:08:17PM -0800, Ray Van Dolson wrote: > > Since we're all sharing, I don't mind either way. I kinda like the > > brackets as well, but I also don't run my mutt in an 80 column wide > > xterm either. :) > > How, then do you get the vi's that it spawns to be only 80 columns > wide, so that wm=9 does something sane for you? :-) > I use set editor="vim -c 'set fo=tcrq' -c 'set tw=71' -c 'set sw=2' -c 'set ts=2'" In mutt and it all seems to work out. Sometimes a little reformatting is required... Now we're getting wayyy off-topic. :) Ray From glisse at freedesktop.org Tue Dec 4 14:26:00 2007 From: glisse at freedesktop.org (Jerome Glisse) Date: Tue, 4 Dec 2007 23:26:00 +0100 Subject: Radeon kernel mode setting code Message-ID: <20071204232600.d7592fc8.glisse@freedesktop.org> Hi, So here it's my kernel modesetting code finaly accessible publicly :) git clone git://people.freedesktop.org/~glisse/drm The beast is in modesetting-radeon code. This is primilary work ie this is not intended for end user but for developer, curious people or people living beyond the edge. Here is a todo list that pop from the top of my brain: - add crtc2 - tmds - lvds - add bios data table so we don't need to hardcode dac/crtc infos - separate clock control to make power saving easier & cleaner - tiling (warning tiling shouldn't be enable in double scan or interlace) - surface reg manager (this goes along with tiling) - suspend/resume hook - avivo & r500 family support - atom bios support (for posting card mostly) - finish superioctl skeleton Well of course i welcome any patch on this topics :) Now my plan is to work on dri2 and gallium driver for r300/r400 family i hope to be able to demonstrate this at fosdem 2008. You will likely see xserver & mesa repository popup soon in my private area at fdo. I also would like to thanks every people who helped me to better understand this hw and to help me fixing bug i did encouter. Cheers, Jerome Glisse From justin at mythtvthemes.co.uk Tue Dec 4 15:08:52 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Tue, 04 Dec 2007 23:08:52 +0000 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output Message-ID: <4755DE04.5070808@mythtvthemes.co.uk> Hi folks. I'm experiencing a slight problem with svideo out using the 'intel' driver version 2.1. I eventually managed to find out how to use xrandr to set the TV standard to PAL and how to get the picture nicely overscanned with the margin setting options of xrandr but... I've noticed that the svideo connection on my Aopen motherboard is flickering slightly near the top of the screen. Turning the colour control on the TV down makes the problem go away which seems to indicate an issue with the chroma signal on the svideo port. I quickly hacked a spare svideo cable up a little and found (by connecting the Y output to a composite input on the TV) that the chroma signal is also present on the Y pin. It's my understanding that for svideo, only luminance should be present. Depending on how the TV treats svideo internally, having chrominance on Y & C could cause problems. I don't know anything about the TV encoder used on this board (yet) but I have access to video test gear at work where I plan to have a real good look at the signals coming out of the svideo port. We also have good monitors which I know for sure don't do any quick & dirty tricks with Y&C signals so if the issue is one of 'beating' of the 'Y chroma' and C signals it should look nice & clean on there. Are there any quick things I can try? It seems (from a quick look in the driver code) that xrandr supports only TV_FORMAT & margin adjustments for the TV encoder. All the timing values look sane to me but as I've already said I plan to examine the signals very closely at work. Regards, Justin From keithp at keithp.com Tue Dec 4 17:55:44 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 04 Dec 2007 17:55:44 -0800 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <4755DE04.5070808@mythtvthemes.co.uk> References: <4755DE04.5070808@mythtvthemes.co.uk> Message-ID: <1196819744.4698.177.camel@koto.keithp.com> On Tue, 2007-12-04 at 23:08 +0000, Justin Hornsby wrote: > Hi folks. > > I'm experiencing a slight problem with svideo out using the 'intel' > driver version 2.1. > > I eventually managed to find out how to use xrandr to set the TV > standard to PAL and how to get the picture nicely overscanned with the > margin setting options of xrandr but... > > I've noticed that the svideo connection on my Aopen motherboard is > flickering slightly near the top of the screen. Turning the colour > control on the TV down makes the problem go away which seems to indicate > an issue with the chroma signal on the svideo port. I quickly hacked a > spare svideo cable up a little and found (by connecting the Y output to > a composite input on the TV) that the chroma signal is also present on > the Y pin. It's my understanding that for svideo, only luminance should > be present. Depending on how the TV treats svideo internally, having > chrominance on Y & C could cause problems. If you hook only the Y pin up, the encoder will be configured for composite video; it automatically detects the kind of cable purely based on which wires are connected. It shouldn't change after you've turned it on though, so hooking it up to svideo, starting the output, then switching should keep it in svideo mode. > I don't know anything about the TV encoder used on this board (yet) but > I have access to video test gear at work where I plan to have a real > good look at the signals coming out of the svideo port. We also have > good monitors which I know for sure don't do any quick & dirty tricks > with Y&C signals so if the issue is one of 'beating' of the 'Y chroma' > and C signals it should look nice & clean on there. > > Are there any quick things I can try? It seems (from a quick look in > the driver code) that xrandr supports only TV_FORMAT & margin > adjustments for the TV encoder. All the timing values look sane to me > but as I've already said I plan to examine the signals very closely at work. Oh, cool! I looked at getting some TV test equipment to figure out whether I was generating legal signals, but couldn't really justify the price. There are a million values you can frob to play with the video signals, but most of them are not exposed through the protocol. Check out i830_tv.c and i810_reg.h which documents the relevant registers reasonably completely. In particular, using one of the test patterns may help isolate the particular issues you're seeing with the image. Let me know if you have specific signal problems and I'll read through the documentation to see what I can figure out. -- keith.packard at intel.com -------------- 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 jbarnes at virtuousgeek.org Tue Dec 4 18:33:46 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 4 Dec 2007 18:33:46 -0800 Subject: xf86-video-intel In-Reply-To: <20071128211052.GC4422@ics.muni.cz> References: <20071120203931.GA9092@ics.muni.cz> <200711281235.41211.jbarnes@virtuousgeek.org> <20071128211052.GC4422@ics.muni.cz> Message-ID: <200712041833.46770.jbarnes@virtuousgeek.org> On Wednesday, November 28, 2007 1:10 pm Lukas Hejtmanek wrote: > On Wed, Nov 28, 2007 at 12:35:41PM -0800, Jesse Barnes wrote: > > Does this patch work for you guys? > > > > It properly gets the backlight at startup time, saves and restores it > > across DPMS on/off calls, and doesn't mess with it at startup time (iow > > it assumes you have it where you want it when you start X). > > did not try it yet but what happens if some application does something like > xset dpms force off; xset dpms force off? i.e. it sets lvdspanelpower off > twice. Tracking this issue in 13306, can you confirm that the patch there works for you? Thanks, Jesse From zhenyu.z.wang at intel.com Tue Dec 4 19:12:14 2007 From: zhenyu.z.wang at intel.com (Zhenyu Wang) Date: Wed, 5 Dec 2007 11:12:14 +0800 Subject: G35/33 X3500/3100 HDMI In-Reply-To: <200712031331.46600.jbarnes@virtuousgeek.org> References: <4752EB4E.9000002@trypill.org> <200712031153.05621.jbarnes@virtuousgeek.org> <47547430.7050909@trypill.org> <200712031331.46600.jbarnes@virtuousgeek.org> Message-ID: <20071205031214.GA669@zhen-devel.sh.intel.com> On 2007.12.03 13:31:45 +0000, Jesse Barnes wrote: > > > > Any idea about mpeg2 acceleration support ? > > (There is hardware support for that, according to wikipedia) > i915's mpeg2 mc decoding acceleration is mostly ready, one missing feature is subpicture, thus breaks OSD. I'll push refactored code to another 'xvmc' branch of intel video driver soon, and currently working on i965 xvmc mpeg2 mc. From rglowery at exemail.com.au Tue Dec 4 20:43:35 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Wed, 5 Dec 2007 15:43:35 +1100 (EST) Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <1196819744.4698.177.camel@koto.keithp.com> References: <4755DE04.5070808@mythtvthemes.co.uk> <1196819744.4698.177.camel@koto.keithp.com> Message-ID: <34902.64.213.30.2.1196829815.squirrel@webmail.exetel.com.au> > > On Tue, 2007-12-04 at 23:08 +0000, Justin Hornsby wrote: >> Hi folks. >> >> I'm experiencing a slight problem with svideo out using the 'intel' >> driver version 2.1. >> >> I eventually managed to find out how to use xrandr to set the TV >> standard to PAL and how to get the picture nicely overscanned with the >> margin setting options of xrandr but... >> >> I've noticed that the svideo connection on my Aopen motherboard is >> flickering slightly near the top of the screen. Turning the colour >> control on the TV down makes the problem go away which seems to indicate >> an issue with the chroma signal on the svideo port. I quickly hacked a >> spare svideo cable up a little and found (by connecting the Y output to >> a composite input on the TV) that the chroma signal is also present on >> the Y pin. It's my understanding that for svideo, only luminance should >> be present. Depending on how the TV treats svideo internally, having >> chrominance on Y & C could cause problems. > > If you hook only the Y pin up, the encoder will be configured for > composite video; it automatically detects the kind of cable purely based > on which wires are connected. It shouldn't change after you've turned it > on though, so hooking it up to svideo, starting the output, then > switching should keep it in svideo mode. > >> I don't know anything about the TV encoder used on this board (yet) but >> I have access to video test gear at work where I plan to have a real >> good look at the signals coming out of the svideo port. We also have >> good monitors which I know for sure don't do any quick & dirty tricks >> with Y&C signals so if the issue is one of 'beating' of the 'Y chroma' >> and C signals it should look nice & clean on there. >> >> Are there any quick things I can try? It seems (from a quick look in >> the driver code) that xrandr supports only TV_FORMAT & margin >> adjustments for the TV encoder. All the timing values look sane to me >> but as I've already said I plan to examine the signals very closely at >> work. > > Oh, cool! I looked at getting some TV test equipment to figure out > whether I was generating legal signals, but couldn't really justify the > price. > > There are a million values you can frob to play with the video signals, > but most of them are not exposed through the protocol. Check out > i830_tv.c and i810_reg.h which documents the relevant registers > reasonably completely. In particular, using one of the test patterns may > help isolate the particular issues you're seeing with the image. > > Let me know if you have specific signal problems and I'll read through > the documentation to see what I can figure out. Hi Keith, I've been trying to track down some geometry issues I am seeing in PAL and 576p modes of the intel driver. https://bugs.freedesktop.org/show_bug.cgi?id=13165 In essence, I believe the raster being generated is a bit too small, resulting in black borders etc. Do you know what some of the magic numbers in i830_tv.c are for (eg 32, 33, 64 and 96 below) 1435 mode_ptr->HDisplay = hactive_s; 1436 mode_ptr->HSyncStart = hactive_s + 1; 1437 mode_ptr->HSyncEnd = hactive_s + 64; 1438 if ( mode_ptr->HSyncEnd <= mode_ptr->HSyncStart) 1439 mode_ptr->HSyncEnd = mode_ptr->HSyncStart + 1; 1440 mode_ptr->HTotal = hactive_s + 96; 1441 1442 mode_ptr->VDisplay = vactive_s; 1443 mode_ptr->VSyncStart = vactive_s + 1; 1444 mode_ptr->VSyncEnd = vactive_s + 32; 1445 if ( mode_ptr->VSyncEnd <= mode_ptr->VSyncStart) 1446 mode_ptr->VSyncEnd = mode_ptr->VSyncStart + 1; 1447 mode_ptr->VTotal = vactive_s + 33; > -- > keith.packard at intel.com > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From torgeir at pobox.com Tue Dec 4 21:03:36 2007 From: torgeir at pobox.com (Torgeir Veimo) Date: Wed, 5 Dec 2007 15:03:36 +1000 Subject: G35/33 X3500/3100 HDMI In-Reply-To: <20071205031214.GA669@zhen-devel.sh.intel.com> References: <4752EB4E.9000002@trypill.org> <200712031153.05621.jbarnes@virtuousgeek.org> <47547430.7050909@trypill.org> <200712031331.46600.jbarnes@virtuousgeek.org> <20071205031214.GA669@zhen-devel.sh.intel.com> Message-ID: <5FC41736-5C87-4D84-BA0D-B1294D64B286@pobox.com> On 5 Dec 2007, at 13:12, Zhenyu Wang wrote: > On 2007.12.03 13:31:45 +0000, Jesse Barnes wrote: >>> >>> Any idea about mpeg2 acceleration support ? >>> (There is hardware support for that, according to wikipedia) >> > i915's mpeg2 mc decoding acceleration is mostly ready, one missing > feature is subpicture, thus breaks OSD. I'll push refactored code > to another 'xvmc' branch of intel video driver soon, and currently > working on i965 xvmc mpeg2 mc. The 945 has iDCT right, while the 915 has only MC? Will you support iDCT in the driver as well? Also, is there any plans to bring DXVA style acceleration to X11 as an extension? It would be usefull for H.264. -- Torgeir Veimo torgeir at pobox.com From zhenyu.z.wang at intel.com Tue Dec 4 21:11:08 2007 From: zhenyu.z.wang at intel.com (Zhenyu Wang) Date: Wed, 5 Dec 2007 13:11:08 +0800 Subject: G35/33 X3500/3100 HDMI In-Reply-To: <5FC41736-5C87-4D84-BA0D-B1294D64B286@pobox.com> References: <4752EB4E.9000002@trypill.org> <200712031153.05621.jbarnes@virtuousgeek.org> <47547430.7050909@trypill.org> <200712031331.46600.jbarnes@virtuousgeek.org> <20071205031214.GA669@zhen-devel.sh.intel.com> <5FC41736-5C87-4D84-BA0D-B1294D64B286@pobox.com> Message-ID: <20071205051108.GA758@zhen-devel.sh.intel.com> On 2007.12.05 15:03:36 +0000, Torgeir Veimo wrote: > > The 945 has iDCT right, while the 915 has only MC? Correct, 945G can support mpeg2 VLD level decoding. > Will you support iDCT in the driver as well? It depends on time and resource, and spec for i945 VLD is also limited. I would put this later. > Also, is there any plans to bring DXVA style acceleration to X11 as an > extension? It would be usefull for H.264. No plan yet, but current work on i915 and i965 is aimed to be easily ported to other framework as needed. We're considering H.264 support within XvMC or not, my draft proposal change to XvMC is on http://cgit.freedesktop.org/~zhen/videoproto/log/?h=h264 From keithp at keithp.com Tue Dec 4 21:39:26 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 04 Dec 2007 21:39:26 -0800 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <34902.64.213.30.2.1196829815.squirrel@webmail.exetel.com.au> References: <4755DE04.5070808@mythtvthemes.co.uk> <1196819744.4698.177.camel@koto.keithp.com> <34902.64.213.30.2.1196829815.squirrel@webmail.exetel.com.au> Message-ID: <1196833166.4698.184.camel@koto.keithp.com> On Wed, 2007-12-05 at 15:43 +1100, Robert Lowery wrote: > In essence, I believe the raster being generated is a bit too small, > resulting in black borders etc. Do you know what some of the magic > numbers in i830_tv.c are for (eg 32, 33, 64 and 96 below) The TV encoder doesn't use the normal CRTC mechanism, so these are all just fake values designed to report the right refresh rate to the application. You should be able to frob them without any visible effect. For your 576p at 50.0 hz, if you can figure out what's wrong with the signal, I can read through the docs and figure out how to fix it. Without knowing what's wrong, just frobbing values may take a long time to fix it. -- keith.packard at intel.com -------------- 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 manuel.teira at telefonica.net Wed Dec 5 02:40:22 2007 From: manuel.teira at telefonica.net (Manuel Teira) Date: Wed, 05 Dec 2007 11:40:22 +0100 Subject: [kdrive] Multiple offscreen areas in KdScreenInfo Message-ID: <1196851222.6127.13.camel@localhost> Hello. I'm developing a kdrive driver for the ATI imageon 100 embedded card. Since this card has a particular memory layout, with two available areas, mapped in different locations and that cannot be combined in a single zone, I've made some changes to the kdrive offscreen infrastructure. The main change is replacing the current memory_size and off_screen_base in the KdScreenInfo structure with a new KdVideoMemArea **videomem_areas, changing accordingly all the usage in the kdrive core. Furthermore, any KdVideoMemArea can be assigned a different priority. This is needed since one of the memory areas in the Imageon has better access times, and is preferred to place overlays, for example. Hence, we need to provide a way to model that from userland. The new KdOffscreenAllocPrio call is used to fill that gap. As an example, I've also adapted the fbdev driver as a proof of concept. Of course, changes in all the drivers will be needed, but I expect not to be very hard to adapt them. I would like to expose here the patch, as a call for comments, and to see if it could eventually be merged in the upstream kdrive. If this ever happens, I should also contribute with my imageon driver to the xorg project. Best regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: kdrive-vidmemarea.diff Type: text/x-patch Size: 24405 bytes Desc: not available URL: From harry at unheit.net Wed Dec 5 02:51:31 2007 From: harry at unheit.net (Harald Braumann) Date: Wed, 5 Dec 2007 11:51:31 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> Message-ID: <20071205115131.593289d8@sbs173> On Mon, 03 Dec 2007 14:35:02 -0800 (PST) "Alan W. Irwin" wrote: > On 2007-12-03 21:35-0000 Alan Cox wrote: > > >> That works for automatic filtering, but is not nearly as > >> convenient for filtering by humans as a simple descriptor in the > >> subject line. I assume that is why most lists have such a > >> subject-line descriptor enabled. So I renew my request that this > >> list conform to that convention. > > > > Some of us humans also prefer not to have [thingsialreadyknow] > > taking up chunks of subject line hiding the real subject. > > > > You can use procmail to achieve what you want without messing it up > > for the rest of us > > Thanks for that good idea. At first I thought you were referring to > automatic filtering of this list into a separate e-mail folder (which > I don't want), but now I realize you were suggesting a procmail rule > just for subject-line tweaking. That works for me. Just make sure to remove that [xorg] part again, when replying to the list. I'm one of those who don't want to have superfluous information in the subject. Actually I don't understand why people want to do things manually that a computer can do automatically. Even more so when the needed information is already present in an easily parsable way (List-Id:). But what do I know. Regards, harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From olafBuddenhagen at gmx.net Wed Dec 5 02:04:15 2007 From: olafBuddenhagen at gmx.net (olafBuddenhagen at gmx.net) Date: Wed, 5 Dec 2007 11:04:15 +0100 Subject: Website maintenance volunteers? In-Reply-To: <20071202172432.GE21078@cgi.jachomes.com> References: <226dee610711300409y6e6e2681h6509243538e37d90@mail.gmail.com> <20071128183851.GM3067@fooishbar.org> <20071128200439.GE30794@bryceharrington.org> <200712010029.lB10TWCO005009@adara.cs.pdx.edu> <20071202172432.GE21078@cgi.jachomes.com> Message-ID: <20071205100412.GE23159@alien.local> Hi, On Sun, Dec 02, 2007 at 12:24:32PM -0500, Jay R. Ashworth wrote: > On Fri, Nov 30, 2007 at 04:29:32PM -0800, Barton C Massey wrote: > > > and about git updating a page under ikiwiki, seriously ;-0.... > > > (you might was well just put the website home directory under git) > > > > I have no idea what you mean by all this. I certainly have lots of > > web pages that are git-controlled outside of any wiki---what's the > > problem? Ikiwiki provides some convenience and wiki-style editing > > on top of this mechanism; this is a good thing, no? Or are you just > > referring to the fact that git+ikiwiki seems to hose itself fairly > > frequently and painfully, which I have to agree with... > > I think he was guffawing at the idea of far-offline wiki editing, in > general, and I'm not sure I disagree with him. Near-offline, maybe. If so, it was a stupid comment by a clueless person. It's not like most pages are updated so frequently as to make it even remotely likely that two people will work on the very same text passage simultaneously. More importantly, offline editing is just part of the story. It's really more about the user interface. The ability to do cd, ls -R (or tree), sed, vi `grep foo`, etc. (or Nautilus&Co. if you prefer); and git-log, git-show-branch, git-diff, git-merge, git-stash... Editing stuff using a web interface is just endless pain. IMHO being able to avoid that is such a crucial feature, that I wouldn't even consider any engine that doesn't allow for that. -antrik- From i.r.wezeman at hetnet.nl Wed Dec 5 05:42:03 2007 From: i.r.wezeman at hetnet.nl (i.r.wezeman at hetnet.nl) Date: Wed, 5 Dec 2007 14:42:03 +0100 Subject: xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' Message-ID: Today build drm and mesa without errors with branch master. When building branch master on xorg/xserver with --prefix=/G and --with-mesa-source=/SOURCE/mesa the next error: Making all in X make[3]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/X' /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I/G/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c -o xm_api.lo xm_api.c /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I/G/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c -o xm_buffer.lo xm_buffer.c gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I/G/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD -MP -MF .deps/xm_api.Tpo -c xm_api.c -fPIC -DPIC -o .libs/xm_api.o gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx -I../../../GL/include -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 -I/G/lib/dbus-1.0/include -I/G/include -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo -MD -MP -MF .deps/xm_buffer.Tpo -c xm_buffer.c -fPIC -DPIC -o libs/xm_buffer.o xm_buffer.c: In function 'alloc_back_buffer': xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' make[3]: *** [xm_buffer.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... xm_api.c: In function 'setup_8bit_hpcr': xm_api.c:877: error: too few arguments to function 'v->display->CreatePixmap' make[3]: *** [xm_api.lo] Error 1 make[3]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/X' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/SOURCE/xorg/xserver/GL' make: *** [all-recursive] Error 1 bash-3.1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin at mythtvthemes.co.uk Wed Dec 5 06:45:03 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Wed, 05 Dec 2007 14:45:03 +0000 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <1196833166.4698.184.camel@koto.keithp.com> References: <4755DE04.5070808@mythtvthemes.co.uk> <1196819744.4698.177.camel@koto.keithp.com> <34902.64.213.30.2.1196829815.squirrel@webmail.exetel.com.au> <1196833166.4698.184.camel@koto.keithp.com> Message-ID: <4756B96F.2010408@mythtvthemes.co.uk> Just a quick update.. I managed to build the driver myself & fiddle with encoder register settings. Setting the colour burst to happen a little earlier and for longer seems to have cleared up the flickering. It's still within acceptable specs and is noticably better. I'll post a patch up in a while. Regards, Justin PS - apologies to Keith for not replying to all in my previous replies. From brian.paul at tungstengraphics.com Wed Dec 5 07:01:44 2007 From: brian.paul at tungstengraphics.com (Brian Paul) Date: Wed, 05 Dec 2007 08:01:44 -0700 Subject: xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' In-Reply-To: References: Message-ID: <4756BD58.5010208@tungstengraphics.com> i.r.wezeman at hetnet.nl wrote: > Today build drm and mesa without errors with branch master. > > When building branch master on xorg/xserver with --prefix=/G and > --with-mesa-source=/SOURCE/mesa the next error: > > > Making all in X > make[3]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/X' > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi > -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl > -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD > -MP -MF .deps/xm_api.Tpo -c -o xm_api.lo xm_api.c > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi > -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl > -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo > -MD -MP -MF deps/xm_buffer.Tpo -c -o xm_buffer.lo xm_buffer.c > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include > -I../X -I../glapi -I../main -I../math -I../shader -I../swrast > -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx > -I../../../GL/include -I../../../hw/xfree86/os-support > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD > -MP -MF .deps/xm_api.Tpo -c xm_api.c -fPIC -DPIC -o libs/xm_api.o > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include > -I../X -I../glapi -I../main -I../math -I../shader -I../swrast > -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx > -I../../../GL/include -I../../../hw/xfree86/os-support > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo > -MD -MP -MF .deps/xm_buffer.Tpo -c xm_buffer.c -fPIC -DPIC -o > libs/xm_buffer.o > xm_buffer.c: In function 'alloc_back_buffer': > xm_buffer.c:226: error: too few arguments to function > 'b->xm_visual->display->CreatePixmap' > make[3]: *** [xm_buffer.lo] Error 1 > make[3]: *** Waiting for unfinished jobs.... > xm_api.c: In function 'setup_8bit_hpcr': > xm_api.c:877: error: too few arguments to function > 'v->display->CreatePixmap' > make[3]: *** [xm_api.lo] Error 1 > make[3]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/X' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/SOURCE/xorg/xserver/GL' > make: *** [all-recursive] Error 1 In Mesa/include/GL/xmesa_xf86.h, try adding this: #define CREATE_PIXMAP_USAGE_SCRATCH before line 172. Let me know what the compiler does. CREATE_PIXMAP_USAGE_SCRATCH _should_ be defined in scrnintstr.h if the CreatePixmap function needs a 5th argument. I don't know why this isn't working otherwise. -Brian From justin at mythtvthemes.co.uk Wed Dec 5 07:08:41 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Wed, 05 Dec 2007 15:08:41 +0000 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <1196819744.4698.177.camel@koto.keithp.com> References: <4755DE04.5070808@mythtvthemes.co.uk> <1196819744.4698.177.camel@koto.keithp.com> Message-ID: <4756BEF9.60804@mythtvthemes.co.uk> Patch attached, Seems ok but I've not tried it on my home TV yet. Justin -------------- next part -------------- A non-text attachment was scrubbed... Name: paltvoutpatch.diff Type: text/x-patch Size: 1043 bytes Desc: not available URL: From mattias.andersson5 at comhem.se Wed Dec 5 07:38:56 2007 From: mattias.andersson5 at comhem.se (Mattias Andersson) Date: Wed, 5 Dec 2007 16:38:56 +0100 (CET) Subject: build.sh stops with "not a git repository" and autogen error Message-ID: <8419385.24721196869136672.JavaMail.defaultUser@defaultHost> Hi all! This is my first mail on the list. I searched everywhere for the answer on why the build.sh stops on two places: luit and xconsole, both in the "app" directory. The script stops in luit/luit-1.0.2/_buld with a message: not a git repository error 128, error 1 Same error in the xconsole/xconsole-1.0.2/_build. Other error is that build scipt stops with error in app/xprop saying that "AC_CHECK_HEADERS_ONCE is not defined". (Line 38) And "try with a m4_..._". I use Fedora 5 with original X (7.0.0). Thanks /Mattias Andersson From florian.harmuth at googlemail.com Wed Dec 5 07:46:33 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Wed, 5 Dec 2007 16:46:33 +0100 Subject: Using XVideo extension? Message-ID: Hello all, i need to add client side scaling to the vncviewer. This should be possible with XVideos XvPutImage. And here is my problem -> the image informations are avaiable as RGB and not as YUV value. My Intel Video Card only provides a port with XvYUV as type (XvListImageFormats). Is it possible to convert the RGB Informations to YUV? Or did anyone know other scaling solutions under X (imlib is great but just loads pics from harddisk). Best Regards, flo -------------- next part -------------- An HTML attachment was scrubbed... URL: From timo.jyrinki at gmail.com Wed Dec 5 08:10:21 2007 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Wed, 5 Dec 2007 18:10:21 +0200 Subject: Website maintenance volunteers? In-Reply-To: <20071129154137.072e41cf.arthur.huillet@free.fr> References: <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> Message-ID: <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> 2007/11/29, Arthur Huillet : > But I'm unsure we need to change the wiki engine, it seems > that it would represent a lot of work for everybody involved, and we certainly want to avoid that. Yes, unless sure there are implementers who are able to do a complete porting of all information to the new system in a short time, it's better to fix the old system than to replace it with something completely new. The new systems often do not reach the level previously set until a very long time, as the migration paths usually involve loss of all kinds of (meta)information. Spam is not a huge problem with working automatic BadContent updating, provided enough users have DeletePage rights. But captcha could be welcome. If you stay in Moin, what should be done in any case is to do a custom theme file for MoinMoin - the default one is one of the ugliest around IMHO. Some examples are available at http://moinmoin.wikiwikiweb.de/MoinMoinScreenShots. https://wiki.edubuntu.org/Edubuntu is quite neat. I also like hiding of some or all controls depending on whether one is logged in or not, and adding some extra navigation links in the theme - see eg. http://www.vapaasuomi.fi/ and http://wiki.ubuntu-fi.org/UKK (I did Moin themes for those) - but it's more suitable for the more end-user oriented sites where majority of readers are just that, readers. Usually some elements like the "trail" are worth hiding in any case to remove clutter, IMO. Image usage problems diminish somewhat if ImageLink macro is made usable. Moin tweaking is easier than changing the whole system, but there should be someone to do that, too, so as always it comes down to which people are there that may do enough work. So changing the whole thing is definitely an option, too. -Timo (I can give the theme py files I've done as an example if needed, though there are others lying around, too) From peter.harris at hummingbird.com Wed Dec 5 08:10:45 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Wed, 05 Dec 2007 11:10:45 -0500 Subject: Using XVideo extension? In-Reply-To: References: Message-ID: <4756CD85.9000205@hummingbird.com> Florian Harmuth wrote: > Or did anyone know other scaling solutions under X (imlib is great but > just loads pics from harddisk). The Render extension will allow you to scale an image when you "composite" from one picture to another. (Pictures can be backed by Pixmaps or Windows). See XRenderSetPictureTransform. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From irwin at beluga.phys.uvic.ca Wed Dec 5 09:05:27 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 05 Dec 2007 09:05:27 -0800 (PST) Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071205115131.593289d8@sbs173> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> Message-ID: Harald Braumann said: > Just make sure to remove that [xorg] part again, when replying to the list. I'm one of those who don't want to have superfluous information in the subject. Sorry, such an attitude is just too far over the top for my tastes. Just to remind you we are supposed to be part of a _free_ software movement which fundamentally means any subject lines are allowed. If you are really that allergic to list-ids in subject lines, then here is a procmail recipe to remove them from this list traffic. :-) :0 fw * ^List-Id: Discuss issues related to the xorg tree |sed -e 's/^Subject:[ ]*[xorg]/Subject: /' Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From moseley at hank.org Wed Dec 5 09:09:38 2007 From: moseley at hank.org (Bill Moseley) Date: Wed, 5 Dec 2007 09:09:38 -0800 Subject: Slow xterm response Message-ID: <20071205170938.GA1006@hank.org> I've posted twice before without response, but it's very irritating to deal with on a daily basis. Every day I plug my Gutsy laptop into the lan and hit power. Then on my desktop I ssh into the laptop and start up a development web application. As soon as the laptop's screen goes blank my xterm sessions show latency. If I hold down a key and repeat a letter it goes along in fits and starts. Now, I do not notice any latency in accessing the web application on the laptop, but I think that would be much harder to see. So, I'm not sure if it's something related to just the xterm session or for all processes on the laptop. There's no jump in cpu usage when this happens so I don't think it's related to some process looping. I've got a script I use when it happens: XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor which gets rid of the latency. If I run it *before* the latency starts, like I just did, the first run make the latency show up: moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor [sudo] password for moseley: Monitor is On Monitor is Off moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor Monitor is Off Monitor is Off I suspect that's not much to go on, but if that was happing to you and driving you crazy what would you do to narrow down? Weird. X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Linux Ubuntu (xorg-server 2:1.3.0.0.dfsg-12ubuntu8) Current Operating System: Linux tiger 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 Build Date: 29 September 2007 -- Bill Moseley moseley at hank.org From ggm at pobox.com Wed Dec 5 09:13:49 2007 From: ggm at pobox.com (George Michaelson) Date: Wed, 5 Dec 2007 09:13:49 -0800 Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? In-Reply-To: <20071204105852.56a9eec6@asmtp.apnic.net> References: <20071204105852.56a9eec6@asmtp.apnic.net> Message-ID: <20071205091349.24dbd464@asmtp.apnic.net> I got clue. this problem is clearly a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=3113 however I was able to verify the patches in 3113 are in the code base I am seeing the problem in. I marked mine as duplicate, commented, and re-opened 3113. thanks to all clue-hitters. -George From reed at reedmedia.net Wed Dec 5 09:33:49 2007 From: reed at reedmedia.net (reed at reedmedia.net) Date: Wed, 5 Dec 2007 11:33:49 -0600 (CST) Subject: anyone maintaining monolithic 6.9? Message-ID: Is anyone maintaining a monolithic X.org? If not, I will close ticket 5799 soon. http://bugs.freedesktop.org/show_bug.cgi?id=5799 Jeremy C. Reed From andrew at digital-domain.net Wed Dec 5 06:32:49 2007 From: andrew at digital-domain.net (Andrew Clayton) Date: Wed, 5 Dec 2007 14:32:49 +0000 Subject: [ANNOUNCE] xf86-video-ati 6.7.196 In-Reply-To: References: <20071113152446.5de66f0e@zeus.pccl.info> <20071114154451.622fd168@zeus.pccl.info> Message-ID: <20071205143249.586faa4f@zeus.pccl.info> On Wed, 14 Nov 2007 10:46:30 -0500, Alex Deucher wrote: > On Nov 14, 2007 10:44 AM, Andrew Clayton wrote: > > On Wed, 14 Nov 2007 10:16:01 -0500, Alex Deucher wrote: > > > > > > > > We are not able to reliably do load detection on the tv dac as of > > > yet so the connection status is unknown. You can force the > > > output off by default in your config. See this page for more > > > info: http://www.intellinuxgraphics.com/dualhead.html > > > > Cheers, I'll take a look at that. > > > > > you can also force it off at runtime with: > > > xrandr --output DVI-0 --off > > > > Yeah, I did try that, but it doesn't seem to have any effect. xrandr > > still lists the DVI-0 as unknown connection. > > right. It still doesn't know the connection status, but the output > is off. OK, just tried the latest version from git (21ed435398e4a398dd8a0a5d7c1d4cc45e916332) And it's all working fine now, DVI-0 is detected as disconnected and no weird screen size stuff, e.g xscreensaver will use the whole screen without fiddling with xrandr first. $ xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1200 VGA-0 connected 1440x900+0+0 (normal left inverted right x axis y axis) 408mm x 255mm 1440x900 59.9*+ 1280x1024 75.0 59.9 1280x960 59.9 1152x864 74.8 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 DVI-0 disconnected (normal left inverted right x axis y axis) S-video disconnected (normal left inverted right x axis y axis) So something got fixed between .196 and now. Good work! Cheers, Andrew From adr3nald0s at gmail.com Wed Dec 5 10:04:50 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Wed, 5 Dec 2007 12:04:50 -0600 Subject: ATI VGA-0 Dual Head Problems Message-ID: <308083c30712051004t3f22b2b4qf8f261b1ccbf1a36@mail.gmail.com> I am trying to get xrandr working with xf86-driver-ati commit 21ed435. I have also tried 6.7.196 to no avail. xrandr detects VGA-0 and LVDS just fine: $ xrandr Screen 0: minimum 320 x 200, current 3520 x 1200, maximum 3520 x 1920 VGA-0 connected 1600x1200+1920+0 (normal left inverted right) 408mm x 306mm 1600x1200 60.0*+ 59.9 1280x1024 75.0 59.9 1280x960 59.9 1152x864 75.0 74.8 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 DVI-0 disconnected (normal left inverted right) LVDS connected 1920x1200+0+0 (normal left inverted right) 0mm x 0mm 1920x1200 60.0*+ 1024x768 60.0 800x600 60.3 640x480 59.9 S-video disconnected (normal left inverted right) I also have Monitor sections setup for each in my xorg.conf. But, no matter what I do, I cannot get anything to display on the external VGA-0 connection. This is on a laptop with R600 M24 video. TIA for any help. Confused From pekane52 at gmail.com Wed Dec 5 10:46:56 2007 From: pekane52 at gmail.com (Pat Kane) Date: Wed, 5 Dec 2007 12:46:56 -0600 Subject: Slow xterm response In-Reply-To: <20071205170938.GA1006@hank.org> References: <20071205170938.GA1006@hank.org> Message-ID: Does you laptops "cpu MHz" change when the screen blanks? What does "cat /proc/cpuinfo" show before and after the latency event? On Dec 5, 2007 11:09 AM, Bill Moseley wrote: > I've posted twice before without response, but it's very irritating to > deal with on a daily basis. > > Every day I plug my Gutsy laptop into the lan and hit power. > > Then on my desktop I ssh into the laptop and start up a development > web application. > > As soon as the laptop's screen goes blank my xterm sessions show > latency. If I hold down a key and repeat a letter it goes along in > fits and starts. > > Now, I do not notice any latency in accessing the web application on > the laptop, but I think that would be much harder to see. So, I'm not > sure if it's something related to just the xterm session or for all > processes on the laptop. There's no jump in cpu usage when this > happens so I don't think it's related to some process looping. > > I've got a script I use when it happens: > > XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > > which gets rid of the latency. > > If I run it *before* the latency starts, like I just did, the first > run make the latency show up: > > moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > [sudo] password for moseley: > Monitor is On > Monitor is Off > > > > > moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > Monitor is Off > Monitor is Off > > > > > I suspect that's not much to go on, but if that was happing to you and > driving you crazy what would you do to narrow down? > > Weird. > > > > X Window System Version 1.3.0 > Release Date: 19 April 2007 > X Protocol Version 11, Revision 0, Release 1.3 > Build Operating System: Linux Ubuntu (xorg-server 2:1.3.0.0.dfsg-12ubuntu8) > Current Operating System: Linux tiger 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 > Build Date: 29 September 2007 > > > > -- > Bill Moseley > moseley at hank.org > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From moseley at hank.org Wed Dec 5 10:55:55 2007 From: moseley at hank.org (Bill Moseley) Date: Wed, 5 Dec 2007 10:55:55 -0800 Subject: Slow xterm response In-Reply-To: References: <20071205170938.GA1006@hank.org> Message-ID: <20071205185555.GA3160@hank.org> On Wed, Dec 05, 2007 at 12:46:56PM -0600, Pat Kane wrote: > Does you laptops "cpu MHz" change when the screen blanks? > What does "cat /proc/cpuinfo" show before and after the latency > event? No difference. And again, when the screen first blanks by itself (which is not dpms sleep, but just screen blanking) is when the latency starts. I can "force" the latency by running my xset command *before* the screen blanks. Then the latency starts and if I run the xset command a second time it goes away. If I wait for it to blank on its own (which is what normally happens) then the latency starts and then I only need to run the xset command once to "fix" it. So, running fine (screen not blank yet): moseley at tiger:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping : 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3994.41 clflush size : 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping : 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3990.04 clflush size : 64 This triggers the latency (because the screen on the laptop isn't blank yet): moseley at tiger:~$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor [sudo] password for moseley: Monitor is On Monitor is Off Now latency shows up: moseley at tiger:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping : 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3994.41 clflush size : 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping : 6 cpu MHz : 1000.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3990.04 clflush size : 64 -- Bill Moseley moseley at hank.org From pekane52 at gmail.com Wed Dec 5 11:14:20 2007 From: pekane52 at gmail.com (Pat Kane) Date: Wed, 5 Dec 2007 13:14:20 -0600 Subject: Slow xterm response In-Reply-To: <20071205185555.GA3160@hank.org> References: <20071205170938.GA1006@hank.org> <20071205185555.GA3160@hank.org> Message-ID: My next WAG would be to add the "-dpms" and "-dumbSched" options to the X server. On Dec 5, 2007 12:55 PM, Bill Moseley wrote: > On Wed, Dec 05, 2007 at 12:46:56PM -0600, Pat Kane wrote: > > Does you laptops "cpu MHz" change when the screen blanks? > > What does "cat /proc/cpuinfo" show before and after the latency > > event? > > No difference. And again, when the screen first blanks by itself > (which is not dpms sleep, but just screen blanking) is when the > latency starts. I can "force" the latency by running my xset command > *before* the screen blanks. Then the latency starts and if I run the > xset command a second time it goes away. > > If I wait for it to blank on its own (which is what normally happens) > then the latency starts and then I only need to run the xset command > once to "fix" it. > > So, running fine (screen not blank yet): > > > moseley at tiger:~$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz > stepping : 6 > cpu MHz : 1000.000 > cache size : 4096 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm > bogomips : 3994.41 > clflush size : 64 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz > stepping : 6 > cpu MHz : 1000.000 > cache size : 4096 KB > physical id : 0 > siblings : 2 > core id : 1 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm > bogomips : 3990.04 > clflush size : 64 > > This triggers the latency (because the screen on the laptop isn't > blank yet): > > moseley at tiger:~$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > [sudo] password for moseley: > Monitor is On > Monitor is Off > > > Now latency shows up: > > moseley at tiger:~$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz > stepping : 6 > cpu MHz : 1000.000 > cache size : 4096 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm > bogomips : 3994.41 > clflush size : 64 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz > stepping : 6 > cpu MHz : 1000.000 > cache size : 4096 KB > physical id : 0 > siblings : 2 > core id : 1 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm > bogomips : 3990.04 > clflush size : 64 > > -- > Bill Moseley > moseley at hank.org > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From bart at cs.pdx.edu Wed Dec 5 11:22:04 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 05 Dec 2007 11:22:04 -0800 Subject: Slow xterm response In-Reply-To: Your message of "Wed, 05 Dec 2007 09:09:38 PST." <20071205170938.GA1006@hank.org> References: <20071205170938.GA1006@hank.org> Message-ID: <200712051922.lB5JM4Jg009069@wezen.cs.pdx.edu> Does it happen when the laptop is plugged in? If not, it could be a power-management thing throttling your laptop down. In any case, try turning all your ACPI power management stuff off and see if the problem persists. Do you have some intense screen saver running, or does the screen really "go blank"? (Had to ask.) Does it happen with a terminal other than xterm? Don't know what the answer would mean, but it would be useful information, and in any case if the answer is no you've got a workaround. What chipset does your laptop have? Bart In message <20071205170938.GA1006 at hank.org> you wrote: > I've posted twice before without response, but it's very irritating to > deal with on a daily basis. > > Every day I plug my Gutsy laptop into the lan and hit power. > > Then on my desktop I ssh into the laptop and start up a development > web application. > > As soon as the laptop's screen goes blank my xterm sessions show > latency. If I hold down a key and repeat a letter it goes along in > fits and starts. > > Now, I do not notice any latency in accessing the web application on > the laptop, but I think that would be much harder to see. So, I'm not > sure if it's something related to just the xterm session or for all > processes on the laptop. There's no jump in cpu usage when this > happens so I don't think it's related to some process looping. > > I've got a script I use when it happens: > > XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > > which gets rid of the latency. > > If I run it *before* the latency starts, like I just did, the first > run make the latency show up: > > moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > [sudo] password for moseley: > Monitor is On > Monitor is Off > > > > > moseley at tiger:~/cat_svn$ XAUTHORITY=/var/lib/gdm/:0.Xauth sudo /usr/bin/xset -q -display :0.0 dpms force off -q | grep Monitor > Monitor is Off > Monitor is Off > > > > > I suspect that's not much to go on, but if that was happing to you and > driving you crazy what would you do to narrow down? > > Weird. > > > > X Window System Version 1.3.0 > Release Date: 19 April 2007 > X Protocol Version 11, Revision 0, Release 1.3 > Build Operating System: Linux Ubuntu (xorg-server 2:1.3.0.0.dfsg-12ubuntu8) > Current Operating System: Linux tiger 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 > Build Date: 29 September 2007 > > > > -- > Bill Moseley > moseley at hank.org > > From bart at cs.pdx.edu Wed Dec 5 11:26:32 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 05 Dec 2007 11:26:32 -0800 Subject: anyone maintaining monolithic 6.9? In-Reply-To: Your message of "Wed, 05 Dec 2007 11:33:49 CST." References: Message-ID: <200712051926.lB5JQWYt009281@wezen.cs.pdx.edu> As far as I know, 6.9 is as dead as doornails. I don't know any reason to close the ticket, though; if someone wants to pick it up that would be fine, and in the meantime it's not hurting anything as far as I can figure. Bart In message you wrote: > Is anyone maintaining a monolithic X.org? > > If not, I will close ticket 5799 soon. > > http://bugs.freedesktop.org/show_bug.cgi?id=5799 > > Jeremy C. Reed > From jra at baylink.com Wed Dec 5 11:27:36 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 5 Dec 2007 14:27:36 -0500 Subject: Slow xterm response In-Reply-To: <200712051922.lB5JM4Jg009069@wezen.cs.pdx.edu> References: <20071205170938.GA1006@hank.org> <200712051922.lB5JM4Jg009069@wezen.cs.pdx.edu> Message-ID: <20071205192736.GA2290@cgi.jachomes.com> On Wed, Dec 05, 2007 at 11:22:04AM -0800, Barton C Massey wrote: > Does it happen when the laptop is plugged in? If not, it > could be a power-management thing throttling your laptop > down. In any case, try turning all your ACPI power management > stuff off and see if the problem persists. Alternatively, you might be getting interrupt storms; checking /proc/interrupts in a periodic manner in the background might tell you something as well. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From bart at cs.pdx.edu Wed Dec 5 11:36:54 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 05 Dec 2007 11:36:54 -0800 Subject: Website maintenance volunteers? In-Reply-To: Your message of "Wed, 05 Dec 2007 18:10:21 +0200." <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> References: <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> Message-ID: <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> In message <68da43e00712050810o5550d379gaa281f10fcb40252 at mail.gmail.com> you wrote: > 2007/11/29, Arthur Huillet : > > But I'm unsure we need to change the wiki engine, it > > seems that it would represent a lot of work for > > everybody involved, and we certainly want to avoid that. > > Yes, unless sure there are implementers who are able to do a complete > porting of all information to the new system in a short time, it's > better to fix the old system than to replace it with something > completely new. The new systems often do not reach the level > previously set until a very long time, as the migration paths usually > involve loss of all kinds of (meta)information. Actually, our MoinMoin->ikiwiki tool is quite good; it was developed for a fairly large and uncontrolled wiki (http://psas.pdx.edu) which had previously been a TWiki, so it was full of interesting test cases. That said, I agree that there will be various fixups afterward. > Spam is not a huge problem with working automatic BadContent updating, > provided enough users have DeletePage rights. But captcha could be > welcome. I'm not understanding people's spam concerns. As far as I know, only X.Org members are currently allowed to edit the wiki. Am I wrong here? > If you stay in Moin, what should be done in any case is to do a custom > theme file for MoinMoin - the default one is one of the ugliest around > IMHO. Some examples are available at > http://moinmoin.wikiwikiweb.de/MoinMoinScreenShots. > https://wiki.edubuntu.org/Edubuntu is quite neat. I also like hiding > of some or all controls depending on whether one is logged in or not, > and adding some extra navigation links in the theme - see eg. > http://www.vapaasuomi.fi/ and http://wiki.ubuntu-fi.org/UKK (I did > Moin themes for those) - but it's more suitable for the more end-user > oriented sites where majority of readers are just that, readers. > Usually some elements like the "trail" are worth hiding in any case to > remove clutter, IMO. If someone wanted to work on a custom MoinMoin theme based on some better existing theme, it would potentially deal with some of the usability problems we've seen. I don't have the energy to do it, though. > Image usage problems diminish somewhat if ImageLink macro > is made usable. That would be a requirement. > Moin tweaking is easier than changing the whole system, but there > should be someone to do that, too, so as always it comes down to which > people are there that may do enough work. So changing the whole thing > is definitely an option, too. > > -Timo (I can give the theme py files I've done as an example if > needed, though there are others lying around, too) Thanks much for your comments! The big questions in my mind are: whether the git-nature of ikiwiki is a big enough win to justify the work of a conversion; in any case whether upgrading and properly theming the MoinMoin is less work than moving to ikiwiki and properly theming that; whether there are other ikiwiki usability issues that would make it less-loved than MoinMoin (we have no easy way to go *back*, currently). Knowledgable opinions on these issues are highly welcome---I need to start moving on this stuff pronto. Bart From alan.coopersmith at sun.com Wed Dec 5 12:35:48 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Wed, 05 Dec 2007 12:35:48 -0800 Subject: Website maintenance volunteers? In-Reply-To: <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> References: <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> Message-ID: <47570BA4.8020504@sun.com> Barton C Massey wrote: > I'm not understanding people's spam concerns. As far as I > know, only X.Org members are currently allowed to edit the > wiki. Am I wrong here? Yes - anyone who fills in the account form on the wiki can edit it, and spammers have done so repeatedly. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From cloos+pdx-xorg at jhcloos.com Wed Dec 5 12:43:13 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Wed, 05 Dec 2007 20:43:13 +0000 Subject: Slow xterm response In-Reply-To: <20071205170938.GA1006@hank.org> (Bill Moseley's message of "Wed, 5 Dec 2007 09:09:38 -0800") References: <20071205170938.GA1006@hank.org> Message-ID: >>>>> "Bill" == Bill Moseley writes: Bill> ... on my desktop I ssh into the laptop and start up a development Bill> web application. Bill> As soon as the laptop's screen goes blank my xterm sessions show Bill> latency. If I hold down a key and repeat a letter it goes along in Bill> fits and starts. You wrote elsewhere in the thread that the blanking isn't caused by X dpms but [I presume] by the laptop's firmware and/or kernel. You also wrote that the MHz rating as exported in /proc/cpuinfo remains constant, so the CPU's P state isn't changing. You may be, however, seeing a problem with C states. If you're kernel is so configured, /proc/acpi/processor/CPU0/performance will show the P states and /proc/acpi/processor/CPU0/power the C states. Check whether those change when the screen blanks. Is there any change in the rate of interupts when the latency occurs? Try triggering the latency while running vmstat(1) on the laptop. There was a post in the last few days on linux-kernel showing a bug in C state handling, where the poster's laptop would fall into a cycle of continuously trying to switch to a lower-wattage C state just to be immediately woken back up. You may be seeing something like that. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From justin at mythtvthemes.co.uk Wed Dec 5 13:10:18 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Wed, 05 Dec 2007 21:10:18 +0000 Subject: Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output In-Reply-To: <1196819744.4698.177.camel@koto.keithp.com> References: <4755DE04.5070808@mythtvthemes.co.uk> <1196819744.4698.177.camel@koto.keithp.com> Message-ID: <475713BA.2090103@mythtvthemes.co.uk> Keith Packard wrote: > On Tue, 2007-12-04 at 23:08 +0000, Justin Hornsby wrote: > >> Hi folks. >> >> I'm experiencing a slight problem with svideo out using the 'intel' >> driver version 2.1. >> >> I eventually managed to find out how to use xrandr to set the TV >> standard to PAL and how to get the picture nicely overscanned with the >> margin setting options of xrandr but... >> >> I've noticed that the svideo connection on my Aopen motherboard is >> flickering slightly near the top of the screen. Turning the colour >> control on the TV down makes the problem go away which seems to indicate >> an issue with the chroma signal on the svideo port. I quickly hacked a >> spare svideo cable up a little and found (by connecting the Y output to >> a composite input on the TV) that the chroma signal is also present on >> the Y pin. It's my understanding that for svideo, only luminance should >> be present. Depending on how the TV treats svideo internally, having >> chrominance on Y & C could cause problems. >> > > If you hook only the Y pin up, the encoder will be configured for > composite video; it automatically detects the kind of cable purely based > on which wires are connected. It shouldn't change after you've turned it > on though, so hooking it up to svideo, starting the output, then > switching should keep it in svideo mode. > > >> I don't know anything about the TV encoder used on this board (yet) but >> I have access to video test gear at work where I plan to have a real >> good look at the signals coming out of the svideo port. We also have >> good monitors which I know for sure don't do any quick & dirty tricks >> with Y&C signals so if the issue is one of 'beating' of the 'Y chroma' >> and C signals it should look nice & clean on there. >> >> Are there any quick things I can try? It seems (from a quick look in >> the driver code) that xrandr supports only TV_FORMAT & margin >> adjustments for the TV encoder. All the timing values look sane to me >> but as I've already said I plan to examine the signals very closely at work. >> > > Oh, cool! I looked at getting some TV test equipment to figure out > whether I was generating legal signals, but couldn't really justify the > price. > > There are a million values you can frob to play with the video signals, > but most of them are not exposed through the protocol. Check out > i830_tv.c and i810_reg.h which documents the relevant registers > reasonably completely. In particular, using one of the test patterns may > help isolate the particular issues you're seeing with the image. > > Let me know if you have specific signal problems and I'll read through > the documentation to see what I can figure out. > > Right. I tested the system as soon as I could when I got home and the flickering was still there. Much head scratching ensued but then I found a doc about the specifics of PAL & it got me wondering... Anyway the fix (my my TVs at least) is as follows: change nbr_end to 288 from 286 in i830_tv.c . The patch I emailed previously can be disregarded. Regards, Justin From daniel at fooishbar.org Wed Dec 5 10:10:40 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 5 Dec 2007 18:10:40 +0000 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> Message-ID: <20071205181040.GC2177@fooishbar.org> On Wed, Dec 05, 2007 at 09:05:27AM -0800, Alan W. Irwin wrote: > Sorry, such an attitude is just too far over the top for my tastes. Just to > remind you we are supposed to be part of a _free_ software movement which > fundamentally means any subject lines are allowed. This is complete bollocks and has _nothing_ to do with _anything_. Even if we accept your argument, then it also means that we're free to have subject lines without [xorg] in it. Daniel, finding this discussion incredible (in the Victorian sense) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Wed Dec 5 09:27:54 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 5 Dec 2007 17:27:54 +0000 Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? In-Reply-To: <20071204135020.5186600f@asmtp.apnic.net> References: <20071204105852.56a9eec6@asmtp.apnic.net> <20071204135020.5186600f@asmtp.apnic.net> Message-ID: <20071205172754.GB2177@fooishbar.org> On Tue, Dec 04, 2007 at 01:50:20PM -0800, George Michaelson wrote: > I have just unpacked 1.4, and I have git head state, and I must be doing > something wrong: I cannot find the patch that is attached > to the above bug as being applied. neither by code looking, nor GIT logs. > > (thats what worries me. I did check git-log, and I cannot find the log of > the applied patch that Eric and co say they applied, and back-ported to > 1.4) > > the current state of hw/xfree86/common/xf86Xinput.c does not have any > instances of pow() or float() and is substantially different to the one > that patch appears to have been applied to. in the 1.3.99 and the 1.4 I > can fetch. The code in question has moved to dix/getevents.c. It's very hard to say what's going wrong without some proper debug logs. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ggm at pobox.com Wed Dec 5 14:39:19 2007 From: ggm at pobox.com (George Michaelson) Date: Wed, 5 Dec 2007 14:39:19 -0800 Subject: can I beg for some eyeballs on a netbsd wscons/XInput mouse problem? In-Reply-To: <20071205172754.GB2177@fooishbar.org> References: <20071204105852.56a9eec6@asmtp.apnic.net> <20071204135020.5186600f@asmtp.apnic.net> <20071205172754.GB2177@fooishbar.org> Message-ID: <20071205143919.197afb04@asmtp.apnic.net> On Wed, 5 Dec 2007 17:27:54 +0000 Daniel Stone wrote: > > The code in question has moved to dix/getevents.c. yes, I found it. and the matching patch to os-support/bsd/bsd_mouse.c I confirm both are in the codebase I have run, and I still see the problem. > > It's very hard to say what's going wrong without some proper debug logs. can you advise how to make these, for mouse events this low in the code? I looked and didn't see any guidance on how to enable the kind of logging you might find useful. If you can help me to make it, I would *love* to make it, so you can do trace on whats happening. If its just the runtime mouse debug state I can turn on live, I think I'm ready.. If I have to re-compile, I need to know at what level in code I do that. (which may require I understand how to pass it down in NetBSD pkgsrc but I can get there) I understand that most Xorg bugs have the XF86Config and the like as attachment. I held off on that, because I didn't see eyeballs on the problem, and given 3113 was closed [fixed] I can understand that. But, I believe it isn't fixed, and if I can help resolve that so much the better. cheers -George > > Cheers, > Daniel From libv at skynet.be Wed Dec 5 15:41:14 2007 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 6 Dec 2007 00:41:14 +0100 Subject: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071204003656.GE6534@fooishbar.org> References: <200712032130.34559.arekm@maven.pl> <20071203210600.GE25785@cgi.jachomes.com> <20071203211933.GA26078@skynet.be> <20071204003656.GE6534@fooishbar.org> Message-ID: <20071205234114.GB3544@skynet.be> On Tue, Dec 04, 2007 at 12:36:56AM +0000, Daniel Stone wrote: > On Mon, Dec 03, 2007 at 10:19:33PM +0100, Luc Verhaegen wrote: > > This would make > > me personally, with my inbox == TODO list kind of mail handling, much > > happier. > > Renaming all the files to hw_xfree86_common_xf86Xinput.c and similar > would be very convenient for me, because I don't use directories. > > IOW, c'est la vie. > > Cheers, > Daniel Don't we place xf86 in front of most files living in hw/xfree86/, and don't we also place xf86 in front of most global symbols in there, and even in front of a lot of static ones? Don't we have enough namespace issues already? I do think the xf86 analogy is slightly more fitting argument for this situation here. Luc Verhaegen. SUSE/Novell X Driver Developer. From libv at skynet.be Wed Dec 5 15:53:27 2007 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 6 Dec 2007 00:53:27 +0100 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071205181040.GC2177@fooishbar.org> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> <20071205181040.GC2177@fooishbar.org> Message-ID: <20071205235327.GC3544@skynet.be> On Wed, Dec 05, 2007 at 06:10:40PM +0000, Daniel Stone wrote: > On Wed, Dec 05, 2007 at 09:05:27AM -0800, Alan W. Irwin wrote: > > Sorry, such an attitude is just too far over the top for my tastes. Just to > > remind you we are supposed to be part of a _free_ software movement which > > fundamentally means any subject lines are allowed. > > This is complete bollocks and has _nothing_ to do with _anything_. Even > if we accept your argument, then it also means that we're free to have > subject lines without [xorg] in it. > > Daniel, finding this discussion incredible (in the Victorian sense) Well, I for instance don't see how people can be so fervently against having [xorg] in front of the subject. I'm sure that those who do not automatically filter are much more inconvenienced than those who do filter. I'm sure that those who do filter usually just cannot be bothered about this subject at all. My guess is that the same logic does apply when considering video drivers: "Buy a new videocard, like everyone else, or shut up." This of course does gloss over the fact that "everyone else" includes those that were already forced to buy from the big three remaining players with the same reasoning. There are a few much more inflamatory analogies along the same line, but it's probably best to not bring those up here and now. Luc Verhaegen. SUSE/Novell X Driver Developer. From moseley at hank.org Wed Dec 5 17:36:40 2007 From: moseley at hank.org (Bill Moseley) Date: Wed, 5 Dec 2007 17:36:40 -0800 Subject: Slow xterm response In-Reply-To: References: <20071205170938.GA1006@hank.org> Message-ID: <20071206013640.GC4320@hank.org> On Wed, Dec 05, 2007 at 08:43:13PM +0000, James Cloos wrote: > >>>>> "Bill" == Bill Moseley writes: > > Bill> ... on my desktop I ssh into the laptop and start up a development > Bill> web application. > > Bill> As soon as the laptop's screen goes blank my xterm sessions show > Bill> latency. If I hold down a key and repeat a letter it goes along in > Bill> fits and starts. > > You wrote elsewhere in the thread that the blanking isn't caused by X > dpms but [I presume] by the laptop's firmware and/or kernel. Well, I'm not so sure. There's dpms which disables the display but there's also the standard screen blanking that happens at 10 minutes. I just assumed that was X clearing the screen (the LCD backlight is still on). That's when the latency starts. Then if I force the display off after the screen is blanked the latency goes away. If I change the timeout to 5 minutes then the latency starts at 5 minutes. So, it seems to be triggered by blanking. What I find odd is if the screen is *not* blanked then I have to run "dpms force off" twice. The first time *start* the latency. Odd. BTW -- yes the laptop is plugged in. > You also wrote that the MHz rating as exported in /proc/cpuinfo remains > constant, so the CPU's P state isn't changing. You may be, however, > seeing a problem with C states. If you're kernel is so configured, > /proc/acpi/processor/CPU0/performance will show the P states and > /proc/acpi/processor/CPU0/power the C states. Check whether those > change when the screen blanks. /proc/acpi/processor/CPU0/performance: No such file or directory > Is there any change in the rate of interupts when the latency occurs? > Try triggering the latency while running vmstat(1) on the laptop. I see no change in vmstat when the latency starts. Well, maybe a little. This starts off with latency showing and then I ran xset dpms force off about where I added the line break. Dose not seem significant. moseley at tiger:~$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 1749552 14044 176404 0 0 23 8 69 49 0 0 99 1 0 0 0 1749536 14044 176404 0 0 0 0 38 38 0 0 100 0 0 0 0 1749544 14060 176400 0 0 0 260 61 110 0 0 100 0 0 0 0 1749544 14060 176404 0 0 0 0 35 38 0 0 100 0 0 0 0 1749544 14060 176404 0 0 0 0 78 126 0 0 100 0 0 0 0 1749536 14060 176404 0 0 0 0 46 62 0 0 100 0 0 0 0 1749544 14060 176404 0 0 0 0 58 101 0 0 100 0 1 0 0 1749544 14060 176404 0 0 0 0 30 31 0 0 100 0 0 0 0 1749544 14060 176404 0 0 0 0 61 102 0 0 100 0 2 0 0 1749544 14060 176404 0 0 0 0 35 37 0 0 100 0 0 0 0 1749620 14068 176396 0 0 0 16 151 369 1 0 99 0 0 0 0 1749660 14068 176404 0 0 0 0 125 35 0 0 100 0 0 0 0 1749660 14068 176404 0 0 0 0 157 103 0 0 100 0 0 0 0 1749668 14068 176404 0 0 0 0 128 41 0 0 100 0 0 0 0 1749668 14068 176404 0 0 0 0 156 97 0 0 100 0 0 0 0 1749668 14068 176404 0 0 0 0 131 38 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 196 158 114 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 132 39 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 157 107 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 138 39 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 159 99 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 130 38 0 0 100 0 1 0 0 1749668 14084 176404 0 0 0 0 158 99 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 130 42 0 0 100 0 0 0 0 1749668 14084 176404 0 0 0 0 165 111 0 0 100 0 0 0 0 1749660 14084 176404 0 0 0 0 135 37 0 0 100 0 -- Bill Moseley moseley at hank.org From daniel at fooishbar.org Wed Dec 5 18:19:18 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 6 Dec 2007 02:19:18 +0000 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071205235327.GC3544@skynet.be> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> <20071205181040.GC2177@fooishbar.org> <20071205235327.GC3544@skynet.be> Message-ID: <20071206021918.GE3614@fooishbar.org> On Thu, Dec 06, 2007 at 12:53:27AM +0100, Luc Verhaegen wrote: > My guess is that the same logic does apply when considering video > drivers: "Buy a new videocard, like everyone else, or shut up." > > This of course does gloss over the fact that "everyone else" includes > those that were already forced to buy from the big three remaining > players with the same reasoning. If ever anyone needed evidence that this discussion was now utterly pointless -- here it is. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From cloos+pdx-xorg at jhcloos.com Wed Dec 5 18:26:47 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Thu, 06 Dec 2007 02:26:47 +0000 Subject: Slow xterm response In-Reply-To: <20071206013640.GC4320@hank.org> (Bill Moseley's message of "Wed, 5 Dec 2007 17:36:40 -0800") References: <20071205170938.GA1006@hank.org> <20071206013640.GC4320@hank.org> Message-ID: >>>>> "Bill" == Bill Moseley writes: Bill> There's dpms which disables the display but Bill> there's also the standard screen blanking that happens at 10 minutes. Bill> I just assumed that was X clearing the screen (the LCD backlight is Bill> still on). Woops. Looks like I got that part backwards! Bill> That's when the latency starts. Then if I force the display off after Bill> the screen is blanked the latency goes away. OK. I must've read the first post too quickly. That said: Bill> /proc/acpi/processor/CPU0/performance: No such file or directory What is under /sys/devices/system/cpu/? There might be useful info there, too. Bill> I see no change in vmstat when the latency starts. Bill> Well, maybe a little. That listing shows about an extra hundred or so INTs per second. Periodic cat(1)s of /proc/interupts will show what is generating those extras. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos+pdx-xorg at jhcloos.com Wed Dec 5 18:37:35 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Thu, 06 Dec 2007 02:37:35 +0000 Subject: Best manual-to-automatic ChangeLog commit? Message-ID: Which tree has the best commit to look at for the optimal manual to automated ChangeLog conversion? The first two I tried had further relevant commits. Is the one from, eg, xdpyinfo the exact model to follow? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From daniel at fooishbar.org Wed Dec 5 18:44:42 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 6 Dec 2007 02:44:42 +0000 Subject: Best manual-to-automatic ChangeLog commit? In-Reply-To: References: Message-ID: <20071206024442.GF3614@fooishbar.org> On Thu, Dec 06, 2007 at 02:37:35AM +0000, James Cloos wrote: > Which tree has the best commit to look at for the optimal manual > to automated ChangeLog conversion? > > The first two I tried had further relevant commits. > > Is the one from, eg, xdpyinfo the exact model to follow? Just take the Makefile.am hook from xserver. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dkasak at nusconsulting.com.au Wed Dec 5 19:20:41 2007 From: dkasak at nusconsulting.com.au (Daniel Kasak) Date: Thu, 06 Dec 2007 14:20:41 +1100 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071205235327.GC3544@skynet.be> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> <20071205181040.GC2177@fooishbar.org> <20071205235327.GC3544@skynet.be> Message-ID: <1196911241.6685.32.camel@dkasak.nusconsulting.com.au> On Thu, 2007-12-06 at 00:53 +0100, Luc Verhaegen wrote: > Well, I for instance don't see how people can be so fervently against > having [xorg] in front of the subject. Here's the rub: 1) There is an established way of dealing with mail from mailing lists. It involves adding a header to the email, with a description of the mailing list in THERE. 2) The technology already exists, and is very much in use, to perform filtering based on mailing list headers. 3) I haven't heard *one* coherent argument why this is inadequate in any way, or inferior to any other hackish, half-arsed 'solutions' such as polluting the subject line ... other than of course, people who simply insist on performing filtering manually. > I'm sure that those who do not automatically filter are much more > inconvenienced than those who do filter. Oh, I'm 100% sure of this fact. But the point is, that it's their own stupid fault for going off on some "I WANT TO DO IT MYSELF" crusade. If you want to buck the trend, then yes, you'll make more work for yourself. You don't buck the trend and then demand that everyone else have to accommodate your newly created needs. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: dkasak at nusconsulting.com.au website: http://www.nusconsulting.com.au From daniel at fooishbar.org Wed Dec 5 10:10:58 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 5 Dec 2007 18:10:58 +0000 Subject: anyone maintaining monolithic 6.9? In-Reply-To: References: Message-ID: <20071205181058.GD2177@fooishbar.org> On Wed, Dec 05, 2007 at 11:33:49AM -0600, reed at reedmedia.net wrote: > Is anyone maintaining a monolithic X.org? Nope. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From moseley at hank.org Wed Dec 5 19:40:43 2007 From: moseley at hank.org (Bill Moseley) Date: Wed, 5 Dec 2007 19:40:43 -0800 Subject: Slow xterm response In-Reply-To: References: <20071205170938.GA1006@hank.org> <20071206013640.GC4320@hank.org> Message-ID: <20071206034042.GA11241@hank.org> On Thu, Dec 06, 2007 at 02:26:47AM +0000, James Cloos wrote: Ok, I don't think this is related to X, now. Although X may provide a solution. I assumed it was X because it always happens when the screen blanks either at the gdm login screen or when logged into my window manager. But, I just did the obvious and removed gdm and rebooted. I ssh'ed in and I *am* seeing the latency. I don't see the latency on the laptop (console). So, now I'm really baffled. Seems running X maybe *disables* something that gets re-enabled when the screen is blanked??? Sure enough: if I "startx" the latency in the ssh terminal goes away. Exiting X and it comes back. I ran strace on both the bash and sshd processes on the laptop but nothing interesting there. I think I need a drink. > What is under /sys/devices/system/cpu/? There might be useful info > there, too. See below. > Bill> Well, maybe a little. > > That listing shows about an extra hundred or so INTs per second. > > Periodic cat(1)s of /proc/interupts will show what is generating those > extras. I'm not seeing anything very significant. Odd that all the interrupts are on CPU0. I've been running this over and over and nothing jumps out when the latency starts. moseley at tiger:~$ cat /proc/interrupts CPU0 CPU1 0: 248647 1 IO-APIC-edge timer 1: 10 0 IO-APIC-edge i8042 8: 7 0 IO-APIC-edge rtc 9: 6655 0 IO-APIC-fasteoi acpi 12: 7492 0 IO-APIC-edge i8042 14: 103254 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 490320 0 IO-APIC-fasteoi uhci_hcd:usb1, ahci, yenta, eth0, fglrx 21: 101767 0 IO-APIC-fasteoi uhci_hcd:usb2, wifi0, HDA Intel 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 23: 56 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb5 NMI: 0 0 LOC: 6174 72575 ERR: 0 MIS: 0 With latency: moseley at tiger:~$ cat /proc/interrupts CPU0 CPU1 0: 249063 1 IO-APIC-edge timer 1: 10 0 IO-APIC-edge i8042 8: 7 0 IO-APIC-edge rtc 9: 6655 0 IO-APIC-fasteoi acpi 12: 7492 0 IO-APIC-edge i8042 14: 103342 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 490872 0 IO-APIC-fasteoi uhci_hcd:usb1, ahci, yenta, eth0, fglrx 21: 101898 0 IO-APIC-fasteoi uhci_hcd:usb2, wifi0, HDA Intel 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 23: 56 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb5 NMI: 0 0 LOC: 6264 72746 ERR: 0 MIS: 0 moseley at tiger:~$ find /sys/devices/system/cpu/ /sys/devices/system/cpu/ /sys/devices/system/cpu/cpu1 /sys/devices/system/cpu/cpu1/cpufreq /sys/devices/system/cpu/cpu1/topology /sys/devices/system/cpu/cpu1/topology/core_siblings /sys/devices/system/cpu/cpu1/topology/thread_siblings /sys/devices/system/cpu/cpu1/topology/core_id /sys/devices/system/cpu/cpu1/topology/physical_package_id /sys/devices/system/cpu/cpu1/cache /sys/devices/system/cpu/cpu1/cache/index2 /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map /sys/devices/system/cpu/cpu1/cache/index2/size /sys/devices/system/cpu/cpu1/cache/index2/number_of_sets /sys/devices/system/cpu/cpu1/cache/index2/ways_of_associativity /sys/devices/system/cpu/cpu1/cache/index2/physical_line_partition /sys/devices/system/cpu/cpu1/cache/index2/coherency_line_size /sys/devices/system/cpu/cpu1/cache/index2/level /sys/devices/system/cpu/cpu1/cache/index2/type /sys/devices/system/cpu/cpu1/cache/index1 /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map /sys/devices/system/cpu/cpu1/cache/index1/size /sys/devices/system/cpu/cpu1/cache/index1/number_of_sets /sys/devices/system/cpu/cpu1/cache/index1/ways_of_associativity /sys/devices/system/cpu/cpu1/cache/index1/physical_line_partition /sys/devices/system/cpu/cpu1/cache/index1/coherency_line_size /sys/devices/system/cpu/cpu1/cache/index1/level /sys/devices/system/cpu/cpu1/cache/index1/type /sys/devices/system/cpu/cpu1/cache/index0 /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map /sys/devices/system/cpu/cpu1/cache/index0/size /sys/devices/system/cpu/cpu1/cache/index0/number_of_sets /sys/devices/system/cpu/cpu1/cache/index0/ways_of_associativity /sys/devices/system/cpu/cpu1/cache/index0/physical_line_partition /sys/devices/system/cpu/cpu1/cache/index0/coherency_line_size /sys/devices/system/cpu/cpu1/cache/index0/level /sys/devices/system/cpu/cpu1/cache/index0/type /sys/devices/system/cpu/cpu1/crash_notes /sys/devices/system/cpu/cpu1/online /sys/devices/system/cpu/cpu0 /sys/devices/system/cpu/cpu0/cpufreq /sys/devices/system/cpu/cpu0/cpufreq/ondemand /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max /sys/devices/system/cpu/cpu0/cpufreq/stats /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state /sys/devices/system/cpu/cpu0/cpufreq/stats/total_trans /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq /sys/devices/system/cpu/cpu0/topology /sys/devices/system/cpu/cpu0/topology/core_siblings /sys/devices/system/cpu/cpu0/topology/thread_siblings /sys/devices/system/cpu/cpu0/topology/core_id /sys/devices/system/cpu/cpu0/topology/physical_package_id /sys/devices/system/cpu/cpu0/cache /sys/devices/system/cpu/cpu0/cache/index2 /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map /sys/devices/system/cpu/cpu0/cache/index2/size /sys/devices/system/cpu/cpu0/cache/index2/number_of_sets /sys/devices/system/cpu/cpu0/cache/index2/ways_of_associativity /sys/devices/system/cpu/cpu0/cache/index2/physical_line_partition /sys/devices/system/cpu/cpu0/cache/index2/coherency_line_size /sys/devices/system/cpu/cpu0/cache/index2/level /sys/devices/system/cpu/cpu0/cache/index2/type /sys/devices/system/cpu/cpu0/cache/index1 /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map /sys/devices/system/cpu/cpu0/cache/index1/size /sys/devices/system/cpu/cpu0/cache/index1/number_of_sets /sys/devices/system/cpu/cpu0/cache/index1/ways_of_associativity /sys/devices/system/cpu/cpu0/cache/index1/physical_line_partition /sys/devices/system/cpu/cpu0/cache/index1/coherency_line_size /sys/devices/system/cpu/cpu0/cache/index1/level /sys/devices/system/cpu/cpu0/cache/index1/type /sys/devices/system/cpu/cpu0/cache/index0 /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map /sys/devices/system/cpu/cpu0/cache/index0/size /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets /sys/devices/system/cpu/cpu0/cache/index0/ways_of_associativity /sys/devices/system/cpu/cpu0/cache/index0/physical_line_partition /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size /sys/devices/system/cpu/cpu0/cache/index0/level /sys/devices/system/cpu/cpu0/cache/index0/type /sys/devices/system/cpu/cpu0/crash_notes /sys/devices/system/cpu/sched_mc_power_savings -- Bill Moseley moseley at hank.org From alexdeucher at gmail.com Wed Dec 5 20:12:58 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Wed, 5 Dec 2007 23:12:58 -0500 Subject: ATI VGA-0 Dual Head Problems In-Reply-To: <308083c30712051004t3f22b2b4qf8f261b1ccbf1a36@mail.gmail.com> References: <308083c30712051004t3f22b2b4qf8f261b1ccbf1a36@mail.gmail.com> Message-ID: On Dec 5, 2007 1:04 PM, Adr3nal D0S wrote: > I am trying to get xrandr working with xf86-driver-ati commit 21ed435. > I have also tried 6.7.196 to no avail. > > xrandr detects VGA-0 and LVDS just fine: > > $ xrandr > Screen 0: minimum 320 x 200, current 3520 x 1200, maximum 3520 x 1920 > VGA-0 connected 1600x1200+1920+0 (normal left inverted right) 408mm x 306mm > 1600x1200 60.0*+ 59.9 > 1280x1024 75.0 59.9 > 1280x960 59.9 > 1152x864 75.0 74.8 > 1024x768 75.1 70.1 60.0 > 832x624 74.6 > 800x600 72.2 75.0 60.3 56.2 > 640x480 75.0 72.8 66.7 60.0 > 720x400 70.1 > DVI-0 disconnected (normal left inverted right) > LVDS connected 1920x1200+0+0 (normal left inverted right) 0mm x 0mm > 1920x1200 60.0*+ > 1024x768 60.0 > 800x600 60.3 > 640x480 59.9 > S-video disconnected (normal left inverted right) > > I also have Monitor sections setup for each in my xorg.conf. But, no > matter what I do, I cannot get anything to display on the external > VGA-0 connection. This is on a laptop with R600 M24 video. We are going to need at least your log and config to sort this out. Also, it's unclear what chip you have. Please file a bug (https://bugs.freedesktop.org) and explain the situation and attach your xorg log and config. Alex From daniel at fooishbar.org Wed Dec 5 11:24:24 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 5 Dec 2007 19:24:24 +0000 Subject: New input hotness not happening for 1.5 Message-ID: <20071205192424.GA3614@fooishbar.org> Hi, Despite putting in the XDS2007 notes that input transformation, XKB 2 and Xi 2 would happen for 1.5, they just aren't going to, to be honest. Doing these sensibly requires some fairly sweeping changes to the way we _process_ events (input-hotplug was all about how we generate them) that also requires sorting out the interactions with MPX, particularly the grab bits, which are going to be tough. That and I badly need a break. I'll try to get them done for 1.6; if 1.5 branches off in Feb, then that means I'll just always be working off master from when I start anyway. Sorry about this. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From km at mathcs.emory.edu Wed Dec 5 21:47:15 2007 From: km at mathcs.emory.edu (Ken Mandelberg) Date: Thu, 06 Dec 2007 00:47:15 -0500 Subject: GLSL on Mesa / Intel 915 Message-ID: <47578CE3.2060805@mathcs.emory.edu> Is there any support for GLSL on Mesa 7.0.1 running against the Intel driver for the i915GM? Naively I tried a sample program and get "user called a no-op dispatch function". From florian.harmuth at googlemail.com Wed Dec 5 22:58:16 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Thu, 6 Dec 2007 07:58:16 +0100 Subject: Using XVideo extension? In-Reply-To: <4756CD28.6070206@hummingbird.com> References: <4756CD28.6070206@hummingbird.com> Message-ID: Hello, thx for your answer -> how to find a documentation about the XRender lib/api? Are there any new books about programming under X? ( newer as 1993...) Best Regards, flo 2007/12/5, Peter Harris < peter.harris at hummingbird.com>: > > Florian Harmuth wrote: > > Or did anyone know other scaling solutions under X (imlib is great but > > just loads pics from harddisk). > > The Render extension will allow you to scale an image when you > "composite" from one picture to another. (Pictures can be backed by > Pixmaps or Windows). > > See XRenderSetPictureTransform. > > Peter Harris > > -- > Hummingbird Connectivity - A Division of Open Text > Peter Harris http://connectivity.hummingbird.com > Research and Development Phone: +1 905 762 6001 > peter.harris at hummingbird.com Toll Free: 1 877 359 4866 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithp at keithp.com Wed Dec 5 23:31:00 2007 From: keithp at keithp.com (Keith Packard) Date: Wed, 05 Dec 2007 23:31:00 -0800 Subject: GLSL on Mesa / Intel 915 In-Reply-To: <47578CE3.2060805@mathcs.emory.edu> References: <47578CE3.2060805@mathcs.emory.edu> Message-ID: <1196926260.5122.50.camel@koto.keithp.com> On Thu, 2007-12-06 at 00:47 -0500, Ken Mandelberg wrote: > Is there any support for GLSL on Mesa 7.0.1 running against the Intel > driver for the i915GM? i915 can't support glsl, only arb_fragment. -- keith.packard at intel.com -------------- 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 bart at cs.pdx.edu Thu Dec 6 00:54:36 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Thu, 06 Dec 2007 00:54:36 -0800 Subject: Website maintenance volunteers? In-Reply-To: Your message of "Wed, 05 Dec 2007 12:35:48 PST." <47570BA4.8020504@sun.com> References: <47570BA4.8020504@sun.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> Message-ID: <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> In message <47570BA4.8020504 at sun.com> you wrote: > Barton C Massey wrote: > > I'm not understanding people's spam concerns. As far as I > > know, only X.Org members are currently allowed to edit the > > wiki. Am I wrong here? > > Yes - anyone who fills in the account form on the wiki can edit it, > and spammers have done so repeatedly. Oh. Thanks for the clarification! I'm confused by this, as I wasn't allowed to edit at least the front page until I recently got the right permissions. And as far as I know no one but XCB developers can edit our XCB pages---although I could be wrong here also. Can somebody in the know please give a clear description of what our current Wiki editing rules are? Bart From cloos+pdx-xorg at jhcloos.com Thu Dec 6 01:44:29 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Thu, 06 Dec 2007 09:44:29 +0000 Subject: Best manual-to-automatic ChangeLog commit? In-Reply-To: <20071206024442.GF3614@fooishbar.org> (Daniel Stone's message of "Thu, 6 Dec 2007 02:44:42 +0000") References: <20071206024442.GF3614@fooishbar.org> Message-ID: >>>>> "Daniel" == Daniel Stone writes: Daniel> Just take the Makefile.am hook from xserver. I take it these additions are also required?: -EXTRA_DIST = ... +EXTRA_DIST = ... ChangeLog +MAINTAINERCLEANFILES = ChangeLog +dist-hook: ChangeLog -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From kamalneet.s at samsung.com Thu Dec 6 02:44:10 2007 From: kamalneet.s at samsung.com (KAMALNEET SINGH) Date: Thu, 06 Dec 2007 10:44:10 +0000 (GMT) Subject: Looking for XRender examples Message-ID: <27956182.355981196937849978.JavaMail.weblogic@epml07> Clemens Eisserer wrote: > Hello, > > Does anybody know tutorials for learning the XRender API? > I found many tutorials for X11's primitive drawing but for XRender > there is almost no developer documentation available. > You can look at xclock code, and also the code of Render-related Xft functions it calls. Keith has screenshots of simpler applications at http://people.freedesktop.org/~keithp/render/, they can serve as tutorials, but I don't know where is the source code. Some notes on xclock's usage of XRender: * Destination surface is created using XftDrawPicture. * Source surface is created using XftDrawSrcPicture. XftDrawSrcPicture uses XCreatePixmap to create a 1x1 pixmap and then uses it as a drawable to create a new Picture. And then uses XRenderFillRectangle to draw the color onto it. * For rendering, xclock calls XRenderCompositeDoublePoly, with some non-NULL mask format (A8 in my test run). For non-null mask-format, Render specification says that first a temporary alpha picture is created and rasterization done on it. See "Trapezoids" in http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt From daniel at fooishbar.org Thu Dec 6 02:57:45 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 6 Dec 2007 10:57:45 +0000 Subject: Website maintenance volunteers? In-Reply-To: <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> References: <47570BA4.8020504@sun.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> Message-ID: <20071206105745.GH3614@fooishbar.org> On Thu, Dec 06, 2007 at 12:54:36AM -0800, Barton C Massey wrote: > In message <47570BA4.8020504 at sun.com> you wrote: > > Barton C Massey wrote: > > > I'm not understanding people's spam concerns. As far as I > > > know, only X.Org members are currently allowed to edit the > > > wiki. Am I wrong here? > > > > Yes - anyone who fills in the account form on the wiki can edit it, > > and spammers have done so repeatedly. > > Oh. Thanks for the clarification! > > I'm confused by this, as I wasn't allowed to edit at least > the front page until I recently got the right permissions. > And as far as I know no one but XCB developers can edit our > XCB pages---although I could be wrong here also. > > Can somebody in the know please give a clear description of > what our current Wiki editing rules are? FrontPage: only a limited subset of people (historical reasons) everything else: everyone who's registered -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Thu Dec 6 03:05:36 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 6 Dec 2007 11:05:36 +0000 Subject: Best manual-to-automatic ChangeLog commit? In-Reply-To: References: <20071206024442.GF3614@fooishbar.org> Message-ID: <20071206110536.GI3614@fooishbar.org> On Thu, Dec 06, 2007 at 09:44:29AM +0000, James Cloos wrote: > >>>>> "Daniel" == Daniel Stone writes: > > Daniel> Just take the Makefile.am hook from xserver. > > I take it these additions are also required?: > > -EXTRA_DIST = ... > +EXTRA_DIST = ... ChangeLog > +MAINTAINERCLEANFILES = ChangeLog > +dist-hook: ChangeLog Yep, that's the one. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From km at mathcs.emory.edu Thu Dec 6 04:41:27 2007 From: km at mathcs.emory.edu (Ken Mandelberg) Date: Thu, 06 Dec 2007 07:41:27 -0500 Subject: GLSL on Mesa / Intel 915 In-Reply-To: <1196926260.5122.50.camel@koto.keithp.com> References: <47578CE3.2060805@mathcs.emory.edu> <1196926260.5122.50.camel@koto.keithp.com> Message-ID: <4757EDF7.9000204@mathcs.emory.edu> Keith Packard wrote: > On Thu, 2007-12-06 at 00:47 -0500, Ken Mandelberg wrote: >> Is there any support for GLSL on Mesa 7.0.1 running against the Intel >> driver for the i915GM? > > i915 can't support glsl, only arb_fragment. > Do any of the newer Intel chips support glsl in any version of the driver? From matteo.brusa at kaasa.com Thu Dec 6 05:54:39 2007 From: matteo.brusa at kaasa.com (Matteo Brusa) Date: Thu, 06 Dec 2007 14:54:39 +0100 Subject: Output problems with 945GM Message-ID: <4757FF1F.4060500@kaasa.com> Hi, i have some HDTV configuration issues with my 945GM based pc, i hope i'm in the right place to ask. I'm running Ubuntu 7.10 and therefore the intel driver version 2:2.1.1-0ubuntu9. VGA output The VGA output works great, it uses the 1360x768 resolution when plugged to an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying to get either HDMI (with DVI adapter cable) or component running. LDVS In X, LVDS is always enabled although i have no LCD screen. I tried "xrandr --ouput LDVS --off" without success, and the intel module does not support any xorg.conf option to shut it off. Could this be the reason why xvidtune always shows 1024x768 and not the actual screen value? Component I always get 1024x768, no matter which Modeline i specify. Any suggestion? TDMS-1 I got 1280x768 working, with noticeable overscan. How can i use the same 1360x768 with DVI, or get rid of the overscan? I also tried to disable DDC; in this case i cannot set any video mode with randr. Do i need to use the 915resolution tool, or it's not relevant anymore? What is the output name for the component: TDMS-1, VGA? Last question: X -verbose says "(==) intel(0): VideoRam: 262144 KB". Does it mean that it allocates 256 megs for the as video memory? Thanks in advance for any suggestion, Matteo From linuxhippy at gmail.com Thu Dec 6 06:05:58 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 6 Dec 2007 15:05:58 +0100 Subject: Looking for XRender examples In-Reply-To: <27956182.355981196937849978.JavaMail.weblogic@epml07> References: <27956182.355981196937849978.JavaMail.weblogic@epml07> Message-ID: <194f62550712060605h6b30778fr9f945e1caa284b96@mail.gmail.com> Hello KAMALNEET, > You can look at xclock code, and also the code of Render-related Xft functions it calls. > Keith has screenshots of simpler applications at http://people.freedesktop.org/~keithp/render/, they can serve as tutorials, but I don't know where is the source code. > > Some notes on xclock's usage of XRender: > * Destination surface is created using XftDrawPicture. > * Source surface is created using XftDrawSrcPicture. XftDrawSrcPicture uses XCreatePixmap to create a 1x1 pixmap and then uses it as a drawable to create a new Picture. And then uses XRenderFillRectangle to draw the color onto it. > * For rendering, xclock calls XRenderCompositeDoublePoly, with some non-NULL mask format (A8 in my test run). For non-null mask-format, Render specification says that first a temporary alpha picture is created and rasterization done on it. See "Trapezoids" in http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt The code for Keith's demos would be great, thanks for the hint about xclock - I completly forgot is was done using render ;) Thanks alot for your hints, they provide at least some starting point to me. lg Clemens From RG.Schneider at t-online.de Thu Dec 6 08:13:25 2007 From: RG.Schneider at t-online.de (Ralf Schneider) Date: Thu, 06 Dec 2007 17:13:25 +0100 Subject: Question/Proposal for multiple X-Servers with multiple Graphic cards and input devices Message-ID: <1196957606.3003.7.camel@ralaptop.se-engineering.de> Hello, currently I'm trying to set up a System as 'RDP' / 'Citrix' Client Station for 4 Users on one single Computer. Basically it is easy to configure and run. BUT:: 1. My computer has a build in graphic adapter -- which I want to use as a Administration console with the ordinary way of running the X server on a vt ( e.g. 21 ) and normal text consoles on vt's 1 to 6. For that I use the PS/2 mouse and keyboard connectors as input devices. 2. I've installed 4 more PCI graphic cards and for each grafic card additional USB mouse and keybords. The problem is that all X servers MUST be connected to a vt and vt switching must be disabled in order to run the X servers. Therefore the text vt's are not accessable anymore. ( if vt switching is enabled and one switches to one of the text vt's, ALL X servers are disabled ). QUESTION / PROPOSAL:: ===================== Why is it ( is it ? ) neccessary to assign a vt to a X server ? Would it be possible to run one X server in the usual way on (e.g.) vt 21 WITH vt switching enabled to have access to the text/framebuffer consoles AND simultaniously multiple additional x servers on onther vt without vt switching so that those users can alwayws work without being interfered by the 'Admin' user ? I hope my description is sufficiant to understand by someone else. If not, please ask back. Regards /RalfS From brian.paul at tungstengraphics.com Thu Dec 6 06:24:43 2007 From: brian.paul at tungstengraphics.com (Brian Paul) Date: Thu, 06 Dec 2007 07:24:43 -0700 Subject: GLSL on Mesa / Intel 915 In-Reply-To: <4757EDF7.9000204@mathcs.emory.edu> References: <47578CE3.2060805@mathcs.emory.edu> <1196926260.5122.50.camel@koto.keithp.com> <4757EDF7.9000204@mathcs.emory.edu> Message-ID: <4758062B.8090900@tungstengraphics.com> Ken Mandelberg wrote: > Keith Packard wrote: >> On Thu, 2007-12-06 at 00:47 -0500, Ken Mandelberg wrote: >>> Is there any support for GLSL on Mesa 7.0.1 running against the Intel >>> driver for the i915GM? >> i915 can't support glsl, only arb_fragment. >> > > Do any of the newer Intel chips support glsl in any version of the driver? Yes, i965 using Mesa/master. -Brian From giedz at arise.pl Thu Dec 6 06:18:28 2007 From: giedz at arise.pl (Marcin Giedz) Date: Thu, 06 Dec 2007 15:18:28 +0100 Subject: Recommended graphic card Message-ID: <475804B4.1000900@arise.pl> Hello I'm looking for graphic card with quite low power consumption, PCIe and with good support for features like HW rotation, HDMI/HDTV. I was wondering about ATI or Intel since they both have opensource drivers and are quite up-to-date. Which model can you recommend ? Best regards, Marcin From edwardbetts at gmail.com Thu Dec 6 06:55:53 2007 From: edwardbetts at gmail.com (Edward Betts) Date: Thu, 6 Dec 2007 14:55:53 +0000 Subject: xf86-video-ati: Radeon S-Video PAL not working Message-ID: <3ffa53c60712060655v50d604a7w847822ec9a19001b@mail.gmail.com> Using xf86-video-ati from git master, I run the xrandr commands to enable S-Video. With tv_standard set to ntsc I get a grayscale picture. This is the expected behaviour with a PAL television. If I switch tv_standard to pal I don't get a picture. Any ideas? Could it be a problem with refresh rate? Let me know if you need any more information. I'm using an RV280 [Radeon 9200 PRO] Output from xrandr: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2080 x 1024 VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 59.9 1280x960 59.9 1152x864 75.0 74.8 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 S-video connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 800x600 59.9*+ 60.3 My current /etc/X11/xorg.conf: Section "Files" ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "gb" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Device" Identifier "ATI Technologies Inc RV280 [Radeon 9200 PRO]" Driver "ati" BusID "PCI:1:0:0" Option "ForceTVOut" "true" Option "TVStandard" "pal" EndSection Section "Monitor" Identifier "Configured Monitor" Option "DPMS" HorizSync 30-70 VertRefresh 50-160 EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" DefaultDepth 24 SubSection "Display" Virtual 2080 1024 Modes "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection And this is my /var/log/Xorg.0.log: X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) Current Operating System: Linux amd64 2.6.22-3-amd64 #1 SMP Sun Nov 4 18:18:09 UTC 2007 x86_64 Build Date: 20 November 2007 02:55:16AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Thu Dec 6 14:54:21 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Configured Monitor" (==) No device specified for screen "Default Screen". Using the first device section listed. (**) | |-->Device "ATI Technologies Inc RV280 [Radeon 9200 PRO]" (==) |-->Input Device "Configured Mouse" (==) |-->Input Device "Generic Keyboard" (==) The core pointer device wasn't specified explicitly in the layout. Using the first mouse device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first core keyboard device. (==) Automatically adding devices (==) Automatically enabling devices (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/cyrillic, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (**) ModulePath set to "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x7b2660 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3188 card 1106,3188 rev 01 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b188 card 0000,0000 rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0b:0: chip 100b,0020 card 1385,f311 rev 00 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 1106,0571 card 1458,5002 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:10:0: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3038 card 1458,5004 rev 81 class 0c,03,00 hdr 80 (II) PCI: 00:10:4: chip 1106,3104 card 1458,5004 rev 86 class 0c,03,20 hdr 80 (II) PCI: 00:11:0: chip 1106,3227 card 1458,5001 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:5: chip 1106,3059 card 1458,a002 rev 60 class 04,01,00 hdr 00 (II) PCI: 00:13:0: chip 10ec,8169 card 1458,e000 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:18:0: chip 1022,1100 card 0000,0000 rev 00 class 06,00,00 hdr 80 (II) PCI: 00:18:1: chip 1022,1101 card 0000,0000 rev 00 class 06,00,00 hdr 80 (II) PCI: 00:18:2: chip 1022,1102 card 0000,0000 rev 00 class 06,00,00 hdr 80 (II) PCI: 00:18:3: chip 1022,1103 card 0000,0000 rev 00 class 06,00,00 hdr 80 (II) PCI: 01:00:0: chip 1002,5960 card 1462,9522 rev 01 class 03,00,00 hdr 80 (II) PCI: 01:00:1: chip 1002,5940 card 1462,9523 rev 01 class 03,80,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B] [1] -1 0 0x0000a400 - 0x0000a4ff (0x100) IX[B] [2] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B] [3] -1 0 0x0000ac00 - 0x0000acff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xe8000000 - 0xe9ffffff (0x2000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd8000000 - 0xe7ffffff (0x10000000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) ATI Technologies Inc RV280 [Radeon 9200 PRO] rev 1, Mem @ 0xd8000000/27, 0xe9000000/16, I/O @ 0xa000/8 (--) PCI: (1:0:1) ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) rev 1, Mem @ 0xe0000000/27, 0xe9010000/16 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xd0000000 from 0xd0000000 to 0xcfffffff (II) Active PCI resource ranges: [0] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [1] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [2] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [3] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [4] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [5] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [6] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [7] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [8] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [9] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [10] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [11] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [12] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [13] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [14] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [15] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [16] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [1] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [2] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [3] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [4] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [5] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [6] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [7] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [8] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [9] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [10] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [11] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [12] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [13] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [14] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [15] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [16] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [5] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [6] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [7] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [8] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [10] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [13] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [14] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [15] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [16] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [17] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [19] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [20] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [21] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [22] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "freetype" (II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (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.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "ati" (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.4.0, module version = 6.7.196 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "mouse" (II) Loading /usr/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) ATI: ATI driver wrapper (version 6.7.196) for chipsets: mach64, rage128, radeon (II) Primary Device is: PCI 01:00:0 (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.4.0, module version = 4.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835 (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (--) Chipset ATI Radeon 9250 5960 (AGP) found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [5] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [6] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [7] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [8] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [10] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [13] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [14] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [15] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [16] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [17] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [19] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [20] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [21] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [22] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [5] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [6] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [7] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [8] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [10] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [13] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [14] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [15] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [16] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [17] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [18] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [19] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [20] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [21] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [22] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [23] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [24] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [25] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) [26] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [27] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): MMIO registers at 0x00000000e9000000: size 64KB (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (**) RADEON(0): Option "ForceTVOut" "true" (**) RADEON(0): Option "TVStandard" "pal" (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.4.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 2.0 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (II) RADEON(0): initializing int10 (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (--) RADEON(0): Chipset: "ATI Radeon 9250 5960 (AGP)" (ChipID = 0x5960) (--) RADEON(0): Linear framebuffer at 0x00000000d8000000 (II) RADEON(0): AGP card detected (II) RADEON(0): Legacy BIOS detected drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.27.0 (==) RADEON(0): Page Flipping disabled (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=131072K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 131072 kByte (64 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (WW) RADEON(0): Requested desktop size exceeds surface limts for tiling, ColorTiling disabled (II) RADEON(0): Max desktop size set to 2080x1024 (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf (II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module "i2c" already built-in (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=40000; xclk=16600 (II) RADEON(0): Bios Connector table: (II) RADEON(0): Port0: DDCType-3, DACType-0, TMDSType-0, ConnectorType-2 (II) RADEON(0): Port5: DDCType-0, DACType-1, TMDSType-2, ConnectorType-6 (II) RADEON(0): Output VGA-0 using monitor section Configured Monitor (II) RADEON(0): I2C bus "VGA_DDC" initialized. (II) RADEON(0): Output S-video has no monitor section (II) RADEON(0): Default TV standard: NTSC (II) RADEON(0): TV standards supported by chip: NTSC PAL (II) RADEON(0): Port0: Monitor -- AUTO Connector -- VGA DAC Type -- Primary TMDS Type -- None DDC Type -- VGA_DDC (II) RADEON(0): Port1: Monitor -- AUTO Connector -- STV DAC Type -- TVDAC/ExtDAC TMDS Type -- None DDC Type -- None (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 finished output detect: 0 finished output detect: 1 finished all detect before xf86InitialConfiguration (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 in RADEONProbeOutputModes (II) RADEON(0): Output VGA-0 connected (II) RADEON(0): Output S-video connected (II) RADEON(0): Output VGA-0 using initial mode 1280x1024 (II) RADEON(0): Output S-video using initial mode 800x600 after xf86InitialConfiguration (++) RADEON(0): DPI set to (100, 100) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (==) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 2.0 (==) RADEON(0): Assuming overlay scaler buffer width is 1536 (II) RADEON(0): No MM_TABLE found - assuming CARD is not TV-in capable. (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xe9000000 - 0xe900ffff (0x10000) MX[B] [1] 0 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B] [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [6] -1 0 0xeb005000 - 0xeb0050ff (0x100) MX[B] [7] -1 0 0xeb004000 - 0xeb0040ff (0x100) MX[B] [8] -1 0 0xeb007000 - 0xeb007fff (0x1000) MX[B] [9] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O [10] -1 0 0xe9010000 - 0xe901ffff (0x10000) MX[B](B) [11] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [12] -1 0 0xe9000000 - 0xe900ffff (0x10000) MX[B](B) [13] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [17] 0 0 0x0000a000 - 0x0000a0ff (0x100) IX[B] [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B] [21] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] [22] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [23] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [24] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B] [25] -1 0 0x0000cc00 - 0x0000cc1f (0x20) IX[B] [26] -1 0 0x0000c800 - 0x0000c80f (0x10) IX[B] [27] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [28] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B](B) [29] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [30] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) RADEON(0): Write-combining range (0xd8000000,0x8000000) Entering TV Save Save TV timing tables saveTimingTables: reading timing tables TV Save done (==) RADEON(0): Using 24 bit depth buffer (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x08000000 (II) RADEON(0): MC_FB_LOCATION : 0xdfffd800 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (2080,8191) (II) RADEON(0): Reserved area from (0,1024) to (2080,1026) (II) RADEON(0): Largest offscreen area available: 2080 x 7165 (II) RADEON(0): Will use front buffer at offset 0x0 (II) RADEON(0): Will use back buffer at offset 0x21c0000 (II) RADEON(0): Will use depth buffer at offset 0x29e0000 (II) RADEON(0): Will use 79872 kb for textures at offset 0x3200000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle = 0xd8000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler (==) RADEON(0): Using AGP 8x (II) RADEON(0): [agp] Mode 0x1f000a0a [AGP 0x1106/0x3188; Card 0x1002/0x5960] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001 (II) RADEON(0): [agp] ring handle = 0xd0000000 (II) RADEON(0): [agp] Ring mapped at 0x2aea12e72000 (II) RADEON(0): [agp] ring read ptr handle = 0xd0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x2aea12f73000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2aea12f74000 (II) RADEON(0): [agp] GART texture map handle = 0xd0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x2aea13174000 (II) RADEON(0): [drm] register handle = 0xe9000000 (II) RADEON(0): [dri] Visual configs initialized init memmap init common init crtc1 init pll1 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd800 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc1 restore pll1 finished PLL1 restore dac enable montype: 1 init memmap init common init crtc2 init pll2 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd800 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc2 restore pll2 finished PLL2 computeRestarts: def = 625592, h = 0, v = 0, p1=126d, p2=1a8f, restart = 625592 computeRestarts: F/H/V=0,631,902 computeRestarts: hSize=0,hInc=1593 restore tv Entering Restore TV Restore TV PLL Restore TVHV Restore TV Restarts Restore Timing Tables Restore TV standard Leaving Restore TV enable montype: 5 disable montype: 1 disable montype: 5 (==) RADEON(0): Backing store disabled (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 16 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 (WW) RADEON(0): DRI init changed memory map, adjusting ... (WW) RADEON(0): MC_FB_LOCATION was: 0xdfffd800 is: 0xdfffd800 (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xd07fd000 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd800 (II) RADEON(0): MC_AGP_LOCATION : 0xd07fd000 (II) RADEON(0): Direct rendering enabled (II) RADEON(0): Render acceleration enabled (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Horizontal and Vertical Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 1026) (II) RADEON(0): Largest offscreen area available: 2080 x 7163 (II) RADEON(0): No video input capabilities detected and no information is provided - disabling multimedia i2c (II) Loading sub module "theatre_detect" (II) LoadModule: "theatre_detect" (II) Loading /usr/local/lib/xorg/modules/multimedia//theatre_detect_drv.so (II) Module theatre_detect: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (II) RADEON(0): no multimedia table present, disabling Rage Theatre. (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 (WW) AIGLX: 3D driver claims to not support visual 0x25 (WW) AIGLX: 3D driver claims to not support visual 0x26 (WW) AIGLX: 3D driver claims to not support visual 0x27 (WW) AIGLX: 3D driver claims to not support visual 0x28 (WW) AIGLX: 3D driver claims to not support visual 0x29 (WW) AIGLX: 3D driver claims to not support visual 0x2a (WW) AIGLX: 3D driver claims to not support visual 0x2b (WW) AIGLX: 3D driver claims to not support visual 0x2c (WW) AIGLX: 3D driver claims to not support visual 0x2d (WW) AIGLX: 3D driver claims to not support visual 0x2e (WW) AIGLX: 3D driver claims to not support visual 0x2f (WW) AIGLX: 3D driver claims to not support visual 0x30 (WW) AIGLX: 3D driver claims to not support visual 0x31 (WW) AIGLX: 3D driver claims to not support visual 0x32 (II) AIGLX: Loaded and initialized /usr/lib/dri/r200_dri.so (II) GLX: Initialized DRI GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 325 x 260 (WW) Configured Mouse: No Device specified, looking for one... (II) Configured Mouse: Setting Device option to "/dev/input/mice" (--) Configured Mouse: Device: "/dev/input/mice" (==) Configured Mouse: Protocol: "Auto" (**) Option "CorePointer" (**) Configured Mouse: always reports core events (==) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 (**) Configured Mouse: Buttons: 9 (**) Configured Mouse: Sensitivity: 1 (**) Option "CoreKeyboard" (**) Generic Keyboard: always reports core events (**) Option "Protocol" "standard" (**) Generic Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Generic Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc104" (**) Generic Keyboard: XkbModel: "pc104" (**) Option "XkbLayout" "gb" (**) Generic Keyboard: XkbLayout: "gb" (**) Option "CustomKeycodes" "off" (**) Generic Keyboard: CustomKeycodes disabled (II) evaluating device (Generic Keyboard) (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD) (II) evaluating device (Configured Mouse) (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (--) Configured Mouse: PnP-detected protocol: "ExplorerPS/2" (II) Configured Mouse: ps2EnableDataReporting: succeeded enable montype: 1 enable montype: 5 (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: VSC Model: f518 Serial#: 16843009 (II) RADEON(0): Year: 2004 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.651 redY: 0.320 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.153 blueY: 0.109 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 338 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: A33043550253 (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 30 H max: 80 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: VE710s (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff005a6318f501010101 (II) RADEON(0): 230e010308221b782ece45a6524c9927 (II) RADEON(0): 1c5054bfef8081808140714f01010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300520e1100001e000000ff00413333 (II) RADEON(0): 3034333535303235330a000000fd0032 (II) RADEON(0): 4b1e500e000a202020202020000000fc (II) RADEON(0): 005645373130730a20202020202000f1 in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "VSC", prod id 62744 in RADEONProbeOutputModes -- Edward. From xavier.bestel at free.fr Thu Dec 6 07:06:31 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Thu, 06 Dec 2007 16:06:31 +0100 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <1196702555.16394.8.camel@rousalka.dyndns.org> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> Message-ID: <1196953591.28027.3.camel@skunk.anacadf.mentorg.com> Hi, I didn't really follow that discussion, but in the end would a non-US keyboard work automagically (without specific sections in xorg.conf), provided the linux console is already properly configured ? Thanks, Xav From ajax at nwnk.net Thu Dec 6 07:41:57 2007 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 06 Dec 2007 10:41:57 -0500 Subject: Question/Proposal for multiple X-Servers with multiple Graphic cards and input devices In-Reply-To: <1196957606.3003.7.camel@ralaptop.se-engineering.de> References: <1196957606.3003.7.camel@ralaptop.se-engineering.de> Message-ID: <1196955717.2303.41.camel@localhost.localdomain> On Thu, 2007-12-06 at 17:13 +0100, Ralf Schneider wrote: > QUESTION / PROPOSAL:: > ===================== > > Why is it ( is it ? ) neccessary to assign a vt to a X server ? Because, in the classic model, that's how input is routed. All keyboards are bound to the vt's tty device; input is routed from them to whichever vt is in the foreground. If you use the evdev driver, you can assign single keyboards and mice to individual servers. > Would it be possible to run one X server in the usual way on > (e.g.) vt 21 WITH vt switching enabled to have access to the > text/framebuffer consoles > AND > simultaniously multiple additional x servers on onther vt without vt > switching so that those users can alwayws work without being interfered > by the 'Admin' user ? Yes, we have that. That's what the -novtswitch option to the X server does. The issue you will run into is that some cards require the legacy VGA resources to be routed to them at various times, and the VGA routing code we currently have is only sufficient for multiple cards within one server. If you have multiple servers that each need the VGA space, they both will think they own the VGA routing at all times, and eventually you'll crash. See Tiago Vignatti's work on the VGA arbiter for work on solving this problem: http://lists.freedesktop.org/archives/xorg/2007-November/030420.html - ajax -------------- 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 nicolas.mailhot at laposte.net Thu Dec 6 07:24:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Dec 2007 16:24:12 +0100 (CET) Subject: [PATCH] Fix XKB options passed from HAL Message-ID: <53326.192.54.193.53.1196954652.squirrel@rousalka.dyndns.org> Le Jeu 6 d?cembre 2007 16:06, Xavier Bestel a ?crit : > Hi, > > I didn't really follow that discussion, but in the end would a non-US > keyboard work automagically (without specific sections in xorg.conf), > provided the linux console is already properly configured ? evdev takes care of the low-level stuff. So everything autoconfigured at the kernel (module) level would work the same in xorg. The kernel hides if a keyboard is PS/2, usb... hotplugged or not, and you'd get the same level of support in xorg. The same keyboard would have the same effect if it's plugged as PS/2 or USB (not the case right now). However, just like you need to select a logical keyboard layout for the console, you'll still need to select a logical layout for X (I think there are plans to hook a layout chooser in gdm). -- Nicolas Mailhot From peter.harris at hummingbird.com Thu Dec 6 07:30:54 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Thu, 06 Dec 2007 10:30:54 -0500 Subject: Using XVideo extension? In-Reply-To: References: <4756CD28.6070206@hummingbird.com> Message-ID: <475815AE.50703@hummingbird.com> Florian Harmuth wrote: > Hello, > thx for your answer -> how to find a documentation about the XRender > lib/api? This documents the protocol: http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt The API in http://gitweb.freedesktop.org/?p=xorg/lib/libXrender.git;a=blob;f=include/X11/extensions/Xrender.h follows the protocol fairly closely. > Are there any new books about programming under X? ( newer as > 1993...) Not that I am aware of. I generally prefer to read source code (as it is always more accurate). Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From alexdeucher at gmail.com Thu Dec 6 07:49:35 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 6 Dec 2007 10:49:35 -0500 Subject: xf86-video-ati: Radeon S-Video PAL not working In-Reply-To: <3ffa53c60712060655v50d604a7w847822ec9a19001b@mail.gmail.com> References: <3ffa53c60712060655v50d604a7w847822ec9a19001b@mail.gmail.com> Message-ID: On Dec 6, 2007 9:55 AM, Edward Betts wrote: > Using xf86-video-ati from git master, I run the xrandr commands to > enable S-Video. With tv_standard set to ntsc I get a grayscale > picture. This is the expected behaviour with a PAL television. If I > switch tv_standard to pal I don't get a picture. Any ideas? Could it > be a problem with refresh rate? Let me know if you need any more > information. > > I'm using an RV280 [Radeon 9200 PRO] PAL is known to be broken at the moment for most people. I've never gotten a chance to sort out why. See: https://bugs.freedesktop.org/show_bug.cgi?id=12007 NTSC should work. Alex From xavier.bestel at free.fr Thu Dec 6 07:54:22 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Thu, 06 Dec 2007 16:54:22 +0100 Subject: Recommended graphic card In-Reply-To: <475804B4.1000900@arise.pl> References: <475804B4.1000900@arise.pl> Message-ID: <1196956462.28027.12.camel@skunk.anacadf.mentorg.com> On Thu, 2007-12-06 at 15:18 +0100, Marcin Giedz wrote: > Hello > > I'm looking for graphic card with quite low power consumption, PCIe and > with good support for features like HW rotation, HDMI/HDTV. I was > wondering about ATI or Intel since they both have opensource drivers and > are quite up-to-date. Which model can you recommend ? Intel doesn't produce "discrete" cards, i.e. cards you can plug in your pcie connector. So, either you buy an ATI card, or you buy a motherboard with an integrated Intel chipset. If you want to do 3D, buy a radeon x850. If you need only 2D, a more recent card will do fine. Xav From adr3nald0s at gmail.com Thu Dec 6 08:01:16 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Thu, 6 Dec 2007 10:01:16 -0600 Subject: ATI VGA-0 Dual Head Problems In-Reply-To: References: <308083c30712051004t3f22b2b4qf8f261b1ccbf1a36@mail.gmail.com> Message-ID: <308083c30712060801t3077a5ack80676fb0bb46964f@mail.gmail.com> On Dec 5, 2007 10:12 PM, Alex Deucher wrote: > We are going to need at least your log and config to sort this out. > Also, it's unclear what chip you have. Please file a bug > (https://bugs.freedesktop.org) and explain the situation and attach > your xorg log and config. I've just submitted bug #13548, https://bugs.freedesktop.org/show_bug.cgi?id=13548. My configuration file and log file are attached to the bug. They are reproduced here for convenience: xorg.conf: Section "ServerLayout" Identifier "Simple Layout" Screen "Screen[0]" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/share/X11/rgb" FontPath "/usr/share/fonts/local/" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/OTF/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/CID/" FontPath "/usr/share/fonts/Speedo/" FontPath "/usr/share/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/100dpi/:unscaled" FontPath "/usr/share/fonts/75dpi/" FontPath "/usr/share/fonts/100dpi/" FontPath "/usr/share/fonts/cyrillic/" EndSection Section "Module" Load "dbe" # Double buffer extension SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection Load "type1" Load "freetype" #Load "speedo" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/mouse" EndSection Section "Monitor" Identifier "Internal Panel" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" EndSection Section "Monitor" Identifier "S-Video" Option "Enable" "FALSE" EndSection Section "Monitor" Identifier "DVI-O" Option "Enable" "FALSE" EndSection Section "Monitor" Identifier "External VGA Monitor" Option "DPMS" "true" Option "RightOf" "Internal Panel" EndSection Section "Device" Identifier "R600" Driver "ati" Option "Monitor-LVDS" "Internal Panel" Option "Monitor-VGA-0" "External VGA Monitor" EndSection Section "Screen" Identifier "Screen[0]" Device "R600" Monitor "Internal Panel" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Virtual 3520 1920 EndSubSection EndSection Xorg.0.log: _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/euroclydon:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Slackware 12.0 Slackware Linux Project Current Operating System: Linux euroclydon 2.6.21.5-rdp #8 SMP Sat Nov 10 01:25:50 CST 2007 i686 Build Date: 09 May 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Thu Dec 6 09:23:23 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen[0]" (0) (**) | |-->Monitor "Internal Panel" (**) | |-->Device "R600" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (WW) The directory "/usr/share/fonts/CID/" does not exist. Entry deleted from font path. (**) FontPath set to: /usr/share/fonts/local/, /usr/share/fonts/misc/, /usr/share/fonts/OTF/, /usr/share/fonts/TTF/, /usr/share/fonts/Type1/, /usr/share/fonts/Speedo/, /usr/share/fonts/75dpi/:unscaled, /usr/share/fonts/100dpi/:unscaled, /usr/share/fonts/75dpi/, /usr/share/fonts/100dpi/, /usr/share/fonts/cyrillic/ (**) RgbPath set to "/usr/share/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81dcd60 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.2 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2590 card 1028,0186 rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2591 card 0000,0000 rev 03 class 06,04,00 hdr 01 (II) PCI: 00:1c:0: chip 8086,2660 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2658 card 1028,0186 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2659 card 1028,0186 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,265a card 1028,0186 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:3: chip 8086,265b card 1028,0186 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,265c card 1028,0186 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev d3 class 06,04,01 hdr 81 (II) PCI: 00:1e:2: chip 8086,266e card 1028,0186 rev 03 class 04,01,00 hdr 00 (II) PCI: 00:1e:3: chip 8086,266d card 14f1,5423 rev 03 class 07,03,00 hdr 00 (II) PCI: 00:1f:0: chip 8086,2641 card 1028,0186 rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:2: chip 8086,2653 card 1028,0186 rev 03 class 01,01,80 hdr 00 (II) PCI: 01:00:0: chip 1002,3150 card 1028,2002 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 14e4,1677 card 1028,0186 rev 01 class 02,00,00 hdr 00 (II) PCI: 03:01:0: chip 104c,8036 card 2000,0000 rev 00 class 06,07,00 hdr 82 (II) PCI: 03:01:5: chip 104c,8038 card 1028,0186 rev 00 class 07,80,00 hdr 80 (II) PCI: 03:03:0: chip 8086,4223 card 8086,1020 rev 05 class 02,80,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000d000 - 0x0000dfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xdfd00000 - 0xdfefffff (0x200000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,2), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xdfc00000 - 0xdfcfffff (0x100000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 3: bridge is at (0:30:0), (0,3,7), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 3 I/O range: [0] -1 0 0x00002000 - 0x00002fff (0x1000) IX[B] (II) Bus 3 non-prefetchable memory range: [0] -1 0 0xdfb00000 - 0xdfbfffff (0x100000) MX[B] (II) Bus 3 prefetchable memory range: [0] -1 0 0x88000000 - 0x8bffffff (0x4000000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 4: bridge is at (3:1:0), (3,4,7), BCTRL: 0x05c0 (VGA_EN is cleared) (II) Bus 4 I/O range: [0] -1 0 0x00002000 - 0x000020ff (0x100) IX[B] [1] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] (II) Bus 4 prefetchable memory range: [0] -1 0 0x88000000 - 0x8bffffff (0x4000000) MX[B] (--) PCI:*(1:0:0) ATI Technologies Inc M24 1P [Radeon Mobility X600] rev 0, Mem @ 0xd0000000/27, 0xdfdf0000/16, I/O @ 0xde00/8, BIOS @ 0xdfe00000/17 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [1] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [2] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [3] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [4] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [5] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [6] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [7] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [8] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [9] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [10] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [11] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [12] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [13] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [14] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [15] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [16] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [17] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [18] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [19] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [20] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [21] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [22] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [23] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [1] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [2] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [3] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [4] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [5] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [6] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [7] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [8] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [9] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [10] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [11] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [12] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [13] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [14] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [15] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [16] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [17] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [18] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [19] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [20] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [21] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [22] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [23] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [5] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [6] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [7] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [8] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [9] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [10] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [11] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [12] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [13] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [17] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [18] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [19] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [20] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [21] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [22] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [23] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [24] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [25] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [26] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [27] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [28] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [29] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (II) Loading /usr/lib/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "freetype" (II) Loading /usr/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.3.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "ati" (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.3.0, module version = 6.7.196 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) LoadModule: "mouse" (II) Loading /usr/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.1.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (II) LoadModule: "kbd" (II) Loading /usr/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.2.99.905, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (II) ATI: ATI driver wrapper (version 6.7.196) for chipsets: mach64, rage128, radeon (II) Primary Device is: PCI 01:00:0 (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.3.0, module version = 4.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835 (--) Assigning device section with no busID to primary device (--) Chipset ATI Radeon Mobility X600 (M24) 3150 (PCIE) found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [5] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [6] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [7] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [8] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [9] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [10] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [11] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [12] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [13] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [17] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [18] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [19] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [20] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [21] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [22] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [23] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [24] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [25] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [26] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [27] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [28] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [29] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [5] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [6] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [7] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [8] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [9] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [10] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [11] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [12] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [13] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [19] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [20] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [21] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [22] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [23] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [24] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [25] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [26] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [27] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [28] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [29] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [30] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [31] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [32] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) [33] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [34] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): MMIO registers at 0x00000000dfdf0000: size 64KB (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.3.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.2 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (II) RADEON(0): initializing int10 (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (--) RADEON(0): Chipset: "ATI Radeon Mobility X600 (M24) 3150 (PCIE)" (ChipID = 0x3150) (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 (--) RADEON(0): BIOS at 0xdfe00000 (II) RADEON(0): PCIE card detected (II) RADEON(0): Legacy BIOS detected (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=131072K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 131072 kByte (128 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) RADEON(0): Max desktop size set to 3520x1920 (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf (II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module already built-in (II) RADEON(0): PLL parameters: rf=2700 rd=6 min=20000 max=35000; xclk=26325 (II) RADEON(0): Bios Connector table: (II) RADEON(0): Port0: DDCType-3, DACType-0, TMDSType-0, ConnectorType-2 (II) RADEON(0): Port1: DDCType-2, DACType-0, TMDSType-0, ConnectorType-4 (II) RADEON(0): Port4: DDCType-0, DACType-2, TMDSType-2, ConnectorType-1 (II) RADEON(0): Port5: DDCType-0, DACType-1, TMDSType-2, ConnectorType-6 (II) RADEON(0): Output VGA-0 using monitor section External VGA Monitor (**) RADEON(0): Option "RightOf" "Internal Panel" (II) RADEON(0): I2C bus "VGA_DDC" initialized. (II) RADEON(0): Output DVI-0 has no monitor section (II) RADEON(0): I2C bus "DVI_DDC" initialized. (II) RADEON(0): DFP table revision: 4 (II) RADEON(0): Output LVDS using monitor section Internal Panel (II) RADEON(0): Panel ID string: G4934?M1LW12 (II) RADEON(0): Panel Size from BIOS: 1920x1200 (II) RADEON(0): BIOS provided dividers will be used. (WW) RADEON(0): LVDS Info: XRes: 1920, YRes: 1200, DotClock: 161750 HBlank: 264, HOverPlus: 96, HSyncWidth: 32 VBlank: 35, VOverPlus: 2, VSyncWidth: 6 (II) RADEON(0): Output S-video using monitor section S-Video (**) RADEON(0): Option "Enable" "FALSE" (II) RADEON(0): Default TV standard: NTSC (II) RADEON(0): TV standards supported by chip: NTSC (II) RADEON(0): Port0: Monitor -- AUTO Connector -- VGA DAC Type -- Primary TMDS Type -- None DDC Type -- VGA_DDC (II) RADEON(0): Port1: Monitor -- AUTO Connector -- DVI-D DAC Type -- None TMDS Type -- Internal DDC Type -- DVI_DDC (II) RADEON(0): Port2: Monitor -- AUTO Connector -- Proprietary/LVDS DAC Type -- None TMDS Type -- None DDC Type -- None (II) RADEON(0): Port3: Monitor -- AUTO Connector -- STV DAC Type -- TVDAC/ExtDAC TMDS Type -- None DDC Type -- None (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Using EDID range info for horizontal sync (II) RADEON(0): Using EDID range info for vertical refresh (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) RADEON(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) RADEON(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) RADEON(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) RADEON(0): Modeline "640x480" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (II) RADEON(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (II) RADEON(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) RADEON(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) RADEON(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (II) RADEON(0): Modeline "1600x1200" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) RADEON(0): Modeline "1280x960" 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (II) RADEON(0): Modeline "1152x864" 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (II) RADEON(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 finished output detect: 0 (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 finished output detect: 1 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 finished output detect: 2 finished output detect: 3 finished all detect before xf86InitialConfiguration (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) RADEON(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) RADEON(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) RADEON(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) RADEON(0): Modeline "640x480" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (II) RADEON(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (II) RADEON(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) RADEON(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) RADEON(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (II) RADEON(0): Modeline "1600x1200" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) RADEON(0): Modeline "1280x960" 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (II) RADEON(0): Modeline "1152x864" 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (II) RADEON(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): Output VGA-0 connected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Output LVDS connected (II) RADEON(0): Output S-video disconnected (II) RADEON(0): Output VGA-0 using initial mode 1600x1200 (II) RADEON(0): Output LVDS using initial mode 1920x1200 after xf86InitialConfiguration (**) RADEON(0): Display dimensions: (410, 310) mm (**) RADEON(0): DPI set to (218, 157) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module already built-in (==) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.2 (==) RADEON(0): Assuming overlay scaler buffer width is 1536 (II) RADEON(0): No MM_TABLE found - assuming CARD is not TV-in capable. (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B] [1] 0 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B] [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [6] -1 0 0xdfbff000 - 0xdfbfffff (0x1000) MX[B] [7] -1 0 0xdfbfe000 - 0xdfbfefff (0x1000) MX[B] [8] -1 0 0xdfbfd000 - 0xdfbfdfff (0x1000) MX[B] [9] -1 0 0xdfcf0000 - 0xdfcfffff (0x10000) MX[B] [10] -1 0 0xdffffd00 - 0xdffffdff (0x100) MX[B] [11] -1 0 0xdffffe00 - 0xdfffffff (0x200) MX[B] [12] -1 0 0xffa80800 - 0xffa80bff (0x400) MX[B] [13] -1 0 0xdfe00000 - 0xdfe1ffff (0x20000) MX[B](B) [14] -1 0 0xdfdf0000 - 0xdfdfffff (0x10000) MX[B](B) [15] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B](B) [16] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [17] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [18] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [19] 0 0 0x0000de00 - 0x0000deff (0x100) IX[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [22] -1 0 0x0000bfa0 - 0x0000bfaf (0x10) IX[B] [23] -1 0 0x00000374 - 0x00000374 (0x1) IX[B] [24] -1 0 0x00000170 - 0x00000177 (0x8) IX[B] [25] -1 0 0x000003f4 - 0x000003f4 (0x1) IX[B] [26] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B] [27] -1 0 0x0000ec80 - 0x0000ecff (0x80) IX[B] [28] -1 0 0x0000ee00 - 0x0000eeff (0x100) IX[B] [29] -1 0 0x0000ec40 - 0x0000ec7f (0x40) IX[B] [30] -1 0 0x0000ed00 - 0x0000edff (0x100) IX[B] [31] -1 0 0x0000bf20 - 0x0000bf3f (0x20) IX[B] [32] -1 0 0x0000bf40 - 0x0000bf5f (0x20) IX[B] [33] -1 0 0x0000bf60 - 0x0000bf7f (0x20) IX[B] [34] -1 0 0x0000bf80 - 0x0000bf9f (0x20) IX[B] [35] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B](B) [36] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [37] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) RADEON(0): Write-combining range (0xd0000000,0x8000000) (WW) RADEON(0): Cannot read colourmap from VGA. Will restore with default Entering TV Save Save TV timing tables saveTimingTables: reading timing tables TV Save done (II) RADEON(0): Dynamic Clock Scaling Disabled (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x08000000 (II) RADEON(0): MC_FB_LOCATION : 0xd7ffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Memory manager initialized to (0,0) (3520,8191) (II) RADEON(0): Reserved area from (0,1920) to (3520,1922) (II) RADEON(0): Largest offscreen area available: 3520 x 6269 init memmap init common init crtc1 init pll1 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xd7ffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc1 restore pll1 restore LVDS enable montype: 2 init memmap init common init crtc2 init pll2 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xd7ffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc2 restore pll2 finished PLL2 restore dac enable montype: 1 disable montype: 2 disable montype: 1 (==) RADEON(0): Backing store disabled (WW) RADEON(0): Direct rendering disabled (II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer. (II) RADEON(0): Render acceleration disabled (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (**) Option "dpms" "true" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 1922) (II) RADEON(0): Largest offscreen area available: 3520 x 6267 (II) RADEON(0): No video input capabilities detected and no information is provided - disabling multimedia i2c (II) Loading sub module "theatre_detect" (II) LoadModule: "theatre_detect" (II) Loading /usr/lib/xorg/modules/multimedia//theatre_detect_drv.so (II) Module theatre_detect: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (II) RADEON(0): no multimedia table present, disabling Rage Theatre. (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. (WW) RADEON(0): Option "VendorName" is not used (WW) RADEON(0): Option "ModelName" is not used (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (EE) AIGLX: DRI module not loaded (II) Loading local sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 897 x 306 (**) Option "Protocol" "PS/2" (**) Mouse1: Device: "/dev/mouse" (**) Mouse1: Protocol: "PS/2" (**) Option "CorePointer" (**) Mouse1: Core Pointer (**) Option "Device" "/dev/mouse" (==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Mouse1: ZAxisMapping: buttons 4 and 5 (**) Mouse1: Buttons: 9 (**) Option "CoreKeyboard" (**) Keyboard1: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard1: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (II) Mouse1: ps2EnableDataReporting: succeeded enable montype: 2 enable montype: 1 (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) RADEON(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) RADEON(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) RADEON(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) RADEON(0): Modeline "640x480" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (II) RADEON(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (II) RADEON(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) RADEON(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) RADEON(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (II) RADEON(0): Modeline "1600x1200" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) RADEON(0): Modeline "1280x960" 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (II) RADEON(0): Modeline "1152x864" 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (II) RADEON(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) RADEON(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) RADEON(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) RADEON(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) RADEON(0): Modeline "640x480" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (II) RADEON(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (II) RADEON(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) RADEON(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) RADEON(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (II) RADEON(0): Modeline "1600x1200" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) RADEON(0): Modeline "1280x960" 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (II) RADEON(0): Modeline "1152x864" 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (II) RADEON(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video disable montype: 3 disable montype: 2 disable montype: 5 disable montype: 1 disable montype: 3 disable montype: 2 disable montype: 5 init memmap init common init crtc1 init pll1 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xd7ffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc1 restore pll1 restore LVDS enable montype: 2 disable montype: 1 disable montype: 3 disable montype: 5 enable montype: 2 (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) RADEON(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) RADEON(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) RADEON(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) RADEON(0): Modeline "640x480" 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (II) RADEON(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) RADEON(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) RADEON(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (II) RADEON(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) RADEON(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) RADEON(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (II) RADEON(0): Modeline "1600x1200" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (II) RADEON(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) RADEON(0): Modeline "1280x960" 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (II) RADEON(0): Modeline "1152x864" 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (II) RADEON(0): Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video init memmap init common init crtc2 init pll2 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xd7ffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 restore common restore crtc2 restore pll2 finished PLL2 restore dac enable montype: 1 disable montype: 3 disable montype: 5 (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video (II) RADEON(0): I2C device "VGA_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA_DDC:ddc2" removed. (II) RADEON(0): EDID for output VGA-0 (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): DDC Type: 3, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on connector: VGA ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 1ad Serial#: 1112683056 (II) RADEON(0): Year: 2006 Week: 35 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400 at 70Hz (II) RADEON(0): 640x480 at 60Hz (II) RADEON(0): 640x480 at 67Hz (II) RADEON(0): 640x480 at 72Hz (II) RADEON(0): 640x480 at 75Hz (II) RADEON(0): 800x600 at 56Hz (II) RADEON(0): 800x600 at 60Hz (II) RADEON(0): 800x600 at 72Hz (II) RADEON(0): 800x600 at 75Hz (II) RADEON(0): 832x624 at 75Hz (II) RADEON(0): 1024x768 at 60Hz (II) RADEON(0): 1024x768 at 70Hz (II) RADEON(0): 1024x768 at 75Hz (II) RADEON(0): 1280x1024 at 75Hz (II) RADEON(0): 1152x870 at 75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) RADEON(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEON(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: HVDL900806 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2dad0130325242 (II) RADEON(0): 231001030e291f782aee95a3544c9926 (II) RADEON(0): 0f5054bfef80a94081808140714f0101 (II) RADEON(0): 010101010101483f403062b0324040c0 (II) RADEON(0): 130098321100001e000000fd00384b1e (II) RADEON(0): 5111000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 004856444c3930303830360a20200093 (II) RADEON(0): Output VGA-0 connected in RADEONProbeOutputModes (II) RADEON(0): EDID vendor "SAM", prod id 429 (II) RADEON(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) RADEON(0): Printing probed modes for output VGA-0 (II) RADEON(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Modeline "1600x1200"x59.9 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEON(0): Modeline "1280x960"x59.9 101.25 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.7 kHz) (II) RADEON(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1152x864"x74.8 104.00 1152 1224 1344 1536 864 867 871 905 -hsync +vsync (67.7 kHz) (II) RADEON(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEON(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): I2C device "DVI_DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI_DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 0 (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): EDID for output DVI-0 (WW) RADEON(0): DDC2/I2C is not properly initialized (II) RADEON(0): DDC Type: 0, Detected Monitor Type: 0 (II) RADEON(0): Detected Monitor Type: 2 (II) RADEON(0): Output LVDS connected in RADEONProbeOutputModes (II) RADEON(0): Added native panel mode: 1920x1200 (II) RADEON(0): Total number of valid Screen mode(s) added: 0 (II) RADEON(0): Not using default mode "640x350" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "720x400" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "640x480" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "800x600" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1024x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x864" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x960" (hsync out of range) (II) RADEON(0): Not using default mode "1280x960" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1280x1024" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (hsync out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1200" (vrefresh out of range) (II) RADEON(0): Not using default mode "1792x1344" (hsync out of range) (II) RADEON(0): Not using default mode "1792x1344" (vrefresh out of range) (II) RADEON(0): Not using default mode "1856x1392" (hsync out of range) (II) RADEON(0): Not using default mode "1856x1392" (vrefresh out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "832x624" (vrefresh out of range) (II) RADEON(0): Not using default mode "1152x768" (vrefresh out of range) (II) RADEON(0): Not using default mode "1400x1050" (hsync out of range) (II) RADEON(0): Not using default mode "1400x1050" (vrefresh out of range) (II) RADEON(0): Not using default mode "1600x1024" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Not using default mode "2048x1536" (vrefresh out of range) (II) RADEON(0): Printing probed modes for output LVDS (II) RADEON(0): Modeline "1920x1200"x60.0 161.75 1920 2016 2048 2184 1200 1202 1208 1235 (74.1 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Output S-video disconnected (II) RADEON(0): EDID for output S-video From nicolas.mailhot at laposte.net Thu Dec 6 08:02:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Dec 2007 17:02:13 +0100 (CET) Subject: [PATCH] Fix XKB options passed from HAL Message-ID: <26593.192.54.193.53.1196956933.squirrel@rousalka.dyndns.org> Le Jeu 6 d?cembre 2007 16:24, Nicolas Mailhot a ?crit : > However, just like you need to select a logical keyboard layout for > the console, you'll still need to select a logical layout for X (I Also, right now the console and xorg do not share the same logical layout database, so propagating layout settings from the console to X (or inversely) would probably require making the console use xkeyboard-config data. A less ideal mode would be to deploy xkeyboard-config to console translators, and I think some exist, but major distributions such as Red Hat do not use them today. -- Nicolas Mailhot From alan.coopersmith at sun.com Thu Dec 6 08:39:59 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Thu, 06 Dec 2007 08:39:59 -0800 Subject: Looking for XRender examples In-Reply-To: <27956182.355981196937849978.JavaMail.weblogic@epml07> References: <27956182.355981196937849978.JavaMail.weblogic@epml07> Message-ID: <475825DF.3050504@sun.com> KAMALNEET SINGH wrote: > Clemens Eisserer wrote: >> Hello, >> >> Does anybody know tutorials for learning the XRender API? >> I found many tutorials for X11's primitive drawing but for XRender >> there is almost no developer documentation available. >> > > You can look at xclock code, and also the code of Render-related Xft functions it calls. xlogo as well. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From keithp at keithp.com Thu Dec 6 09:13:27 2007 From: keithp at keithp.com (Keith Packard) Date: Thu, 06 Dec 2007 09:13:27 -0800 Subject: Looking for XRender examples In-Reply-To: <27956182.355981196937849978.JavaMail.weblogic@epml07> References: <27956182.355981196937849978.JavaMail.weblogic@epml07> Message-ID: <1196961207.5122.61.camel@koto.keithp.com> On Thu, 2007-12-06 at 10:44 +0000, KAMALNEET SINGH wrote: > * For rendering, xclock calls XRenderCompositeDoublePoly, But, please avoid using this function as it doesn't work right in most cases. Treat the XRender library as a thin protocol wrapper, as cairo does. -- keith.packard at intel.com -------------- 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 twxorg at gmail.com Thu Dec 6 09:44:39 2007 From: twxorg at gmail.com (tommy watson) Date: Thu, 6 Dec 2007 12:44:39 -0500 Subject: xf86-video-ati: AMD64 RV350 tv-out Message-ID: <54337fa00712060944y891b77ud8bafc6fc16cd1cc@mail.gmail.com> Hi, I am also having an issue with an amd64 system, the tv-out works fine on my system until I play a video in mythtv, at that point a blue rectangle appears on the screen the size of the video. I am running gentoo x11-base/xorg-server-1.3.0.0-r2 and x11-drivers/xf86- video-ati-6.7.196 or x11-drivers/xf86-video-ati-9999 (git from yesterday) 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA]) Is this a known issue? Is there anything I can do to help test/fix this? Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dberkholz at gentoo.org Thu Dec 6 10:06:03 2007 From: dberkholz at gentoo.org (Donnie Berkholz) Date: Thu, 6 Dec 2007 10:06:03 -0800 Subject: Best manual-to-automatic ChangeLog commit? In-Reply-To: References: <20071206024442.GF3614@fooishbar.org> Message-ID: <20071206180603.GU29076@supernova> On 09:44 Thu 06 Dec , James Cloos wrote: > >>>>> "Daniel" == Daniel Stone writes: > > Daniel> Just take the Makefile.am hook from xserver. > > I take it these additions are also required?: > > -EXTRA_DIST = ... > +EXTRA_DIST = ... ChangeLog > +MAINTAINERCLEANFILES = ChangeLog > +dist-hook: ChangeLog You might need a PHONY rule as well, otherwise you won't regenerate the ChangeLog if the file already exists and you end up distributing a stale ChangeLog. Thanks, Donnie From cworth at cworth.org Thu Dec 6 10:11:05 2007 From: cworth at cworth.org (Carl Worth) Date: Thu, 06 Dec 2007 10:11:05 -0800 Subject: Looking for XRender examples In-Reply-To: <27956182.355981196937849978.JavaMail.weblogic@epml07> References: <27956182.355981196937849978.JavaMail.weblogic@epml07> Message-ID: <87tzmvels6.wl%cworth@cworth.org> On Thu, 06 Dec 2007 10:44:10 +0000 (GMT), KAMALNEET SINGH wrote: > Some notes on xclock's usage of XRender: > * Destination surface is created using XftDrawPicture. > * Source surface is created using > XftDrawSrcPicture. XftDrawSrcPicture uses XCreatePixmap to create a > 1x1 pixmap and then uses it as a drawable to create a new Picture. And > then uses XRenderFillRectangle to draw the color onto it. For an application using XRender "only" you can use XRenderCreatePicture instead of relying on the Xft library as well. As soon as you want to render text through XRender, you will quickly find that there's quite a bit of work required to manage everything necessary. At that point, you might find it quite helpful to use an existing library. Originally, Xft was the recommended library, (and should still work fine, of course). But today active development has instead moved to cairo for XRender-based rendering of text. > * For rendering, xclock calls XRenderCompositeDoublePoly, with some > * non-NULL mask format (A8 in my test run). For non-null > * mask-format, Render specification says that first a temporary > * alpha picture is created and rasterization done on it. That function was a mistake in the XRender library. There is no protocol support for passing a polygon of doubles, so instead this function tessellates and makes a CompositeTrapezoids request. But the tessellation it does is extremely inefficient and often wrong. So better would be to do your own tessellation, (or use a library like cairo that will do tessellation for you). I hope that helps, -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jbarnes at virtuousgeek.org Thu Dec 6 10:41:27 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 6 Dec 2007 10:41:27 -0800 Subject: Output problems with 945GM In-Reply-To: <4757FF1F.4060500@kaasa.com> References: <4757FF1F.4060500@kaasa.com> Message-ID: <200712061041.27890.jbarnes@virtuousgeek.org> On Thursday, December 06, 2007 5:54 am Matteo Brusa wrote: > Hi, > i have some HDTV configuration issues with my 945GM based pc, i hope i'm in > the right place to ask. I'm running Ubuntu 7.10 and therefore the intel > driver version 2:2.1.1-0ubuntu9. > > VGA output > The VGA output works great, it uses the 1360x768 resolution when plugged to > an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying to get > either HDMI (with DVI adapter cable) or component running. > LDVS > In X, LVDS is always enabled although i have no LCD screen. I tried "xrandr > --ouput LDVS --off" without success, and the intel module does not support > any xorg.conf option to shut it off. Could this be the reason why xvidtune > always shows 1024x768 and not the actual screen value? Component > I always get 1024x768, no matter which Modeline i specify. Any suggestion? You actually can disable it: Section "Monitor" Identifier "Bogus LCD" Option "ignore" "true" EndSection Section "Driver" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "Unknown Board" Option "Monitor-LVDS" "Bogus LCD" EndSection And since we've been getting so many reports about this stuff and always end up pointing people at http://www.intellinuxgraphics.org/dualhead.html, I think I'll update the man page with some more detail... > TDMS-1 > I got 1280x768 working, with noticeable overscan. How can i use the same > 1360x768 with DVI, or get rid of the overscan? What's the output of 'xrandr'? > > I also tried to disable DDC; in this case i cannot set any video mode with > randr. Do i need to use the 915resolution tool, or it's not relevant > anymore? It's not relevant anymore and should generally be avoided... > What is the output name for the component: TDMS-1, VGA? I'm not sure what you mean here, TMDS-1 and VGA are separate outputs... > Last question: X -verbose says "(==) intel(0): VideoRam: 262144 KB". Does > it mean that it allocates 256 megs for the as video memory? It means it can allocate up to 256M for video memory as needed. It doesn't necessarily allocate all of that by default though... Jesse From vladc6 at yahoo.com Thu Dec 6 10:39:37 2007 From: vladc6 at yahoo.com (Vlad) Date: Thu, 6 Dec 2007 10:39:37 -0800 (PST) Subject: Looking for XRender examples In-Reply-To: <87tzmvels6.wl%cworth@cworth.org> Message-ID: <57859.98998.qm@web54409.mail.yahoo.com> --- Carl Worth wrote: > On Thu, 06 Dec 2007 10:44:10 +0000 (GMT), KAMALNEET SINGH wrote: > > Some notes on xclock's usage of XRender: > > * Destination surface is created using XftDrawPicture. > > * Source surface is created using > > XftDrawSrcPicture. XftDrawSrcPicture uses XCreatePixmap to > create a > > 1x1 pixmap and then uses it as a drawable to create a new > Picture. And > > then uses XRenderFillRectangle to draw the color onto it. > > For an application using XRender "only" you can use > XRenderCreatePicture instead of relying on the Xft library as well. > > As soon as you want to render text through XRender, you will quickly > find that there's quite a bit of work required to manage everything > necessary. At that point, you might find it quite helpful to use an > existing library. Originally, Xft was the recommended library, (and > should still work fine, of course). But today active development has > instead moved I highly recommend Qt for high-performance text and graphics rendering. Qt has a very intuitive and mature C++ API and bindings for other languages (Python, Java, Ruby, etc). It is actively developed as open source software and supported commercially. http://trolltech.com/products/qt http://doc.trolltech.com/4.3/index.html Vlad ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From linuxhippy at gmail.com Thu Dec 6 10:49:30 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 6 Dec 2007 19:49:30 +0100 Subject: Looking for XRender examples In-Reply-To: <57859.98998.qm@web54409.mail.yahoo.com> References: <87tzmvels6.wl%cworth@cworth.org> <57859.98998.qm@web54409.mail.yahoo.com> Message-ID: <194f62550712061049u335c6772t5d86338f303ebad0@mail.gmail.com> Hello again, Thanks again for all the suggestions, I know cairo would make my life much easier but I guess the software-project I plan to work on is afraid of any additional dependency... I am most afraid of the text-stuff - is Xt present by default on systems which have Xorg installed ... I don't know if there's something like "core X libraries" - but if yes - does Xt belong to that "group"? > I highly recommend Qt for high-performance text and graphics > rendering. I really like QT (much more than GTK), but its really over-featured for my needs. Thanks a lot, lg Clemens From xavier.bestel at free.fr Thu Dec 6 07:43:10 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Thu, 06 Dec 2007 16:43:10 +0100 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <53326.192.54.193.53.1196954652.squirrel@rousalka.dyndns.org> References: <53326.192.54.193.53.1196954652.squirrel@rousalka.dyndns.org> Message-ID: <1196955790.28027.9.camel@skunk.anacadf.mentorg.com> On Thu, 2007-12-06 at 16:24 +0100, Nicolas Mailhot wrote: > Le Jeu 6 d?cembre 2007 16:06, Xavier Bestel a ?crit : > > Hi, > > > > I didn't really follow that discussion, but in the end would a non-US > > keyboard work automagically (without specific sections in xorg.conf), > > provided the linux console is already properly configured ? > > evdev takes care of the low-level stuff. So everything autoconfigured > at the kernel (module) level would work the same in xorg. The kernel > hides if a keyboard is PS/2, usb... hotplugged or not, and you'd get > the same level of support in xorg. The same keyboard would have the > same effect if it's plugged as PS/2 or USB (not the case right now). > > However, just like you need to select a logical keyboard layout for > the console, you'll still need to select a logical layout for X (I > think there are plans to hook a layout chooser in gdm). So I'll rephrase my question: will X be able to choose a layout automatically, just by looking at what the kernel console is already doing ? After all the info is already there, somewhere. Xav From bart at cs.pdx.edu Thu Dec 6 11:40:33 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Thu, 06 Dec 2007 11:40:33 -0800 Subject: Website maintenance volunteers? In-Reply-To: Your message of "Thu, 06 Dec 2007 10:57:45 GMT." <20071206105745.GH3614@fooishbar.org> References: <20071206105745.GH3614@fooishbar.org> <47570BA4.8020504@sun.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> Message-ID: <200712061940.lB6JeXiN023371@wezen.cs.pdx.edu> In message <20071206105745.GH3614 at fooishbar.org> you wrote: > On Thu, Dec 06, 2007 at 12:54:36AM -0800, Barton C Massey wrote: > > Can somebody in the know please give a clear description of > > what our current Wiki editing rules are? > > FrontPage: only a limited subset of people (historical reasons) > everything else: everyone who's registered Thanks! "Everything else" includes the project wikis, I assume. I did not know/remember this. Do folks have thoughts on non-member wiki edits? Should non-members have edit permission only on a specific subsite (or not at all)? Should we have a separate registration review for folks who sign up to edit the wiki? Or should we just use standard wikispam-fighting techniques and hope for the best? Bart From bart at cs.pdx.edu Thu Dec 6 11:47:03 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Thu, 06 Dec 2007 11:47:03 -0800 Subject: Website maintenance volunteers? In-Reply-To: Your message of "Fri, 07 Dec 2007 00:50:01 +1030." <47580511.30403@clearchain.com> References: <47580511.30403@clearchain.com> <47570BA4.8020504@sun.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> <20071206105745.GH3614@fooishbar.org> Message-ID: <200712061947.lB6Jl38O023740@wezen.cs.pdx.edu> In message <47580511.30403 at clearchain.com> you wrote: > Whilst I agree MW has a much richer feature set, Moin > seems nicely suited to wiki farms. There's trade offs > either way. MW is much easier to extend though. I've not > looked at Moin for extendability. One thing to note is MW > has no concept of acl's. Moin does. Though based on the > current wiki rules that's not an issue. In my mind, the conversion to MediaWiki is a moot point unless somebody has some plan for solving the content conversion problem. As far as I know, there are no automated tools for this. I haven't heard anybody speak up with a viable plan for how it would be done by hand, either, which seems to me to be a huge amount of work with substantial risks. Bart From hcb at chaoticmind.net Thu Dec 6 11:40:43 2007 From: hcb at chaoticmind.net (Helge Bahmann) Date: Thu, 6 Dec 2007 20:40:43 +0100 Subject: Looking for XRender examples In-Reply-To: <194f62550712061049u335c6772t5d86338f303ebad0@mail.gmail.com> References: <87tzmvels6.wl%cworth@cworth.org> <57859.98998.qm@web54409.mail.yahoo.com> <194f62550712061049u335c6772t5d86338f303ebad0@mail.gmail.com> Message-ID: <200712062040.43933.hcb@chaoticmind.net> Hello and sorry for tuning in late... I have several sample programs and quite a bit of documentation about Xrender, its model and how to use it written up for my students (mostly in german though); if you are interested I can collect and tidy them up (when I asked last time on this mailing list there was zero interest apparently) > Thanks again for all the suggestions, I know cairo would make my life > much easier but I guess the software-project I plan to work on is > afraid of any additional dependency... > > I am most afraid of the text-stuff - is Xt present by default on > systems which have Xorg installed ... I don't know if there's > something like "core X libraries" - but if yes - does Xt belong to > that "group"? Actually "simple" text rendering without Xft isn't that bad, for example: http://www.chaoticmind.net/~hcb/xrender/rendertext.c uses just freetype and Xrender and is as minimal as it gets (unless you want to provide your own glyph shapes, in which case you can also ditch freetype); maybe this suits your purpose Best regards, Helge Bahmann From linuxhippy at gmail.com Thu Dec 6 12:06:17 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 6 Dec 2007 21:06:17 +0100 Subject: Looking for XRender examples In-Reply-To: <200712062040.43933.hcb@chaoticmind.net> References: <87tzmvels6.wl%cworth@cworth.org> <57859.98998.qm@web54409.mail.yahoo.com> <194f62550712061049u335c6772t5d86338f303ebad0@mail.gmail.com> <200712062040.43933.hcb@chaoticmind.net> Message-ID: <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> Hello Helge, > I have several sample programs and quite a bit of documentation about Xrender, > its model and how to use it written up for my students (mostly in german > though); if you are interested I can collect and tidy them up (when I asked > last time on this mailing list there was zero interest apparently) That would be exactly what I was seraching for, perfect. By the way I am from Austria so german documentation would be awesome :) > Actually "simple" text rendering without Xft isn't that bad, for example: > > http://www.chaoticmind.net/~hcb/xrender/rendertext.c > > uses just freetype and Xrender and is as minimal as it gets (unless you want > to provide your own glyph shapes, in which case you can also ditch freetype); > maybe this suits your purpose Great! It does exactly what I searched for. Thanks :) Thanks a lot, lg Clemens From cloos+pdx-xorg at jhcloos.com Thu Dec 6 12:32:45 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Thu, 06 Dec 2007 20:32:45 +0000 Subject: Best manual-to-automatic ChangeLog commit? In-Reply-To: <20071206180603.GU29076@supernova> (Donnie Berkholz's message of "Thu, 6 Dec 2007 10:06:03 -0800") References: <20071206024442.GF3614@fooishbar.org> <20071206180603.GU29076@supernova> Message-ID: >>>>> "Donnie" == Donnie Berkholz writes: Donnie> You might need a PHONY rule as well, otherwise you won't Donnie> regenerate the ChangeLog if the file already exists and Donnie> you end up distributing a stale ChangeLog. OK. Several converted repos lack the PHONY line. In xorg/*/* ? including the two I just converted ? 27 lack a PHONY. And 256 still have a static ChangeLog file. I?ll add and push the missing PHONY lines now. xorg/app/xmag is, I think, an easy-to-remember choice to be a reference commit. Cf: http://cgit.freedesktop.org/xorg/app/xmag/diff/Makefile.am?id=80faa002 which shows an append of this to the Makefile.am: ,----[ reference_changelog_makefile_append ] | | EXTRA_DIST += ChangeLog | MAINTAINERCLEANFILES = ChangeLog | | .PHONY: ChangeLog | | ChangeLog: | (GIT_DIR=$(top_srcdir)/.git git-log > .changelog.tmp && mv .changelog.tmp ChangeLog; rm -f .changelog.tmp) || (touch ChangeLog; echo 'git directory not found: installing possibly empty changelog.' >&2) | | dist-hook: ChangeLog `---- -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From alan.coopersmith at sun.com Thu Dec 6 13:51:12 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Thu, 06 Dec 2007 13:51:12 -0800 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <1196955790.28027.9.camel@skunk.anacadf.mentorg.com> References: <53326.192.54.193.53.1196954652.squirrel@rousalka.dyndns.org> <1196955790.28027.9.camel@skunk.anacadf.mentorg.com> Message-ID: <47586ED0.10005@sun.com> Xavier Bestel wrote: > So I'll rephrase my question: will X be able to choose a layout > automatically, just by looking at what the kernel console is already > doing ? After all the info is already there, somewhere. We do that on Solaris, by using a table mapping kernel layouts to XKB layouts in the kbd driver, but have never gotten around to upstreaming that code (and I'm not sure it would help any other systems). The part I've never gotten around to figuring out is how to get the kbd driver to change the XKB layout when we get a keyboard-layout-changed event from the kernel (either because someone used the kernel-layout-change tool or hotplugged in a keyboard of different layout). -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From saschahlusiak at arcor.de Thu Dec 6 15:37:31 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Fri, 7 Dec 2007 00:37:31 +0100 Subject: [ANNOUNCE] xf86-input-joystick-1.3.1 Message-ID: <200712070037.36898.saschahlusiak@arcor.de> Release 1.3.1 of the joystick input driver for X.Org-7.3 git tag: xf86-input-joystick-1.3.1 This release adds support for evdev devices (/dev/input/event*) but if this fails, the linux joystick interface is tried and, if available, the bsd usbhid interface (so in FreeBSD the linux joystick interface can be used now with the same binary). The evdev backend makes it possible to hotplug the joystick driver from hal; an example policy file is included in the tarball. Use with care. Changes since 1.3.0: - Add check for kbproto in configure script - configure.ac: Checking for available backends instead of OS - Added backend selection code (in order: evdev, linux joystick, bsd usbhid) - Fixed implicit declaration warnings because of missed header files - Mentioned multiple backends in man page - New: evdev backend - Return NULL on device configure fail instead of an unconfigured device, which made X segfault - Fixed default button mappings - Looking for Path parameter besides Device (used by HAL+input hotplug) - Added example hal policy file for input hotplugging of a joystick - Mentioned hotplugging and hal policy in man page md5sum: ff25ea697cfa1570cc28f4b9cf9c761f xf86-input-joystick-1.3.1.tar.bz2 d61333fcbc99f61888df3e2eb71d962a xf86-input-joystick-1.3.1.tar.gz sha1sum: e28590951aaebee5089a0d9abd8d22b900e9ee22 xf86-input-joystick-1.3.1.tar.bz2 79360faad77b478377ca0d26fa9fea37f06eac89 xf86-input-joystick-1.3.1.tar.gz http://xorg.freedesktop.org/archive/individual/driver/xf86-input-joystick-1.3.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-joystick-1.3.1.tar.gz Regards, Sascha -------------- 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 tiagomatos at gmail.com Thu Dec 6 15:47:25 2007 From: tiagomatos at gmail.com (Rui Tiago Matos) Date: Thu, 6 Dec 2007 23:47:25 +0000 Subject: Looking for XRender examples In-Reply-To: <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> References: <87tzmvels6.wl%cworth@cworth.org> <57859.98998.qm@web54409.mail.yahoo.com> <194f62550712061049u335c6772t5d86338f303ebad0@mail.gmail.com> <200712062040.43933.hcb@chaoticmind.net> <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> Message-ID: On 06/12/2007, Clemens Eisserer wrote: > > I have several sample programs and quite a bit of documentation about Xrender, > > its model and how to use it written up for my students (mostly in german > > though); if you are interested I can collect and tidy them up (when I asked > > last time on this mailing list there was zero interest apparently) > That would be exactly what I was seraching for, perfect. By the way I > am from Austria so german documentation would be awesome :) This seems the kind of content that could (should even, if the author agrees) be put on the wiki, even if in german, someone else could then translate it. Rui From pcjc2 at cam.ac.uk Thu Dec 6 16:52:52 2007 From: pcjc2 at cam.ac.uk (Peter Clifton) Date: Fri, 07 Dec 2007 00:52:52 +0000 Subject: [ANNOUNCE] xf86-input-joystick-1.3.1 In-Reply-To: <200712070037.36898.saschahlusiak@arcor.de> References: <200712070037.36898.saschahlusiak@arcor.de> Message-ID: <1196988772.5846.49.camel@pcjc2lap> On Fri, 2007-12-07 at 00:37 +0100, Sascha Hlusiak wrote: > Release 1.3.1 of the joystick input driver for X.Org-7.3 > > git tag: xf86-input-joystick-1.3.1 > > > This release adds support for evdev devices (/dev/input/event*) but if this > fails, the linux joystick interface is tried and, if available, the bsd > usbhid interface (so in FreeBSD the linux joystick interface can be used now > with the same binary). The evdev backend makes it possible to hotplug the > joystick driver from hal; an example policy file is included in the tarball. > Use with care. How does this stand with 6 Axis devices like the SpaceNavigator from 3Dconnexion? I want to use this device for manipulating 3D objects in applications (the ones I'm working on at lest). The question I have, is really.. what is the right model to use.. The device (USB version at least) appears as a /dev/input/event* device under linux. I can access that directly in the app, but somehow I feel I should be using an Xorg joystick driver, or perhaps the 3Dconnexions SDK (ok, no.. that looks horrid!) According to this forum post (which I'll quote some of): http://www.3dconnexion.com/forum/viewtopic.php?t=336&postdays=0&postorder=asc&start=0 "" The original HID_Descriptor from SpaceNavigator is at 99% a Joystick one. [...] Here are the first bytes of this descriptor: Code: /* Space Nav */ 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x08, // USAGE (Undefined) 0xa1, 0x01, // COLLECTION (Application) 0xa1, 0x00, // COLLECTION (Physical) 0x85, 0x01, // REPORT_ID (1) 0x16, 0x0c, 0xfe, // LOGICAL_MINIMUM (-500) 0x26, 0xf4, 0x01, // LOGICAL_MAXIMUM (500) 0x36, 0x00, 0x80, // PHYSICAL_MINIMUM (-32768) 0x46, 0xff, 0x7f, // PHYSICAL_MAXIMUM (32767) The second line : 0x09, 0x08 ??? change it to 0x09,0x04 and u have a Joystick ???. With those 2 bits changed, SpaceNavigator is seen as a Joystick without any driver. "" Does the joystick driver seem the right place to try and implement support for this device? What would it look like to the application wanting to use the joystick? (If you can point to any trivial examples of X11 apps using a joystick with this driver, I'd appreciate it. I don't own a conventional joystick, and am not a gamer, so can't think where to start in Linux really!) Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) From pcpa at mandriva.com.br Thu Dec 6 17:14:33 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Thu, 06 Dec 2007 23:14:33 -0200 Subject: X packages Message-ID: <20071206231433.ayjebx6wxlz48gs0@webmail.conectiva.com.br> Hi, Just cc-ing x-packagers as the list has very low traffic, and maybe not all "x packagers" are subscribed. In this email I will attempt to explain a "way of packaging X" for Mandriva Linux, that I have almost finished implementing; and hopefully help others, or get some feedback about possible mistakes I am doing, or even better, get some consensus about some problems that may be common to all distros regardless of operating system. All distros have some custom changes, or changes that are not considered upstream ready because it is a work in progress, or possibly some extra value added to the specific distro, or some operating system specific feature interface. For Mandriva, I am mirroring most of anongit.freedesktop.org. And I am working on these branches, that I update based on server-1.4-branch, and later may adjust for other "stable" branch: * mandriva Has changes that are considered "upstream quality" and hopefully will be added to upstream some day. And is expected to br easy for upstream commiters to pull code from this brach. * mandriva+custom Not really "upstream ready" or qualified. In the case of this specific branch, it has things like a "blue background" instead of the default "stippled" background, etc, and one patch that I am not "fully happy" with it yet, that handles keyboard events using SIGIO and allows killing an application or the X Server when Ctrl+Alt+Backspace is pressed. It kills the client if handling a client request, or the X Server if not handling a client request. This doesn't prevent all types of crashes, and if some code blocks SIGIO before entering an infinite loop, it does nothing... * mandriva+gpl This probably will not enter upstream. Currently it has some Debian patches/customizations and Xvnc code. It also has some Mandriva specific GPL code, and new code, that doesn't touch existing files, that I am implementing is also going only to this branch. Any gpl code can only enter this branch, at least until mainstream accepts GPL code. This is also the branch that will be used for Mandriva packages. Since Mandriva uses rpm, and I am mirroring "upstream" I also use git-archive to generate a tar dist file; this may require something like autoreconf before ./configure, but the patches already require it to regenerate some ".in" files, therefore there is no reason to store files not in the repository in the tar file, this also reduces some Mb in the tar file, and git-format-patch to generate the patches, and maybe some ``git-magic'' for more "pleasant" patches that address a single problem/fix at a time, and doesn't require a specific branch for it. Things that are "work in progress": I am considering to add a tag in the repository for every new package, but unless I automatize it, this may not be implemented. One of my patches, that is in the "main" mandriva branch (and also present in mandriva+custom and mandriva+gpl) is a change to compile most code with -fvisiblity=hidden. I have it already working, but I did most of it in a "hard" way, analyzing missing symbols, following macro definitions for symbols that are defined by macros, fixing/rewriting things like "#define foo_func ((type (*)(foo_args)) LoaderSymbol("foo_func"))", "ansifition" of some files (they already have ANSI declarations), and fixing a few problems like a C file with a statement like "extern type some_func(some_args);" but the "some_func" function doesn't exist anymore, so I am putting declarations in header files, etc. Today I wrote a perl script that will use "objdump -t -T -w" for every library/module, and use ldd to "augment" the list of available symbols on the shared objects. After parsing the output of objdump, the script knows where symbols are defined, the type of the symbol and where it is required, as well as warn if an symbol is "hidden" in one shared object but required by another, a "minor" warning if a symbol is exported but not used by any modules, and a warning about symbol clashes, a example is stub symbols in libXfont that the X Server implements another version of the symbol; if this symbol is made hidden, things will crash badly as the stub in libXfont will be used. One thing that I still did not stop to start writing code is inter module dependency. At first I considered using something like the makedepend program from monolithic X Server build, or figure a way to create a "sign" for every symbol, and cross-reference it to know if a module needs to be rebuilt. Maybe GNU "autotools" already have something similar to makedepend that I am missing. I don't want to make a new release of every module because someone added an ErrorF in the X Server code or some library, but I want an easy "automatable" method of detecting when a module needs to be rebuilt, due to some change in some structure, function return type or arguments, etc. If someone already have something to resolve this problem, that is a side effect of converting the "monolithic" X Server in a huge amount of different packages, I would like to know :-) Otherwise I am also considering to analyze how the Linux kernel handles dependencies, and symbol "signatures" and try to implement something similar. Thanks, Paulo From mailinglists at who-t.net Thu Dec 6 19:02:18 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Fri, 07 Dec 2007 13:32:18 +1030 Subject: New input hotness not happening for 1.5 In-Reply-To: <20071205192424.GA3614@fooishbar.org> References: <20071205192424.GA3614@fooishbar.org> Message-ID: <4758B7BA.1080602@who-t.net> Daniel Stone wrote: > Despite putting in the XDS2007 notes that input transformation, XKB 2 > and Xi 2 would happen for 1.5, they just aren't going to, to be honest. > Doing these sensibly requires some fairly sweeping changes to the way we > _process_ events (input-hotplug was all about how we generate them) that > also requires sorting out the interactions with MPX, particularly the > grab bits, which are going to be tough. That and I badly need a break. FWIW, here's a quick update on the state of the "rest of XI2" (i.e. MPX). First, MPX will not happen for 1.5, but 1.6 may be realistic. The most recent change added the device hierarchy as put forward by Keith Packard at the XDS07. This allows you to create and remove new cursors and keyboard foci (master devices) at runtime and attach the physical devices (slave devices) to any of these. And change them around as you need. By default, the devices are all assigned to a single cursor/focus which resembles exactly the current behaviour of the server. this is a good thing, unless you know mpx is there and start using it, it's invisible. Aside from that, it's seems to be working well so far but as we have seen from 1.4 if it is working on one box doesn't mean it caters for all configurations. I _think_ most of the grab-related issues are sorted out, although more testing is required. One missing thing is that I need to go through all extensions and replicate their APIs with device-specific ones if possible. XTest comes to my mind here. The blob stuff (i.e. touch screen support) is in a decent state now too, allowing clients to query devices for the support etc. I'm quite keen to merge it into mpx. can I please get a heads-up whether we want that in the first version of mpx? What I would like to see is people actually trying to write some apps with multiple devices. The number of these apps is still so limited that considering the API stable is a bit of a speculation. Cheers, Peter From onetwojojo at gmail.com Thu Dec 6 21:06:32 2007 From: onetwojojo at gmail.com (JoJo jojo) Date: Fri, 7 Dec 2007 10:36:32 +0530 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: <20071206021918.GE3614@fooishbar.org> References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> <20071205181040.GC2177@fooishbar.org> <20071205235327.GC3544@skynet.be> <20071206021918.GE3614@fooishbar.org> Message-ID: <226dee610712062106g240d31b2vd93bd98de9d843be@mail.gmail.com> Perfect soln. to our problems !!! Lets handle this problem on the serverside 2 Mailing lists - (1 with [xorg] & 1 without [xorg]) plus we need 1 reply-to-mailinglist id. Mailing lists - with [xorg] Accept/Allow [xorg], if missing apply [xorg] to subject (only accept email from reply-to-mailinglist id) Mailing lists - without [xorg] Dis-allow [xorg], if present remove [xorg] from subject (only accept email from reply-to-mailinglist id) Content mirroring All replies to any topic on the above mailinglists are sent indirectly via reply-to-mailinglist id (which in turn send it to both of the above mailing lists) to achieve synchronization the down side:- *further confusion for bug reporters (which list do i report it on?) *fdo resources utilization & efficiency is hurt (huge impact) * gmail conversations may break (small impact) the upside:- * peaceful co-existence -Jojo On 12/6/07, Daniel Stone wrote: > On Thu, Dec 06, 2007 at 12:53:27AM +0100, Luc Verhaegen wrote: > > My guess is that the same logic does apply when considering video > > drivers: "Buy a new videocard, like everyone else, or shut up." > > > > This of course does gloss over the fact that "everyone else" includes > > those that were already forced to buy from the big three remaining > > players with the same reasoning. > > If ever anyone needed evidence that this discussion was now utterly > pointless -- here it is. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHV1wmUVYB1rKAgJQRAuRyAKDRgie9vlrzVR0qfH2ZVkOJEDOOTwCeNqZc > yu2aZBN5tnADQ7kQ4x5Pbgs= > =fCgt > -----END PGP SIGNATURE----- > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From airlied at gmail.com Thu Dec 6 21:46:06 2007 From: airlied at gmail.com (Dave Airlie) Date: Fri, 7 Dec 2007 15:46:06 +1000 Subject: radeon zaphod the return... Message-ID: <21d7e9970712062146l37db83cfv3907d938d75a0c0a@mail.gmail.com> Okay if you take a look at the zaphod-lolz branch http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=zaphod-lolz I've managed to bring back zaphod without majorly impacting on the driver, randr-1.2 actually makes it quite easy to implement. Each head in theory still exports randr-1.2 interfaces in non-Xinerama mode.... I'd like to merge this into master quickly and also into atombios-support so I can do this on r500 class cards. Dave. From alexdeucher at gmail.com Thu Dec 6 22:42:45 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 7 Dec 2007 01:42:45 -0500 Subject: radeon zaphod the return... In-Reply-To: <21d7e9970712062146l37db83cfv3907d938d75a0c0a@mail.gmail.com> References: <21d7e9970712062146l37db83cfv3907d938d75a0c0a@mail.gmail.com> Message-ID: On Dec 7, 2007 12:46 AM, Dave Airlie wrote: > Okay if you take a look at the zaphod-lolz branch > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=zaphod-lolz > > I've managed to bring back zaphod without majorly impacting on the > driver, randr-1.2 actually makes it quite easy to implement. > > Each head in theory still exports randr-1.2 interfaces in non-Xinerama mode.... > > I'd like to merge this into master quickly and also into > atombios-support so I can do this on r500 class cards. Looks good to me. Looks good; minimally intrusive. I can't test for a few days however. Alex From alexdeucher at gmail.com Thu Dec 6 22:58:11 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 7 Dec 2007 01:58:11 -0500 Subject: xf86-video-ati: AMD64 RV350 tv-out In-Reply-To: <54337fa00712060944y891b77ud8bafc6fc16cd1cc@mail.gmail.com> References: <54337fa00712060944y891b77ud8bafc6fc16cd1cc@mail.gmail.com> Message-ID: On Dec 6, 2007 12:44 PM, tommy watson wrote: > Hi, > I am also having an issue with an amd64 system, the tv-out works fine on > my system until I play a video in mythtv, at that point a blue rectangle > appears on the screen the size of the video. > > I am running gentoo x11-base/xorg- server-1.3.0.0-r2 and > x11-drivers/xf86-video-ati-6.7.196 or x11-drivers/xf86-video-ati-9999 (git > from yesterday) > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon > 9600] (prog-if 00 [VGA]) > > Is this a known issue? Is there anything I can do to help test/fix this? The video overlay only works on one crtc at a time. In dualhead configurations, the overlay will follow the window. In clone mode you have to pick which crtc you want to use the overlay with. use a tool like xvattr to switch the crtc used by the overlay. Possible values: -1 auto, 0 crtc0, 1, crtc1. xvattr -a XV_CRTC -v 1 Alex From solca at guug.org Thu Dec 6 23:18:23 2007 From: solca at guug.org (Otto Solares) Date: Fri, 7 Dec 2007 01:18:23 -0600 Subject: radeon: incorrect crtc for external LCD on VGA-0 Message-ID: <20071207071823.GA16163@guug.org> Hi! Video card on x86 laptop: ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) I used to have an old external CRT monitor attached to the VGA-0 connector and the command `xrand --output LVDS --off` would correctly turn off the laptop's LCD so I can work in the external without having both monitors powered-on. Problem now is that I buy a new external LCD monitor and the above command would turn off both the new LCD and the laptop's LCD. But when `xrandr --output VGA-0 --crtc 0` everything works as expected so I pressume is a bug in the crtc detection when a LCD is attached in the VGA-0 connector both monitors are driven by the same crtc. As I said, plugging the CRT monitor doesn't exhibit this problem. Running latest Debian Sid (X Server 1.4.0) and git radeon driver. -otto From alexdeucher at gmail.com Thu Dec 6 23:37:05 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 7 Dec 2007 02:37:05 -0500 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <20071207071823.GA16163@guug.org> References: <20071207071823.GA16163@guug.org> Message-ID: On Dec 7, 2007 2:18 AM, Otto Solares wrote: > Hi! > > Video card on x86 laptop: > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > I used to have an old external CRT monitor attached to the VGA-0 > connector and the command `xrand --output LVDS --off` would > correctly turn off the laptop's LCD so I can work in the external > without having both monitors powered-on. > > Problem now is that I buy a new external LCD monitor and the > above command would turn off both the new LCD and the laptop's > LCD. > > But when `xrandr --output VGA-0 --crtc 0` everything works as > expected so I pressume is a bug in the crtc detection when a > LCD is attached in the VGA-0 connector both monitors are driven > by the same crtc. As I said, plugging the CRT monitor doesn't > exhibit this problem. > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. Please file a bug (https://bugs.freedesktop.org) and attach your xorg log and config. Alex From alexdeucher at gmail.com Thu Dec 6 23:38:57 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 7 Dec 2007 02:38:57 -0500 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <20071207071823.GA16163@guug.org> References: <20071207071823.GA16163@guug.org> Message-ID: On Dec 7, 2007 2:18 AM, Otto Solares wrote: > Hi! > > Video card on x86 laptop: > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > I used to have an old external CRT monitor attached to the VGA-0 > connector and the command `xrand --output LVDS --off` would > correctly turn off the laptop's LCD so I can work in the external > without having both monitors powered-on. > > Problem now is that I buy a new external LCD monitor and the > above command would turn off both the new LCD and the laptop's > LCD. > > But when `xrandr --output VGA-0 --crtc 0` everything works as > expected so I pressume is a bug in the crtc detection when a > LCD is attached in the VGA-0 connector both monitors are driven > by the same crtc. As I said, plugging the CRT monitor doesn't > exhibit this problem. > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. Did you/debian also upgrade the xrandr utility to the latest version in git as well? Alex From solca at guug.org Fri Dec 7 00:13:43 2007 From: solca at guug.org (Otto Solares) Date: Fri, 7 Dec 2007 02:13:43 -0600 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: References: <20071207071823.GA16163@guug.org> Message-ID: <20071207081343.GB16163@guug.org> On Fri, Dec 07, 2007 at 02:37:05AM -0500, Alex Deucher wrote: > On Dec 7, 2007 2:18 AM, Otto Solares wrote: > > Hi! > > > > Video card on x86 laptop: > > > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > > > I used to have an old external CRT monitor attached to the VGA-0 > > connector and the command `xrand --output LVDS --off` would > > correctly turn off the laptop's LCD so I can work in the external > > without having both monitors powered-on. > > > > Problem now is that I buy a new external LCD monitor and the > > above command would turn off both the new LCD and the laptop's > > LCD. > > > > But when `xrandr --output VGA-0 --crtc 0` everything works as > > expected so I pressume is a bug in the crtc detection when a > > LCD is attached in the VGA-0 connector both monitors are driven > > by the same crtc. As I said, plugging the CRT monitor doesn't > > exhibit this problem. > > > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. > > Please file a bug (https://bugs.freedesktop.org) and attach your xorg > log and config. Done: Bug # 13557 -otto From illth at gmx.de Thu Dec 6 23:58:08 2007 From: illth at gmx.de (Thomas Ilnseher) Date: Fri, 07 Dec 2007 08:58:08 +0100 Subject: Intel Graphics: xrandr doesn't work when VGA isn't connected during boot Message-ID: <1197014288.28572.8.camel@pcmik05.zmk.uni-kl.de> I have a Notebook (Acer Extensa 5220) with Intel GMA X3100. Output hotpluging with XRandR doesn't work when there was no monitor connected during boot up. (The second monitor is detected in this case, and xrandr commandos yield no error, but the external monitor remains black). It does work as expected when the monitor was connected during bootup. in this case, all output goes to the external monitor, until X starts up, which uses the LVDS (builtin LCD). Then, i can use xrandr for xinerama setup or clone-mode, etc. -- Thomas Ilnseher From solca at guug.org Fri Dec 7 00:17:11 2007 From: solca at guug.org (Otto Solares) Date: Fri, 7 Dec 2007 02:17:11 -0600 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: References: <20071207071823.GA16163@guug.org> Message-ID: <20071207081711.GC16163@guug.org> On Fri, Dec 07, 2007 at 02:38:57AM -0500, Alex Deucher wrote: > On Dec 7, 2007 2:18 AM, Otto Solares wrote: > > Hi! > > > > Video card on x86 laptop: > > > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > > > I used to have an old external CRT monitor attached to the VGA-0 > > connector and the command `xrand --output LVDS --off` would > > correctly turn off the laptop's LCD so I can work in the external > > without having both monitors powered-on. > > > > Problem now is that I buy a new external LCD monitor and the > > above command would turn off both the new LCD and the laptop's > > LCD. > > > > But when `xrandr --output VGA-0 --crtc 0` everything works as > > expected so I pressume is a bug in the crtc detection when a > > LCD is attached in the VGA-0 connector both monitors are driven > > by the same crtc. As I said, plugging the CRT monitor doesn't > > exhibit this problem. > > > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. > > Did you/debian also upgrade the xrandr utility to the latest version > in git as well? No, I'm using Debian's: # which xrandr /usr/bin/xrandr # dpkg -S /usr/bin/xrandr x11-xserver-utils: /usr/bin/xrandr # dpkg -l x11-xserver-utils ii x11-xserver-utils 7.3+2 X server utilities -otto From mgedmin at b4net.lt Fri Dec 7 04:01:14 2007 From: mgedmin at b4net.lt (Marius Gedminas) Date: Fri, 7 Dec 2007 14:01:14 +0200 Subject: Intel Graphics: xrandr doesn't work when VGA isn't connected during boot In-Reply-To: <1197014288.28572.8.camel@pcmik05.zmk.uni-kl.de> References: <1197014288.28572.8.camel@pcmik05.zmk.uni-kl.de> Message-ID: <20071207120114.GC7151@platonas> On Fri, Dec 07, 2007 at 08:58:08AM +0100, Thomas Ilnseher wrote: > I have a Notebook (Acer Extensa 5220) with Intel GMA X3100. I've a Lenovo T61 with the same graphics, AFAIU (Intel 965GM). > Output hotpluging with XRandR doesn't work when there was no monitor > connected during boot up. (The second monitor is detected in this case, > and xrandr commandos yield no error, but the external monitor remains > black). Usually xrandr works fine for me, but sometimes I get the same thing you do: the external monitor thinks it is getting a signal, but shows a black picture. Restarting X.org helps. > It does work as expected when the monitor was connected during bootup. Usually my monitor is connected during bootup, and then I keep pluggin/unplugging external monitors and suspending/unsuspending it randomly. And it usually works fine. Marius Gedminas -- Get a life? Well, once I nearly found one, but the link was broken. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From saschahlusiak at arcor.de Fri Dec 7 04:27:21 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Fri, 7 Dec 2007 13:27:21 +0100 Subject: [ANNOUNCE] xf86-input-joystick-1.3.1 In-Reply-To: <1196988772.5846.49.camel@pcjc2lap> References: <200712070037.36898.saschahlusiak@arcor.de> <1196988772.5846.49.camel@pcjc2lap> Message-ID: <200712071327.29025.saschahlusiak@arcor.de> Hello Peter, Am Freitag 07 Dezember 2007 01:52:52 schrieb Peter Clifton: > On Fri, 2007-12-07 at 00:37 +0100, Sascha Hlusiak wrote: > > Release 1.3.1 of the joystick input driver for X.Org-7.3 > > > How does this stand with 6 Axis devices like the SpaceNavigator from > 3Dconnexion? > > I want to use this device for manipulating 3D objects in applications > (the ones I'm working on at lest). The question I have, is really.. what > is the right model to use.. In general you should be able to use all input devices with the xf86-input-evdev module, but it seems it more focuses on mice and keyboards and not joystick like devices. The joystick driver can use /dev/input/js* devices and /dev/input/event* devices (with up to 32 axes, which is hardcoded but not a real limit) so you should be able to use the SpaceNavigator with this driver. The joystick driver is clearly focused on "normal" joysticks, meaning it assumes that the device has only absolute axes. Main purpose is to use the joystick as a mouse replacement (core events for the mouse cursor) but the driver also reports the axes values as raw valuators to be used by applications that are aware of extended input devices. The driver usually reports two valuators for core events (relative mouse coordinates) and a valuator for each axis found. My joystick has 6 axes so I have 8 valuators. Axis 2-7 are reported absolute between -32768 and 32767. > The device (USB version at least) appears as a /dev/input/event* device > under linux. I can access that directly in the app, but somehow I feel I > should be using an Xorg joystick driver, or perhaps the 3Dconnexions SDK > (ok, no.. that looks horrid!) The joystick driver can generate extended input events for applications. Why do you want to go away from using /dev/input/event* directly? How do you use it and what events do you process? > The second line : 0x09, 0x08 ??? change it to 0x09,0x04 and u have a > Joystick ???. With those 2 bits changed, SpaceNavigator is seen as a > Joystick without any driver. "" Is does not need to be seen as a joystick anymore, an evdev device is fine. > Does the joystick driver seem the right place to try and implement > support for this device? What would it look like to the application > wanting to use the joystick? Feel free to try. If it doesn't fit your needs, the xf86-input-evdev or xf86-input-joystick drivers might be enhanced to support the SpaceNavigator. But tell me what the axes are like, what they report to evtest and what you'd like to do with them. > (If you can point to any trivial examples of X11 apps using a joystick > with this driver, I'd appreciate it. I don't own a conventional > joystick, and am not a gamer, so can't think where to start in Linux > really!) I suggest looking at the simple "xinput" program that shows events of extended input devices. Gimp can make use of those too. Regards, Sascha Hlusiak -------------- 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 Thu Dec 6 07:09:04 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 6 Dec 2007 15:09:04 +0000 Subject: [PATCH] Fix XKB options passed from HAL In-Reply-To: <1196953591.28027.3.camel@skunk.anacadf.mentorg.com> References: <4752D680.3020004@gmail.com> <20071203124513.GU6534@fooishbar.org> <4754237D.7000206@mandriva.com.br> <1196702555.16394.8.camel@rousalka.dyndns.org> <1196953591.28027.3.camel@skunk.anacadf.mentorg.com> Message-ID: <20071206150904.GA13920@fooishbar.org> On Thu, Dec 06, 2007 at 04:06:31PM +0100, Xavier Bestel wrote: > I didn't really follow that discussion, but in the end would a non-US > keyboard work automagically (without specific sections in xorg.conf), > provided the linux console is already properly configured ? No, because there's no mapping between console layouts and XKB layouts; that being said, it's a fairly trivial addition to HAL. In any case, the console should probably start using cxkb at some point anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From anders.norgaard at gmail.com Fri Dec 7 06:48:57 2007 From: anders.norgaard at gmail.com (Anders) Date: Fri, 7 Dec 2007 14:48:57 +0000 (UTC) Subject: intel 965GM 3D problems References: <20071102152756.pdao9t45c0k4848g@webmail.fc.up.pt> Message-ID: fc.up.pt> writes: > > > Hello > > I have a intel 965GM graphic card. I have made a fresh install of > ubuntu gutsy (7.10) and I don't have compiz working and I have a > strange behavior running 3D applications. [...] > But when I run > applications such as pymol (sudo apt-get install pymol) or vmd the > program crash after some minutes, and I have to reboot the computer ( > the X freezes). > Can anyone please install pymol (chemistry program) and see if the > same happen? The same problem affects me and others. A bug has been filed in ubuntu http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/124023 but with no resolution in sight. It is pretty bad, considering that pymol is a critical tool for many bio-scientists. -Anders > When I run torcs I have the same behaviour. After 1 minute or two the > system freezes. > > Thanks in advance Nuno > From matteo.brusa at kaasa.com Fri Dec 7 08:30:36 2007 From: matteo.brusa at kaasa.com (Matteo Brusa) Date: Fri, 07 Dec 2007 17:30:36 +0100 Subject: Output problems with 945GM In-Reply-To: <200712061041.27890.jbarnes@virtuousgeek.org> References: <4757FF1F.4060500@kaasa.com> <200712061041.27890.jbarnes@virtuousgeek.org> Message-ID: <4759752C.9000205@kaasa.com> Hi Jesse, thanks for the answer. See my inline comments. Jesse Barnes wrote: > On Thursday, December 06, 2007 5:54 am Matteo Brusa wrote: >> Hi, >> i have some HDTV configuration issues with my 945GM based pc, i hope i'm in >> the right place to ask. I'm running Ubuntu 7.10 and therefore the intel >> driver version 2:2.1.1-0ubuntu9. >> >> VGA output >> The VGA output works great, it uses the 1360x768 resolution when plugged to >> an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying to get >> either HDMI (with DVI adapter cable) or component running. >> LDVS >> In X, LVDS is always enabled although i have no LCD screen. I tried "xrandr >> --ouput LDVS --off" without success, and the intel module does not support >> any xorg.conf option to shut it off. Could this be the reason why xvidtune >> always shows 1024x768 and not the actual screen value? Component >> I always get 1024x768, no matter which Modeline i specify. Any suggestion? > > You actually can disable it: > > Section "Monitor" > Identifier "Bogus LCD" > Option "ignore" "true" > EndSection > > Section "Driver" > Identifier "Card0" > Driver "intel" > VendorName "Intel Corporation" > BoardName "Unknown Board" > Option "Monitor-LVDS" "Bogus LCD" > EndSection > > And since we've been getting so many reports about this stuff and always end > up pointing people at http://www.intellinuxgraphics.org/dualhead.html, I > think I'll update the man page with some more detail... Great, this works. That would be really helpful to have this mentioned in the man page. > >> TDMS-1 >> I got 1280x768 working, with noticeable overscan. How can i use the same >> 1360x768 with DVI, or get rid of the overscan? > > What's the output of 'xrandr'? Here's the snippet relative to this output: TMDS-1 connected 1280x720+0+0 (0x62) normal (normal left inverted right) 160mm x 90mm Identifier: 0x4e Timestamp: -1361725529 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00ffffffffffff004c2d000200000000 2a0f01038010098c0ae2bda15b4a9824 15474a20000001010101010101010101 010101010101011d007251d01e206e28 5500a05a0000001e011d00bc52d01e20 b8285540a05a0000001e000000fd0032 3d0f2e08000a202020202020000000fc 0053414d53554e470a202020202001af 1280x720 (0x62) 74.2MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.0KHz v: height 720 start 725 end 730 total 750 clock 60.0Hz 1280x720 (0x63) 74.2MHz +HSync +VSync h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.5KHz v: height 720 start 725 end 730 total 750 clock 50.0Hz 640x480 (0x64) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz > >> I also tried to disable DDC; in this case i cannot set any video mode with >> randr. Do i need to use the 915resolution tool, or it's not relevant >> anymore? > > It's not relevant anymore and should generally be avoided... > >> What is the output name for the component: TDMS-1, VGA? > > I'm not sure what you mean here, TMDS-1 and VGA are separate outputs... With my motherboard came a DVI dongle/splitter with VGA, DVI and component (3 RCA) plugs. I just discovered that the component plugs are mapped to TV output. The only resolution i get here is a poor 1024x768 interlaced. I tried to set manually the monitor section similar to the following, without any success. How can i get a resolution in par with VGA or DVI output? Here's xrandr snippet: TV connected 1024x768+0+0 (0x62) normal (normal left inverted right) 0mm x 0mm Identifier: 0x4f Timestamp: -1362011090 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 1 BOTTOM: 37 (0x00000025) range: (0,100) RIGHT: 46 (0x0000002e) range: (0,100) TOP: 36 (0x00000024) range: (0,100) LEFT: 54 (0x00000036) range: (0,100) TV_FORMAT: NTSC-M supported: NTSC-M NTSC-443 NTSC-J PAL-M PAL-N PAL 480p at 59.94Hz 480p at 60Hz 576p 720p at 60Hz 720p at 59.94Hz 720p at 50Hz 1080i at 50Hz 1080i at 60Hz 1080i at 59.94H 1024x768 (0x62) 26.9MHz h: width 1024 start 1025 end 1088 total 1120 skew 0 clock 24.0KHz v: height 768 start 769 end 800 total 801 clock 30.0Hz 800x600 (0x63) 17.0MHz h: width 800 start 801 end 864 total 896 skew 0 clock 19.0KHz v: height 600 start 601 end 632 total 633 clock 30.0Hz 848x480 (0x64) 14.5MHz h: width 848 start 849 end 912 total 944 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz 640x480 (0x65) 11.3MHz h: width 640 start 641 end 704 total 736 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz > >> Last question: X -verbose says "(==) intel(0): VideoRam: 262144 KB". Does >> it mean that it allocates 256 megs for the as video memory? > > It means it can allocate up to 256M for video memory as needed. It doesn't > necessarily allocate all of that by default though... > > Jesse -- Matteo Brusa Senior Lead Developer, Kaasa Solution GmbH tel +49(0)211 730 635 21 mobil +49(0)163 392 09 82 fax +49(0)211 730 635 77 Zollhof 13 40221 D?sseldorf Germany http://www.kaasa.com From adr3nald0s at gmail.com Fri Dec 7 08:31:34 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Fri, 7 Dec 2007 10:31:34 -0600 Subject: [Bug 13548] ATI VGA-O blank when activated in dual-headed mode In-Reply-To: <20071206164029.D9F45130051@annarchy.freedesktop.org> References: <20071206164029.D9F45130051@annarchy.freedesktop.org> Message-ID: <308083c30712070831v46f5cfa9n5f81941211c8956e@mail.gmail.com> I replied on the bug.freedesktop.org site, but didn't know if I needed to reply here. bugzilla-daemon at freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=13548 > ------- Comment #3 from agd5f at yahoo.com 2007-12-06 08:40 PST ------- > Do both heads come up ok if you don't specify a position in your > config? What position? If you mean removing the 'Viewport 0 0' setting, that has no effect. I was doing an 'xrandr ... --right-of LVDS' to set the relative position once X was up. > How about if you turn the VGA port off and on? > xrandr --output VGA-0 --off > xrandr --output VGA-0 --mode 1600x1200 No visible effect. I should have mentioned that when VGA-0 is on, the monitors OSD will show the set resolution and refresh rate in spite of the fact that it displays nothing else. I can also drag windows from LVDS to VGA-0 and back, but they are not displayed on VGA-0. When VGA-0 is off the monitor looks for a signal and then goes to sleep. From matteo.brusa at kaasa.com Fri Dec 7 08:36:56 2007 From: matteo.brusa at kaasa.com (Matteo Brusa) Date: Fri, 07 Dec 2007 17:36:56 +0100 Subject: Output problems with 945GM In-Reply-To: <200712061041.27890.jbarnes@virtuousgeek.org> References: <4757FF1F.4060500@kaasa.com> <200712061041.27890.jbarnes@virtuousgeek.org> Message-ID: <475976A8.30709@kaasa.com> Hi Jesse, thanks for the answer. See my inline comments. Jesse Barnes wrote: > On Thursday, December 06, 2007 5:54 am Matteo Brusa wrote: >> Hi, >> i have some HDTV configuration issues with my 945GM based pc, i hope i'm in >> the right place to ask. I'm running Ubuntu 7.10 and therefore the intel >> driver version 2:2.1.1-0ubuntu9. >> >> VGA output >> The VGA output works great, it uses the 1360x768 resolution when plugged to >> an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying to get >> either HDMI (with DVI adapter cable) or component running. >> LDVS >> In X, LVDS is always enabled although i have no LCD screen. I tried "xrandr >> --ouput LDVS --off" without success, and the intel module does not support >> any xorg.conf option to shut it off. Could this be the reason why xvidtune >> always shows 1024x768 and not the actual screen value? Component >> I always get 1024x768, no matter which Modeline i specify. Any suggestion? > > You actually can disable it: > > Section "Monitor" > Identifier "Bogus LCD" > Option "ignore" "true" > EndSection > > Section "Driver" > Identifier "Card0" > Driver "intel" > VendorName "Intel Corporation" > BoardName "Unknown Board" > Option "Monitor-LVDS" "Bogus LCD" > EndSection > > And since we've been getting so many reports about this stuff and always end > up pointing people at http://www.intellinuxgraphics.org/dualhead.html, I > think I'll update the man page with some more detail... This works, great. It would be really helpful to have this mentioned in the man page. >> TDMS-1 >> I got 1280x768 working, with noticeable overscan. How can i use the same >> 1360x768 with DVI, or get rid of the overscan? > > What's the output of 'xrandr'? Here's the snippet relative to this output: TMDS-1 connected 1280x720+0+0 (0x62) normal (normal left inverted right) 160mm x 90mm Identifier: 0x4e Timestamp: -1361725529 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00ffffffffffff004c2d000200000000 2a0f01038010098c0ae2bda15b4a9824 15474a20000001010101010101010101 010101010101011d007251d01e206e28 5500a05a0000001e011d00bc52d01e20 b8285540a05a0000001e000000fd0032 3d0f2e08000a202020202020000000fc 0053414d53554e470a202020202001af 1280x720 (0x62) 74.2MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.0KHz v: height 720 start 725 end 730 total 750 clock 60.0Hz 1280x720 (0x63) 74.2MHz +HSync +VSync h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.5KHz v: height 720 start 725 end 730 total 750 clock 50.0Hz 640x480 (0x64) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz BTW, the xvidtune tool does not work at all, any configuration (included the current working preset) is not accepted as valid, no matter if i'm in VGA or DVI mode. I hoped i could fix the overscan issue with it. >> I also tried to disable DDC; in this case i cannot set any video mode with >> randr. Do i need to use the 915resolution tool, or it's not relevant >> anymore? > > It's not relevant anymore and should generally be avoided... > >> What is the output name for the component: TDMS-1, VGA? > > I'm not sure what you mean here, TMDS-1 and VGA are separate outputs... With my motherboard came a DVI dongle/splitter with VGA, DVI and component (3 RCA) plugs. I just discovered that the component plugs are mapped to TV output. The only resolution i get here is a poor 1024x768 interlaced. I tried to set manually the monitor section similar to the following, without any success. Section "Monitor" Identifier "TVMon" # Option "Ignore" "true" # Option "Enable" "false" HorizSync 30-61 VertRefresh 29-75 Modeline "1024x768" 26.89 1024 1025 1088 1120 768 769 800 801 Modeline "1280x720x25" 83.700 1280 1780 1828 2172 720 751 754 769 +hsync +vsync Modeline "1360x768" 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync Modeline "1280x720_o" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Modeline "1360x768" 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync Modeline "1360x768_60.00" 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync Modeline "1360x768_50.00" 69.00 1360 1416 1552 1744 768 771 781 793 -hsync +vsync Modeline "1360x768R" 72.00 1360 1408 1440 1520 768 771 781 790 +hsync -vsync Modeline "1152x672" 62.25 1152 1208 1320 1488 672 675 685 699 -hsync +vsync Modeline "1920x1200" 154 1920 1968 2000 2080 1200 1203 1209 1235 +HSync -Vsync Modeline "1280x768_60.00" 79.50 1280 1344 1472 1664 768 771 781 798 -hsync +vsync Modeline "1920x1080" 148.5 1920 1960 2016 2200 1080 1082 1088 1125 -hsync +vsync EndSection How can i get a resolution similar to the VGA or DVI output? Here's xrandr snippet: TV connected 1024x768+0+0 (0x62) normal (normal left inverted right) 0mm x 0mm Identifier: 0x4f Timestamp: -1362011090 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 1 BOTTOM: 37 (0x00000025) range: (0,100) RIGHT: 46 (0x0000002e) range: (0,100) TOP: 36 (0x00000024) range: (0,100) LEFT: 54 (0x00000036) range: (0,100) TV_FORMAT: NTSC-M supported: NTSC-M NTSC-443 NTSC-J PAL-M PAL-N PAL 480p at 59.94Hz 480p at 60Hz 576p 720p at 60Hz 720p at 59.94Hz 720p at 50Hz 1080i at 50Hz 1080i at 60Hz 1080i at 59.94H 1024x768 (0x62) 26.9MHz h: width 1024 start 1025 end 1088 total 1120 skew 0 clock 24.0KHz v: height 768 start 769 end 800 total 801 clock 30.0Hz 800x600 (0x63) 17.0MHz h: width 800 start 801 end 864 total 896 skew 0 clock 19.0KHz v: height 600 start 601 end 632 total 633 clock 30.0Hz 848x480 (0x64) 14.5MHz h: width 848 start 849 end 912 total 944 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz 640x480 (0x65) 11.3MHz h: width 640 start 641 end 704 total 736 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz Thanks again, Matteo From jra at baylink.com Fri Dec 7 09:07:52 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 7 Dec 2007 12:07:52 -0500 Subject: [xorg] Re: Request to reconfigure the list with [xorg] in subject line In-Reply-To: References: <200712032130.34559.arekm@maven.pl> <20071203213505.0a6b9eae@the-village.bc.nu> <20071205115131.593289d8@sbs173> Message-ID: <20071207170752.GF12178@cgi.jachomes.com> On Wed, Dec 05, 2007 at 09:05:27AM -0800, Alan W. Irwin wrote: > Sorry, such an attitude is just too far over the top for my tastes. Just to > remind you we are supposed to be part of a _free_ software movement which > fundamentally means any subject lines are allowed. If you are really that > allergic to list-ids in subject lines, then here is a procmail > recipe to remove them from this list traffic. :-) Ah, yes; the "who's responsible for the toilet seat position" argument. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From jra at baylink.com Fri Dec 7 09:12:45 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 7 Dec 2007 12:12:45 -0500 Subject: Website maintenance volunteers? In-Reply-To: <200712061947.lB6Jl38O023740@wezen.cs.pdx.edu> References: <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> <20071206105745.GH3614@fooishbar.org> <200712061947.lB6Jl38O023740@wezen.cs.pdx.edu> Message-ID: <20071207171245.GG12178@cgi.jachomes.com> On Thu, Dec 06, 2007 at 11:47:03AM -0800, Barton C Massey wrote: > In message <47580511.30403 at clearchain.com> you wrote: > > Whilst I agree MW has a much richer feature set, Moin > > seems nicely suited to wiki farms. There's trade offs > > either way. MW is much easier to extend though. I've not > > looked at Moin for extendability. One thing to note is MW > > has no concept of acl's. Moin does. Though based on the > > current wiki rules that's not an issue. > > In my mind, the conversion to MediaWiki is a moot point > unless somebody has some plan for solving the content > conversion problem. As far as I know, there are no > automated tools for this. I haven't heard anybody speak up > with a viable plan for how it would be done by hand, either, > which seems to me to be a huge amount of work with > substantial risks. I had, in fact, mentioned twice, once to Daniel off list, and once on, that the MythTV project has a set of scripts for this conversion, having done it ourselves (to excellent effect) about 2 years ago. If interest in them is decided upon, we'd be glad to share them; I'll run off now and make sure we still *have* them. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From sears at cs.berkeley.edu Fri Dec 7 11:14:22 2007 From: sears at cs.berkeley.edu (Russell Sears) Date: Fri, 07 Dec 2007 11:14:22 -0800 Subject: intel 965GM 3D problems In-Reply-To: References: <20071102152756.pdao9t45c0k4848g@webmail.fc.up.pt> Message-ID: <47599B8E.7040709@cs.berkeley.edu> I'm running ubuntu gutsy with an intel 965gm (Lenovo x61 tablet), but with the newer intel video drivers from hardy (2:2.2.0-1ubuntu1). I haven't tested it heavily, but pymol doesn't seem to crash X on my system. Instead, if you move the window, pymol's rendering window (the 3d one) is no longer updated. The menus are still responsive. Pymol says this on the command line: OpenGL graphics engine: GL_VENDOR: Tungsten Graphics, Inc GL_RENDERER: Mesa DRI Intel(R) 965GM 4.1.3002 GL_VERSION: 1.5 Mesa 7.0.2 Detected 2 CPUs. Enabled multithreaded rendering. PyMOL: normal program termination. -Rusty Anders wrote: > fc.up.pt> writes: > >> >> Hello >> >> I have a intel 965GM graphic card. I have made a fresh install of >> ubuntu gutsy (7.10) and I don't have compiz working and I have a >> strange behavior running 3D applications. > > [...] > >> But when I run >> applications such as pymol (sudo apt-get install pymol) or vmd the >> program crash after some minutes, and I have to reboot the computer ( >> the X freezes). >> Can anyone please install pymol (chemistry program) and see if the >> same happen? > > The same problem affects me and others. A bug has been filed in ubuntu > > http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/124023 > > but with no resolution in sight. It is pretty bad, considering that pymol is a > critical tool for many bio-scientists. > > -Anders > > > >> When I run torcs I have the same behaviour. After 1 minute or two the >> system freezes. >> >> Thanks in advance Nuno >> > > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From saschahlusiak at arcor.de Fri Dec 7 12:34:52 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Fri, 7 Dec 2007 21:34:52 +0100 Subject: More flexible config/hal.c Message-ID: <200712072135.14149.saschahlusiak@arcor.de> Hi list, Looking at config/hal.c, why is it necessary to check if info.capabilities contains input.mouse or input.keys? Isn't the presence of input.x11_driver enough to see that this device wants to be hotplugged? When this is present, it was surely merged in an hal fdi file, meaning this device is hotplugable enough. But maybe I'd like to hotplug a device that does not export input.mouse or input.key, like joysticks? The driver will know how to handle the device. Why fail just because we don't know the device yet? And I think it's safe enough to just check for "input.xkb.rules" without knowing if it is actually a keyboard; if it fails it will return NULL, if it succeeds, let's not care; the input driver will process the option if needed. I'd also like to wish for a way to pass custom options to drivers, not only a handful of hardcoded options like the input.xkb namespace. There already was a patch on the list for this once: http://lists.freedesktop.org/archives/xorg/2007-August/027515.html Please review attached patch and tell me what you think. Regards, Sascha -------------- next part -------------- A non-text attachment was scrubbed... Name: hal.c.patch Type: text/x-diff Size: 3018 bytes Desc: not available 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 jbarnes at virtuousgeek.org Fri Dec 7 13:33:56 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 7 Dec 2007 13:33:56 -0800 Subject: [PATCH] add EXA relocation function Message-ID: <200712071333.56545.jbarnes@virtuousgeek.org> In order to avoid having a fixed offset for the EXA offscreen area (which is nice if the driver is using TTM) drivers need to update the base offset of EXA memory in EnterVT, and may need to update any private pointers they've allocated as well (e.g. for the cursor or scanout buffers, etc.). Since the server already kicks out all the pixmaps at VT switch time, the relocation is trivial and will typically just involve the one, big free area and any locked driver allocations; this function reflects that. One possible enhancement would be to call back into a driver provided function to update the private allocations, but it wouldn't really save any code... Any thoughts on this? Jesse -------------- next part -------------- A non-text attachment was scrubbed... Name: exa-base-update.patch Type: text/x-diff Size: 1289 bytes Desc: not available URL: From twxorg at gmail.com Fri Dec 7 13:41:06 2007 From: twxorg at gmail.com (tommy watson) Date: Fri, 7 Dec 2007 16:41:06 -0500 Subject: xf86-video-ati: AMD64 RV350 tv-out In-Reply-To: <54337fa00712060944y891b77ud8bafc6fc16cd1cc@mail.gmail.com> References: <54337fa00712060944y891b77ud8bafc6fc16cd1cc@mail.gmail.com> Message-ID: <54337fa00712071341p7e99970cpe55f65a069bbafe9@mail.gmail.com> On Dec 7, 2007 1:58 AM, Alex Deucher wrote: > On Dec 6, 2007 12:44 PM, tommy watson wrote: > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon > > 9600] (prog-if 00 [VGA]) > > > > Is this a known issue? Is there anything I can do to help test/fix this? > > The video overlay only works on one crtc at a time. In dualhead > configurations, the overlay will follow the window. In clone mode you > have to pick which crtc you want to use the overlay with. use a tool > like xvattr to switch the crtc used by the overlay. Possible values: > -1 auto, 0 crtc0, 1, crtc1. > > xvattr -a XV_CRTC -v 1 > Thank you _very_ much, this fixed my problem and I went from 100% cpu usage with fglrx to 47% idle using xf86-video-ati. Thanks for all your hard work getting this incorporated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbarnes at virtuousgeek.org Fri Dec 7 13:52:16 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 7 Dec 2007 13:52:16 -0800 Subject: [PATCH] add EXA relocation function In-Reply-To: <200712071333.56545.jbarnes@virtuousgeek.org> References: <200712071333.56545.jbarnes@virtuousgeek.org> Message-ID: <200712071352.16128.jbarnes@virtuousgeek.org> On Friday, December 07, 2007 1:33 pm Jesse Barnes wrote: > In order to avoid having a fixed offset for the EXA offscreen area (which > is nice if the driver is using TTM) drivers need to update the base offset > of EXA memory in EnterVT, and may need to update any private pointers > they've allocated as well (e.g. for the cursor or scanout buffers, etc.). > > Since the server already kicks out all the pixmaps at VT switch time, the > relocation is trivial and will typically just involve the one, big free > area and any locked driver allocations; this function reflects that. > > One possible enhancement would be to call back into a driver provided > function to update the private allocations, but it wouldn't really save any > code... > > Any thoughts on this? Updated with a version bump and intel driver support. Jesse -------------- next part -------------- A non-text attachment was scrubbed... Name: exa-base-update-2.patch Type: text/x-diff Size: 1504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: i830-exa-relocation.patch Type: text/x-diff Size: 2192 bytes Desc: not available URL: From bart at cs.pdx.edu Fri Dec 7 14:18:18 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Fri, 07 Dec 2007 14:18:18 -0800 Subject: Website maintenance volunteers? In-Reply-To: Your message of "Fri, 07 Dec 2007 12:12:45 EST." <20071207171245.GG12178@cgi.jachomes.com> References: <20071207171245.GG12178@cgi.jachomes.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> <20071206105745.GH3614@fooishbar.org> <200712061947.lB6Jl38O023740@wezen.cs.pdx.edu> Message-ID: <200712072218.lB7MII3O029199@adara.cs.pdx.edu> In message <20071207171245.GG12178 at cgi.jachomes.com> you wrote: > I had, in fact, mentioned twice, once to Daniel off list, and once on, > that the MythTV project has a set of scripts for this conversion, > having done it ourselves (to excellent effect) about 2 years ago. My apologies! I guess I missed it in the flurry of discussion. > If interest in them is decided upon, we'd be glad to share them; I'll > run off now and make sure we still *have* them. :-) That would be good to know---also a bit about what kind of manual post-processing was needed after applying them at MythTV (there's always some, I think). Thanks much for your kind offers of help! Bart Massey bart at cs.pdx.edu From alan.coopersmith at sun.com Fri Dec 7 14:29:12 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Fri, 07 Dec 2007 14:29:12 -0800 Subject: Website maintenance volunteers? In-Reply-To: <200712061940.lB6JeXiN023371@wezen.cs.pdx.edu> References: <20071206105745.GH3614@fooishbar.org> <47570BA4.8020504@sun.com> <68da43e00712050810o5550d379gaa281f10fcb40252@mail.gmail.com> <20071128201032.GA25389@bludgeon.org> <20071128210737.GP3067@fooishbar.org> <200711290644.49048.zack@tungstengraphics.com> <20071129154137.072e41cf.arthur.huillet@free.fr> <200712051936.lB5JatsR009761@wezen.cs.pdx.edu> <200712060854.lB68saTJ001487@wezen.cs.pdx.edu> <200712061940.lB6JeXiN023371@wezen.cs.pdx.edu> Message-ID: <4759C938.4060402@sun.com> Barton C Massey wrote: > In message <20071206105745.GH3614 at fooishbar.org> you wrote: >> On Thu, Dec 06, 2007 at 12:54:36AM -0800, Barton C Massey wrote: >>> Can somebody in the know please give a clear description of >>> what our current Wiki editing rules are? >> FrontPage: only a limited subset of people (historical reasons) >> everything else: everyone who's registered > > Thanks! "Everything else" includes the project wikis, I > assume. > > I did not know/remember this. Do folks have thoughts on > non-member wiki edits? Should non-members have edit > permission only on a specific subsite (or not at all)? How would the wiki know who is a member? Sounds like additional admin work to keep an up-to-date copy of the member database on freedesktop.org and designing some way to authenticate against it, so that the spammers can't just all claim they're Jim Gettys or Keith Packard or other well known members. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From itamar.axelrod.work at gmail.com Fri Dec 7 14:39:27 2007 From: itamar.axelrod.work at gmail.com (Itamar Axelrod) Date: Sat, 8 Dec 2007 00:39:27 +0200 Subject: Window initial position Message-ID: Hi all, I had noticed very strange behaviour while trying to get the x,y coor. of a created window. I use the standard XCreateSimpleWindow(...) library call to create my window - right after I create it - I "Map" it using XMapWindow(). Now, all I want is to query the created window's initial x,y coor. - and for this I use XTranslateCoordinates(). For some reason sometimes the x,y coor. I receive differ from the window's actual position. Also, after creating the window and querying its initial location I subscirbe to its events - I had noticed that sometimes the window receives a non-interactive initial move event (which I don't always catch) - that changes its original initial location. How can I be sure the coor. I receive are the correct ones? Please help. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at anholt.net Fri Dec 7 16:32:31 2007 From: eric at anholt.net (Eric Anholt) Date: Fri, 07 Dec 2007 16:32:31 -0800 Subject: [PATCH] add EXA relocation function In-Reply-To: <200712071333.56545.jbarnes@virtuousgeek.org> References: <200712071333.56545.jbarnes@virtuousgeek.org> Message-ID: <1197073951.1445.39.camel@localhost> On Fri, 2007-12-07 at 13:33 -0800, Jesse Barnes wrote: > In order to avoid having a fixed offset for the EXA offscreen area (which is > nice if the driver is using TTM) drivers need to update the base offset of > EXA memory in EnterVT, and may need to update any private pointers they've > allocated as well (e.g. for the cursor or scanout buffers, etc.). > > Since the server already kicks out all the pixmaps at VT switch time, the > relocation is trivial and will typically just involve the one, big free area > and any locked driver allocations; this function reflects that. > > One possible enhancement would be to call back into a driver provided function > to update the private allocations, but it wouldn't really save any code... > > Any thoughts on this? area->base_offset is the non-aligned offset of the allocation, i.e. it should equal prev->base_offset + prev->size. I think you want to be incrementing both base_offset and offset by a delta of (new_base - pExaScr->info->offScreenBase) and then update pExaScr->info->offScreenBase. You might want to run once with DEBUG_OFFSCREEN set to make sure you're not violating any invariants. -- Eric Anholt anholt at FreeBSD.org eric at anholt.net eric.anholt at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part URL: From at at drinian.org Fri Dec 7 17:51:11 2007 From: at at drinian.org (Andrew Todd) Date: Fri, 7 Dec 2007 20:51:11 -0500 Subject: X lockups with xf86-video-i810-2.2.0 Message-ID: <200712072051.11487.at@drinian.org> I was asked to pass this along from the Gentoo Bugzilla. There's a few people with 945GM chipsets, including me, who are getting random lockups several times a day with the 2.2.0 version of the Intel driver. Full trace here: https://bugs.gentoo.org/show_bug.cgi?id=201519 and please ask me if I can provide any more useful information. Thanks. From macslow at bangang.de Fri Dec 7 22:59:05 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Sat, 08 Dec 2007 07:59:05 +0100 Subject: Unable to create a redirected window with a rgba-colormap Message-ID: <1197097145.7222.26.camel@HAL9000> Greetings xorg-crowd! Once more I'm suffering form the lack of tutorials, up-to-date documentation on Composite, Render and general X11-development. I desperately turn to this list asking for help to achieve the presumably simple task of creating a redirected top-level X11-window with a rgba-colormap (or visual). Please have a look at the attached program below. When calling XCreateWindow() like... window = XCreateWindow (pDisplay, RootWindow (pDisplay, pVisInfo[i].screen), 50, 50, 300, 300, 0, pVisInfo[i].depth, InputOutput, pVisInfo[i].visual, iWindowAttribsMask, &windowAttribs); I get a... X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 13 Current serial number in output stream: 16 When I do use CopyFromParent for the arguments depth and visual in XCreateWindow() the program runs fine. What's the reason for this? How can I make sure it works without using CopyFromParent? I assume to query the list of VisualInfos in a correct way... but then I don't live and breath X11 enough to be really certain. I also get the same BadMatch-error when I try to pass a dedicated colormap (which is hopefully a rgba-colormap) to XCreateWindow(). How is one supposed to create a window with a rgba-colormap? My motivation for going through all this is to understand - on the long run - the needed nuts and bolts for making non-top-level windows being redirected and hopefully stuffed in a GL-texture via GLX_EXT_texture_from_pixmap. Humble thanks in advance to anybody helping me out with this! Best regards... Mirco "MacSlow" M?ller -------------- next part -------------- A non-text attachment was scrubbed... Name: x11-offscreen-redirection.c Type: text/x-csrc Size: 11567 bytes Desc: not available URL: From andreas at schildbach.de Sat Dec 8 02:50:00 2007 From: andreas at schildbach.de (Andreas Schildbach) Date: Sat, 08 Dec 2007 11:50:00 +0100 Subject: Quirk problem in intel driver 2.2.0 (possible "patch" included) Message-ID: Hello, The ignore_tv quirk for the Dell Latitude X1 currently does not have any effect (I tested xserver-xorg-video-intel (2:2.2.0-1ubuntu1)) Is it possible that the following line in i830_quick is not correct? /* Dell Latitude X1 */ { PCI_CHIP_I945_GM, 0x1028, 0x01a3, quirk_ignore_tv }, The Dell X1 has got a i915 family chip: 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Dell Unknown device 01a3 I think that line should read: /* Dell Latitude X1 */ { PCI_CHIP_I915_GM, 0x1028, 0x01a3, quirk_ignore_tv }, Regards, Andreas From andreas at schildbach.de Sat Dec 8 02:55:53 2007 From: andreas at schildbach.de (Andreas Schildbach) Date: Sat, 08 Dec 2007 11:55:53 +0100 Subject: Quirk problem in intel driver 2.2.0 (possible "patch" included) In-Reply-To: References: Message-ID: Andreas Schildbach wrote: > The Dell X1 has got a i915 family chip: > > 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP]) > Subsystem: Dell Unknown device 01a3 Ooops: 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) Subsystem: Dell Unknown device 01a3 From brice.goglin at gmail.com Sat Dec 8 03:23:09 2007 From: brice.goglin at gmail.com (Brice Goglin) Date: Sat, 08 Dec 2007 12:23:09 +0100 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <20071207081711.GC16163@guug.org> References: <20071207071823.GA16163@guug.org> <20071207081711.GC16163@guug.org> Message-ID: <475A7E9D.2070404@gmail.com> Otto Solares wrote: > On Fri, Dec 07, 2007 at 02:38:57AM -0500, Alex Deucher wrote: > >> Did you/debian also upgrade the xrandr utility to the latest version >> in git as well? >> > > No, I'm using Debian's: > > # which xrandr > /usr/bin/xrandr > # dpkg -S /usr/bin/xrandr > x11-xserver-utils: /usr/bin/xrandr > # dpkg -l x11-xserver-utils > ii x11-xserver-utils 7.3+2 X server utilities > This is xrandr 1.2.2, not the one from git. I don't know if Matthias Hopf is done with his changes in xrandr, but it might be good to release 1.2.3. Brice From s.xrhstos at yahoo.gr Sat Dec 8 04:07:59 2007 From: s.xrhstos at yahoo.gr (Chris) Date: Sat, 8 Dec 2007 12:07:59 +0000 (GMT) Subject: Xgl-gamma-problem. Message-ID: <376747.12633.qm@web23408.mail.ird.yahoo.com> Hello, I have a problem with gamma correction after make compiz enabled...I get a message in the kcontrol that my hardware doesn't support it.I tried to correct the gamma from the console.(man xgamma and xgamma -gamma 0.4).But all I get is this message: Xlib: extension "XFree86-VidModeExtension" missing on display ":0.0". Unable to query video extension version. I try to install XFree86 and I get this message during installation: .../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/drm.h:45:26: error: linux/config.h: No such file or directory make[5]: *** [clientattrib.o] Error 1 make[5]: Leaving directory `/build/lib/GL/glx' make[4]: *** [all] Error 2 make[4]: Leaving directory `/build/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/build' make[1]: *** [World] Error 2 make[1]: Leaving directory `/build' make: *** [World] Error 2 Is there any other way to correct the gamma? Sorry for my english.Please any help.I cannot have compiz for this reason.I think the simple things like gamma and brightness are the most difficult... I have OpenSuse 10.3 KDE and my graphic chip is Intel 945. ___________________________________________________________ ?????????????? Yahoo!; ?????????? ?? ?????????? ???????? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? http://login.yahoo.com/config/mail?.intl=gr From simon.thum at gmx.de Sat Dec 8 04:32:04 2007 From: simon.thum at gmx.de (Simon Thum) Date: Sat, 08 Dec 2007 13:32:04 +0100 Subject: Xgl-gamma-problem. In-Reply-To: <376747.12633.qm@web23408.mail.ird.yahoo.com> References: <376747.12633.qm@web23408.mail.ird.yahoo.com> Message-ID: <475A8EC4.9080203@gmx.de> > Is there any other way to correct the gamma? http://linux.die.net/man/5/xorg.conf You may need to load "extmod" module: http://www.knoppix.net/forum/viewtopic.php?t=3291&view=previous Just 2 sec of google... -Simon From simon.thum at gmx.de Sat Dec 8 04:56:27 2007 From: simon.thum at gmx.de (Simon Thum) Date: Sat, 08 Dec 2007 13:56:27 +0100 Subject: Build problem Message-ID: <475A947B.60006@gmx.de> Hi List, I'm trying to rebuild my xorg tree (fresh from git, using build.sh), but the following comes in many packages: Makefile.am:44: EXTRA_DIST must be set with `=' before using `+=' That's easily fixed by removing the '+' in '+=' at any occurrence, but it leads me to think I am missing something. Also, I'm not an autotools genius. Any ideas? -- Simon Thum From macslow at bangang.de Sat Dec 8 05:04:09 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Sat, 08 Dec 2007 14:04:09 +0100 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <1197097145.7222.26.camel@HAL9000> References: <1197097145.7222.26.camel@HAL9000> Message-ID: <1197119049.7222.77.camel@HAL9000> Am Samstag, den 08.12.2007, 07:59 +0100 schrieb Mirco M?ller: > When calling XCreateWindow() like... > > window = XCreateWindow (pDisplay, > RootWindow (pDisplay, > pVisInfo[i].screen), > 50, > 50, > 300, > 300, > 0, > pVisInfo[i].depth, > InputOutput, > pVisInfo[i].visual, > iWindowAttribsMask, > &windowAttribs); > > I get a... > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 1 (X_CreateWindow) > Serial number of failed request: 13 > Current serial number in output stream: 16 In the meantime I was able to fix this by the very "scientific" approach of trial-and-error. It turned out to be missing... windowAttribs.border_pixel = 0; ... and... iWindowAttribsMask = CWBorderPixel | CWEventMask | CWColormap; I really tried this by pure chance as there is nothing in the man-page of XCreateWindow() hinting someone towards this. This makes me wonder again how anybody can properly learn developing against X11. Now the passed colormap is accepted and the program does run after additional modifications in the paint() function. A first small victory. But I still cannot create a GLX-pixmap in the paint() function, following the GLX_EXT_texture_from_pixmap spec. I get... X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 142 (GLX) Minor opcode of failed request: 22 () Value in failed request: 0x2 Serial number of failed request: 39 Current serial number in output stream: 40 ... which clearly points out a mistake in the way I call glXCreatePixmap(). But according to... http://www.opengl.org/registry/specs/EXT/texture_from_pixmap.txt ... it seems necessary to pass a non-empty attribute-array to glXCreatePixmap(). Looking at the OpenGL 2.1 reference for glXCreatePixmap() the attribute-array has to be empty. Now what? I certainly tried it with an empty attribute-list and the BadValue-error did not occur. But how am I supposed to properly use GLX_EXT_texture_from_pixmap? So I took a look at the current sourcecode of compiz. Just as the GLX_EXT_texture_form_pixmap spec suggests the attribute-array for glXCreatePixmap() is not empty. So I stuck with an attribute-array looking like... int aiGLXPixmapAttribs[] = { GLX_TEXTURE_TARGET_EXT, GLX_TEXTURE_RECTANGLE_EXT, GLX_TEXTURE_FORMAT_EXT, GLX_TEXTURE_FORMAT_RGB_EXT, None }; It still did not work. Then I had a flash of a totally random trial-and-error idea again and disabled compiz, switching back to metacity. Guess what now it worked. Stunned I was... for a moment. In the next flash of totally random... you get the idea... I enabled compiz again and ran my program again. This time it even ran under compiz. WTF!? So, two small victories in a day... surely I can top that and make it three, by trying the same code on an intel i965. Crap! Segfault somewhere in libGL, impossible for gdb to point out the error. Sigh! Best regards... Mirco "MacSlow" M?ller -------------- next part -------------- A non-text attachment was scrubbed... Name: x11-offscreen-redirection.c Type: text/x-csrc Size: 18070 bytes Desc: not available URL: From rjshaw at netspace.net.au Sat Dec 8 05:31:49 2007 From: rjshaw at netspace.net.au (Russell Shaw) Date: Sun, 09 Dec 2007 00:31:49 +1100 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <1197119049.7222.77.camel@HAL9000> References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> Message-ID: <475A9CC5.2080107@netspace.net.au> Mirco M?ller wrote: > Am Samstag, den 08.12.2007, 07:59 +0100 schrieb Mirco M?ller: > >> When calling XCreateWindow() like... >> >> window = XCreateWindow (pDisplay, >> RootWindow (pDisplay, >> pVisInfo[i].screen), >> 50, >> 50, >> 300, >> 300, >> 0, >> pVisInfo[i].depth, >> InputOutput, >> pVisInfo[i].visual, >> iWindowAttribsMask, >> &windowAttribs); >> >> I get a... >> >> X Error of failed request: BadMatch (invalid parameter attributes) >> Major opcode of failed request: 1 (X_CreateWindow) >> Serial number of failed request: 13 >> Current serial number in output stream: 16 > > In the meantime I was able to fix this by the very "scientific" > approach of trial-and-error. It turned out to be missing... > > windowAttribs.border_pixel = 0; > > ... and... > > iWindowAttribsMask = CWBorderPixel | CWEventMask | CWColormap; > > I really tried this by pure chance as there is nothing in the man-page > of XCreateWindow() hinting someone towards this. This makes me wonder > again how anybody can properly learn developing against X11. You really need the "XLIB Programming Manual". http://www.amazon.com/Programming-Manual-Definitive-Guides-Window/dp/1565920023/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1197120206&sr=8-1 also "XLIB Reference Manual R5": http://www.amazon.com/Reference-Manual-Definitive-Guides-Window/dp/1565920066/ref=pd_sim_b_title_1 also useful, "OpenGL Programming for the X Window System": http://www.amazon.com/OpenGL-Programming-X-Window-System/dp/0201483599/ref=sr_1_1?ie=UTF8&s=books&qid=1197120535&sr=1-1 From wharms at bfs.de Sat Dec 8 08:05:42 2007 From: wharms at bfs.de (walter harms) Date: Sat, 08 Dec 2007 17:05:42 +0100 Subject: Build problem In-Reply-To: <475A947B.60006@gmx.de> References: <475A947B.60006@gmx.de> Message-ID: <475AC0D6.2000505@bfs.de> Simon Thum wrote: > Hi List, > > I'm trying to rebuild my xorg tree (fresh from git, using build.sh), but > the following comes in many packages: > > Makefile.am:44: EXTRA_DIST must be set with `=' before using `+=' > > That's easily fixed by removing the '+' in '+=' at any occurrence, but > it leads me to think I am missing something. Also, I'm not an autotools > genius. > This is not a fix since since FOO+=bar means FOO=$(FOO)bar. I have no clue what causes this problem in the first place but try EXTRA_DIST= somcewhere at the beginning. re, wh From dbn.lists at gmail.com Sat Dec 8 08:49:42 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sat, 8 Dec 2007 08:49:42 -0800 Subject: Build problem In-Reply-To: <475A947B.60006@gmx.de> References: <475A947B.60006@gmx.de> Message-ID: <91705d080712080849x6dd7f21cgd8ec8a3c3720971a@mail.gmail.com> On Dec 8, 2007 4:56 AM, Simon Thum wrote: > > I'm trying to rebuild my xorg tree (fresh from git, using build.sh), but > the following comes in many packages: > > Makefile.am:44: EXTRA_DIST must be set with `=' before using `+=' > > That's easily fixed by removing the '+' in '+=' at any occurrence, but > it leads me to think I am missing something. Also, I'm not an autotools > genius. No, you're right. If "EXTRA_DIST += ..." is the only occurrence in that Makefile.am, that's wrong. A massive addition to all the trees was made to support generating the ChangeLog, and part of it was this: EXTRA_DIST += ChangeLog If you could find all the modules that have this issue, that'd be great. Most likely, it just requires changing those lines to "EXTRA_DIST = ChangeLog" in the top level Makefile.am if there's no other occurrence of EXTRA_DIST. -- Dan From macslow at bangang.de Sat Dec 8 09:19:58 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Sat, 08 Dec 2007 18:19:58 +0100 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <475A9CC5.2080107@netspace.net.au> References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> <475A9CC5.2080107@netspace.net.au> Message-ID: <1197134398.7222.82.camel@HAL9000> Am Sonntag, den 09.12.2007, 00:31 +1100 schrieb Russell Shaw: > > I really tried this by pure chance as there is nothing in the man-page > > of XCreateWindow() hinting someone towards this. This makes me wonder > > again how anybody can properly learn developing against X11. > > You really need the "XLIB Programming Manual". > > http://www.amazon.com/Programming-Manual-Definitive-Guides-Window/dp/1565920023/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1197120206&sr=8-1 > > also "XLIB Reference Manual R5": > > http://www.amazon.com/Reference-Manual-Definitive-Guides-Window/dp/1565920066/ref=pd_sim_b_title_1 Aren't those X11R5-related book heavily out-dated? Under Linux we are at X11R7 and things like Xcomposite, Xrender, Xfixes, Xdamage, Xrandr etc. are not covered by these books. Does anybody know, if there are updated editions of these books, covering all the new X11-extensions, planned or available? > also useful, "OpenGL Programming for the X Window System": > > http://www.amazon.com/OpenGL-Programming-X-Window-System/dp/0201483599/ref=sr_1_1?ie=UTF8&s=books&qid=1197120535&sr=1-1 That might be more worthwhile. Best regards... Mirco From jennytharayil at gmail.com Sat Dec 8 10:20:23 2007 From: jennytharayil at gmail.com (jenny tc) Date: Sat, 8 Dec 2007 23:50:23 +0530 Subject: No subject Message-ID: <47b5508f0712081020n41f42a7fpb975144f6a46c834@mail.gmail.com> Hi I am trying to bring Aserver up on a mips board.The board does not have any input devices . Is it possible to generate input events through the network?If so how? -Jenny From jennytharayil at gmail.com Sat Dec 8 10:20:31 2007 From: jennytharayil at gmail.com (jenny tc) Date: Sat, 8 Dec 2007 23:50:31 +0530 Subject: No subject Message-ID: <47b5508f0712081020q73075a18jeb1e61d537500640@mail.gmail.com> Hi I am trying to bring Xserver up on a mips board.The board does not have any input devices . Is it possible to generate input events through the network?If so how? -Jenny From jennytharayil at gmail.com Sat Dec 8 10:21:37 2007 From: jennytharayil at gmail.com (jenny tc) Date: Sat, 8 Dec 2007 23:51:37 +0530 Subject: Input events through network Message-ID: <47b5508f0712081021q39a18a7i55228a7c42f47f81@mail.gmail.com> Hi I am trying to bring Xserver up on a mips board.The board does not have any input devices . Is it possible to generate input events through the network?If so how? -Jenny From sergio at sergiomb.no-ip.org Sat Dec 8 11:21:41 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 08 Dec 2007 19:21:41 +0000 Subject: X lockups with xf86-video-i810-2.2.0 In-Reply-To: <200712072051.11487.at@drinian.org> References: <200712072051.11487.at@drinian.org> Message-ID: <1197141701.2917.12.camel@monteirov> On Fri, 2007-12-07 at 20:51 -0500, Andrew Todd wrote: > I was asked to pass this along from the Gentoo Bugzilla. There's a few people > with 945GM chipsets, including me, who are getting random lockups several > times a day with the 2.2.0 version of the Intel driver. > > Full trace here: > https://bugs.gentoo.org/show_bug.cgi?id=201519 > Please try the git version of intel drive -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From solca at guug.org Sat Dec 8 13:39:11 2007 From: solca at guug.org (Otto Solares) Date: Sat, 8 Dec 2007 15:39:11 -0600 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <475A7E9D.2070404@gmail.com> References: <20071207071823.GA16163@guug.org> <20071207081711.GC16163@guug.org> <475A7E9D.2070404@gmail.com> Message-ID: <20071208213911.GA22214@guug.org> On Sat, Dec 08, 2007 at 12:23:09PM +0100, Brice Goglin wrote: > Otto Solares wrote: > > On Fri, Dec 07, 2007 at 02:38:57AM -0500, Alex Deucher wrote: > > > >> Did you/debian also upgrade the xrandr utility to the latest version > >> in git as well? > >> > > > > No, I'm using Debian's: > > > > # which xrandr > > /usr/bin/xrandr > > # dpkg -S /usr/bin/xrandr > > x11-xserver-utils: /usr/bin/xrandr > > # dpkg -l x11-xserver-utils > > ii x11-xserver-utils 7.3+2 X server utilities > > > > This is xrandr 1.2.2, not the one from git. I don't know if Matthias > Hopf is done with his changes in xrandr, but it might be good to release > 1.2.3. Excuse my ignorance, how to fetch xrandr from git? -otto From brice.goglin at gmail.com Sat Dec 8 14:10:29 2007 From: brice.goglin at gmail.com (Brice Goglin) Date: Sat, 08 Dec 2007 23:10:29 +0100 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <20071208213911.GA22214@guug.org> References: <20071207071823.GA16163@guug.org> <20071207081711.GC16163@guug.org> <475A7E9D.2070404@gmail.com> <20071208213911.GA22214@guug.org> Message-ID: <475B1655.5000601@gmail.com> Otto Solares wrote: > On Sat, Dec 08, 2007 at 12:23:09PM +0100, Brice Goglin wrote: > >> Otto Solares wrote: >> >>> On Fri, Dec 07, 2007 at 02:38:57AM -0500, Alex Deucher wrote: >>> >>> >>>> Did you/debian also upgrade the xrandr utility to the latest version >>>> in git as well? >>>> >>>> >>> No, I'm using Debian's: >>> >>> # which xrandr >>> /usr/bin/xrandr >>> # dpkg -S /usr/bin/xrandr >>> x11-xserver-utils: /usr/bin/xrandr >>> # dpkg -l x11-xserver-utils >>> ii x11-xserver-utils 7.3+2 X server utilities >>> >>> >> This is xrandr 1.2.2, not the one from git. I don't know if Matthias >> Hopf is done with his changes in xrandr, but it might be good to release >> 1.2.3. >> > > Excuse my ignorance, how to fetch xrandr from git? > git clone git://anongit.freedesktop.org/git/xorg/app/xrandr cd xrandr ./autogen.sh make Brice From rjshaw at netspace.net.au Sat Dec 8 15:06:06 2007 From: rjshaw at netspace.net.au (Russell Shaw) Date: Sun, 09 Dec 2007 10:06:06 +1100 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <1197134398.7222.82.camel@HAL9000> References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> <475A9CC5.2080107@netspace.net.au> <1197134398.7222.82.camel@HAL9000> Message-ID: <475B235E.3090903@netspace.net.au> Mirco M?ller wrote: > Am Sonntag, den 09.12.2007, 00:31 +1100 schrieb Russell Shaw: > >>> I really tried this by pure chance as there is nothing in the man-page >>> of XCreateWindow() hinting someone towards this. This makes me wonder >>> again how anybody can properly learn developing against X11. >> You really need the "XLIB Programming Manual". >> >> http://www.amazon.com/Programming-Manual-Definitive-Guides-Window/dp/1565920023/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1197120206&sr=8-1 >> >> also "XLIB Reference Manual R5": >> >> http://www.amazon.com/Reference-Manual-Definitive-Guides-Window/dp/1565920066/ref=pd_sim_b_title_1 > > Aren't those X11R5-related book heavily out-dated? Under Linux we are > at X11R7 and things like Xcomposite, Xrender, Xfixes, Xdamage, Xrandr > etc. are not covered by these books. Most of the functions and window management in the R5 books still apply. The drawing stuff (like XDrawLine) still apply, but those functions are replaced now in newer apps with XRender etc. The XLIB Reference Manual is still excellent for a general overview of X. > Does anybody know, if there are updated editions of these books, > covering all the new X11-extensions, planned or available? > >> also useful, "OpenGL Programming for the X Window System": >> >> http://www.amazon.com/OpenGL-Programming-X-Window-System/dp/0201483599/ref=sr_1_1?ie=UTF8&s=books&qid=1197120535&sr=1-1 > > That might be more worthwhile. From cloos+pdx-xorg at jhcloos.com Sat Dec 8 15:12:27 2007 From: cloos+pdx-xorg at jhcloos.com (James Cloos) Date: Sat, 08 Dec 2007 23:12:27 +0000 Subject: Build problem In-Reply-To: <91705d080712080849x6dd7f21cgd8ec8a3c3720971a@mail.gmail.com> (Dan Nicholson's message of "Sat, 8 Dec 2007 08:49:42 -0800") References: <475A947B.60006@gmx.de> <91705d080712080849x6dd7f21cgd8ec8a3c3720971a@mail.gmail.com> Message-ID: >>>>> "Dan" == Dan Nicholson writes: Dan> No, you're right. If "EXTRA_DIST += ..." is the only occurrence in Dan> that Makefile.am, that's wrong. A massive addition to all the trees Dan> was made to support generating the ChangeLog, and part of it was this: Dan> EXTRA_DIST += ChangeLog I think I found all of the ones which needed fixing from the big push: doc/xorg-sgml-doctools app/fdclock app/xkbutils app/xphelloworld app/xrestop app/xrx and pushed those when the bug about doc/xorg-sgml-doctools came thru. I don't find any others grep(1)ing thru the git/xorg tree. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From pekane52 at gmail.com Sat Dec 8 19:48:30 2007 From: pekane52 at gmail.com (Pat Kane) Date: Sat, 8 Dec 2007 21:48:30 -0600 Subject: Window initial position In-Reply-To: References: Message-ID: On Dec 7, 2007 4:39 PM, Itamar Axelrod wrote: > How can I be sure the coor. I receive are the correct ones? Kill the window manager. or From jobi at via.ecp.fr Sun Dec 9 02:20:58 2007 From: jobi at via.ecp.fr (Johan Bilien) Date: Sun, 09 Dec 2007 12:20:58 +0200 Subject: Modes from LCD TV not read - intel 2.2.0 Message-ID: <1197195658.7575.6.camel@macbook> Hi, I'm trying to connect an LCD TV to the VGA output of my macbook (intel 945GM). Somehow X does not pick up the EDID information from the TV and xrandr lists the same modes for the laptop panel and the TV. Among these the TV only accepts 1024x768. $ xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 3200 x 1080 VGA connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x800 60.0* 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 286mm x 179mm 1280x800 59.9*+ 60.0 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 It worked once, the log then showed that the modes had indeed been read from EDID, but ever since it has failed the same way. I'm using the intel driver 2.2.0 and the server 1.4.1 from Debian. I attach my configuration and log. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 35808 bytes Desc: not available URL: -------------- next part -------------- # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Files" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load "i2c" Load "bitmap" Load "ddc" Load "dri" Load "extmod" Load "freetype" Load "glx" Load "int10" Load "vbe" EndSection # ##Section "InputDevice" # Identifier "Generic Keyboard" # Driver "kbd" # Option "CoreKeyboard" # Option "XkbRules" "xorg" # Option "XkbModel" "pc104" # Option "XkbLayout" "us" #EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/dev/psaux" Option "Protocol" "auto-dev" Option "SHMConfig" "true" Option "New AccelFactor" "0.03" Option "LeftEdge" "100" Option "RightEdge" "1120" Option "TopEdge" "50" Option "BottomEdge" "310" Option "FingerHigh" "30" Option "MinSpeed" "0.75" Option "MaxSpeed" "1" Option "AccelFactor" "0.0015" Option "FingerLow" "20" Option "HorizScrollDelta" "0" Option "MaxTapTime" "150" # Option "TapButton1" "1" Option "TapButton2" "3" Option "TapButton3" "2" Option "VertEdgeScroll" "1" Option "HorizEdgeScroll" "1" Option "VertScrollDelta" "5" Option "VertTwoFingerScroll" "0" Option "HorizTwoFingerScroll" "0" EndSection Section "Device" Identifier "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller" Driver "intel" BusID "PCI:0:2:0" Option "AccelMethod" "XAA" Option "XAANoOffscreenPixmaps" "true" Option "MigrationHeuristic" "greedy" Option "PageFlip" "true" # Option "TripleBuffer" "true" Option "monitor-TV" "On TV" Option "monitor-TMDS-1" "On DVI" EndSection Section "Monitor" Identifier "Generic Monitor" Option "DPMS" # HorizSync 28-64 # VertRefresh 43-60 EndSection Section "Monitor" Identifier "On DVI" Option "Ignore" "true" EndSection Section "Monitor" Identifier "On TV" Option "Ignore" "true" EndSection Section "Screen" Identifier "Default Screen" Device "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display" Depth 1 Modes "1280x800" EndSubSection SubSection "Display" Depth 4 Modes "1280x800" EndSubSection SubSection "Display" Depth 8 Modes "1280x800" EndSubSection SubSection "Display" Depth 15 Modes "1280x800" EndSubSection SubSection "Display" Depth 16 Modes "1280x800" EndSubSection SubSection "Display" Depth 24 Modes "1920x1080" "1280x800" Virtual 3200 1080 EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" # InputDevice "Generic Keyboard" InputDevice "Configured Mouse" InputDevice "Synaptics Touchpad" EndSection Section "DRI" Mode 0666 EndSection Section "Extensions" Option "Composite" "Enable" EndSection From hcb at chaoticmind.net Sun Dec 9 04:46:47 2007 From: hcb at chaoticmind.net (Helge Bahmann) Date: Sun, 9 Dec 2007 13:46:47 +0100 Subject: Looking for XRender examples In-Reply-To: References: <87tzmvels6.wl%cworth@cworth.org> <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> Message-ID: <200712091346.47393.hcb@chaoticmind.net> > On 06/12/2007, Clemens Eisserer wrote: > > > I have several sample programs and quite a bit of documentation about > > > Xrender, its model and how to use it written up for my students (mostly > > > in german though); if you are interested I can collect and tidy them up > > > (when I asked last time on this mailing list there was zero interest > > > apparently) > > > > That would be exactly what I was seraching for, perfect. By the way I > > am from Austria so german documentation would be awesome :) > > This seems the kind of content that could (should even, if the author > agrees) be put on the wiki, even if in german, someone else could then > translate it. okay I have uploaded most of the slides, documentation and sample programs to: http://www.chaoticmind.net/~hcb/xrender/ it does not completely cover XRender, but it may be a good starting point. Since there appears to be some interest I would volunteer to translate the material and maybe turn it into a more fleshed-out tutorial, so if you have comments or would like to help me please write me. Where would you ideally have me put it? (wiki?) Otherwise I will host it myself until a better place is found... Best regards Helge From zhen78 at gmail.com Sun Dec 9 13:39:56 2007 From: zhen78 at gmail.com (Zhenyu Wang) Date: Mon, 10 Dec 2007 05:39:56 +0800 Subject: Quirk problem in intel driver 2.2.0 (possible "patch" included) In-Reply-To: References: Message-ID: <20071209213956.GA25676@localdomain> On 2007.12.08 11:50:00 +0100, Andreas Schildbach wrote: > I think that line should read: > > /* Dell Latitude X1 */ > { PCI_CHIP_I915_GM, 0x1028, 0x01a3, quirk_ignore_tv }, Thanks for catch this one, seems Keith's typo. I'll push your fix. From jaymz at artificial-stupidity.net Sun Dec 9 06:16:06 2007 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Mon, 10 Dec 2007 01:16:06 +1100 Subject: Input events through network In-Reply-To: <47b5508f0712081021q39a18a7i55228a7c42f47f81@mail.gmail.com>; from jennytharayil@gmail.com on Sat, Dec 08, 2007 at 11:51:37PM +0530 References: <47b5508f0712081021q39a18a7i55228a7c42f47f81@mail.gmail.com> Message-ID: <20071210011605.L3771@artificial-stupidity.net> On Sat, Dec 08, 2007 at 11:51:37PM +0530, jenny tc wrote: > Hi > I am trying to bring Xserver up on a mips board.The board does not > have any input devices . Is it possible to generate input events > through the network?If so how? You could always use XTEST if you can run a simple client on there. --jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From dave.joubert at googlemail.com Sun Dec 9 06:40:29 2007 From: dave.joubert at googlemail.com (Dave Joubert) Date: Sun, 9 Dec 2007 14:40:29 +0000 Subject: Multiple mouse problem Message-ID: Hi, I am working on a hardware project with one mouse attached via /dev/psaux and 4 more USB mice attached via a USB hub. I want my desktop to ignore the extra mice, and have therefore modified xorg.conf: /etc/X11/xorg.conf-30-Section "InputDevice" /etc/X11/xorg.conf-31- Identifier "Configured Mouse" /etc/X11/xorg.conf-32- Driver "mouse" /etc/X11/xorg.conf-33- Option "CorePointer" /etc/X11/xorg.conf-34-# Option "Device" "/dev/input/mice" /etc/X11/xorg.conf:35: Option "Device" "/dev/psaux" /etc/X11/xorg.conf-36- Option "Protocol" "ImPS/2" /etc/X11/xorg.conf-37- Option "ZAxisMapping" "4 5" /etc/X11/xorg.conf-38- Option "Emulate3Buttons" "true" /etc/X11/xorg.conf-39-EndSection /var/log/Xorg.0.log confirms the config change.... 681 (**) Option "Protocol" "ImPS/2" 682 (**) Configured Mouse: Device: "/dev/psaux" 683 (**) Configured Mouse: Protocol: "ImPS/2" 684 (**) Option "CorePointer" 685 (**) Configured Mouse: Core Pointer 686 (**) Option "Device" "/dev/psaux" 687 (**) Option "Emulate3Buttons" "true" 688 (**) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 689 (**) Option "ZAxisMapping" "4 5" 690 (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 691 (**) Configured Mouse: Buttons: 9 692 (**) Configured Mouse: Sensitivity: 1 693 (**) Option "SendCoreEvents" When I plug the USB mice in, udev generates crw-rw---- 1 root root 13, 70 2007-12-09 13:46 event6 crw-rw---- 1 root root 13, 71 2007-12-09 13:46 event7 crw-rw---- 1 root root 13, 72 2007-12-09 13:46 event8 crw-rw---- 1 root root 13, 73 2007-12-09 13:46 event9 and crw-rw---- 1 root root 13, 34 2007-12-09 13:46 mouse2 crw-rw---- 1 root root 13, 35 2007-12-09 13:46 mouse3 crw-rw---- 1 root root 13, 36 2007-12-09 13:46 mouse4 crw-rw---- 1 root root 13, 37 2007-12-09 13:46 mouse5 as well as firing pass_env_to_socket: passed 143 bytes to socket '/org/freedesktop/hal/udev_event' and pass_env_to_socket: passed -1 bytes to socket '/org/kernel/udev/monitor' When I start using the additional mice, the cursor on the desktop reacts, which is unexpected. Ensuring that /org/freedesktop/hal/udev_event does not fire, does not solve the problem. I have the following packages installed (Kubuntu 7.10 but it was a problem in 7.4 as well) ii xorg 1:7.2-5ubuntu13 X.Org X Window System ii xserver-xorg 1:7.2-5ubuntu13 the X.Org X server ii xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8 X.Org X server -- core server ii xserver-xorg-input-all 1:7.2-5ubuntu13 the X.Org X server -- input driver metapacka ii xserver-xorg-input-evdev 1:1.1.5-3 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.2.0-1+1.2.1ubuntu1 X.OrgX server -- keyboard input driver ii xserver-xorg-input-mouse 1:1.2.1-1 X.Org X server -- mouse input driver I am truly stuck on this one. It used to work fine in the bad old days when one had to modify xorg.conf explicitly to add a second mouse. Dave Joubert -------------- next part -------------- An HTML attachment was scrubbed... URL: From saschahlusiak at arcor.de Sun Dec 9 08:00:36 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Sun, 9 Dec 2007 17:00:36 +0100 Subject: Multiple mouse problem In-Reply-To: References: Message-ID: <200712091701.02228.saschahlusiak@arcor.de> > When I start using the additional mice, the cursor on the desktop reacts, > which > is unexpected. Ensuring that /org/freedesktop/hal/udev_event does not fire, > does not solve the problem. Is anything added to the Xorg.0.log file as soon when you plug in the additional mice? Maybe they are added through hal, meaning Ubuntu shipped and installed the fdi file for input hotplugging. > I am truly stuck on this one. It used to work fine in the bad old days when > one had to modify > xorg.conf explicitly to add a second mouse. Geetings, Sascha -------------- 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 dave.joubert at googlemail.com Sun Dec 9 09:52:35 2007 From: dave.joubert at googlemail.com (Dave Joubert) Date: Sun, 9 Dec 2007 17:52:35 +0000 Subject: Multiple mouse problem In-Reply-To: <200712091701.02228.saschahlusiak@arcor.de> References: <200712091701.02228.saschahlusiak@arcor.de> Message-ID: On Dec 9, 2007 4:00 PM, Sascha Hlusiak wrote: > > > When I start using the additional mice, the cursor on the desktop > reacts, > > which > > is unexpected. Ensuring that /org/freedesktop/hal/udev_event does not > fire, > > does not solve the problem. > Is anything added to the Xorg.0.log file as soon when you plug in the > additional mice? Maybe they are added through hal, meaning Ubuntu shipped > and > installed the fdi file for input hotplugging. No, there is nothing in the log file after the initial startup. Log file ends: (**) Option "Protocol" "ImPS/2" (**) Configured Mouse: Device: "/dev/psaux" (**) Configured Mouse: Protocol: "ImPS/2" (**) Option "CorePointer" (**) Configured Mouse: Core Pointer (**) Option "Device" "/dev/psaux" (==) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 (**) Configured Mouse: Buttons: 9 (**) Configured Mouse: Sensitivity: 1 (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD) (II) Configured Mouse: ps2EnableDataReporting: succeeded Also, as I said, if I comment out /etc/udev/rules.d/95-hal.rules # Have udev pass data over a socket to hal # RUN+="socket:/org/freedesktop/hal/udev_event" (and I can see in /var/log/daemon.log that org/freedesktop/hal/udev_event is not triggered); it makes no difference. syslog confirms there is no hal event after initial startup. lsof (filtered for Xorg and (dev|socket|proc|) says: Xorg 5205 root mem CHR 1,1 2805 /dev/mem Xorg 5205 root 3u unix 0xffff810071d7d8c0 30756 socket Xorg 5205 root 4u CHR 4,7 2575 /dev/tty7 Xorg 5205 root 5u REG 0,3 256 4026531988 /proc/bus/pci/01/00.0 Xorg 5205 root 6w REG 0,3 0 4026531914 /proc/mtrr Xorg 5205 root 7u CHR 10,1 4324 /dev/psaux Still stumped..... > > > > I am truly stuck on this one. It used to work fine in the bad old days > when > > one had to modify > > xorg.conf explicitly to add a second mouse. > > > Geetings, > Sascha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saschahlusiak at arcor.de Sun Dec 9 10:00:52 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Sun, 9 Dec 2007 19:00:52 +0100 Subject: Multiple mouse problem In-Reply-To: References: <200712091701.02228.saschahlusiak@arcor.de> Message-ID: <200712091901.02022.saschahlusiak@arcor.de> > > Is anything added to the Xorg.0.log file as soon when you plug in the > > additional mice? Maybe they are added through hal, meaning Ubuntu shipped > > and > > installed the fdi file for input hotplugging. > > No, there is nothing in the log file after the initial startup. > Log file ends: > (**) Option "Protocol" "ImPS/2" > (**) Configured Mouse: Device: "/dev/psaux" Us, quoting from "make menuconfig": "The data available through /dev/psaux is exactly the same as the data from /dev/input/mice." So you are still using a multiplexer, that gives you the data of all mice together. Try using one device of /dev/input/{mouse,event}*, if there is one for your PS2 mouse. Sascha -------------- 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 at at drinian.org Sun Dec 9 11:44:36 2007 From: at at drinian.org (Andrew Todd) Date: Sun, 9 Dec 2007 14:44:36 -0500 Subject: X lockups with xf86-video-i810-2.2.0 In-Reply-To: <1197141701.2917.12.camel@monteirov> References: <200712072051.11487.at@drinian.org> <1197141701.2917.12.camel@monteirov> Message-ID: <200712091444.36859.at@drinian.org> On 2007 December 08 Saturday 14:21:41 Sergio Monteiro Basto wrote: > Please try the git version of intel drive Still locks up occasionally. Latest stack trace: (II) intel(0): xf86BindGARTMemory: bind key 1 at 0x01000000 (pgoffset 4096) (II) intel(0): xf86BindGARTMemory: bind key 2 at 0x02800000 (pgoffset 10240) (II) intel(0): xf86BindGARTMemory: bind key 3 at 0x03000000 (pgoffset 12288) (II) intel(0): xf86BindGARTMemory: bind key 4 at 0x03800000 (pgoffset 14336) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000007f820000 physical ) (II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000007fe20000 physical ) (II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000007fe21000 physical ) (II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB) (II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000007fe33000 physical ) (II) intel(0): 0x007bf000: end of stolen memory (II) intel(0): 0x00800000-0x00ffffff: front buffer (7680 kB) X tiled (II) intel(0): 0x01000000-0x0267ffff: exa offscreen (23040 kB) (II) intel(0): 0x02800000-0x02ffffff: back buffer (7680 kB) X tiled (II) intel(0): 0x03000000-0x037fffff: depth buffer (7680 kB) X tiled (II) intel(0): 0x03800000-0x057fffff: classic textures (32768 kB) (II) intel(0): 0x10000000: end of aperture (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x05e18bfc) and PRB0_TAIL (0x00018da8) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. From dave.joubert at googlemail.com Sun Dec 9 12:11:39 2007 From: dave.joubert at googlemail.com (Dave Joubert) Date: Sun, 9 Dec 2007 20:11:39 +0000 Subject: Multiple mouse problem In-Reply-To: <200712091901.02022.saschahlusiak@arcor.de> References: <200712091701.02228.saschahlusiak@arcor.de> <200712091901.02022.saschahlusiak@arcor.de> Message-ID: On Dec 9, 2007 6:00 PM, Sascha Hlusiak wrote: > > > Is anything added to the Xorg.0.log file as soon when you plug in the > > > additional mice? Maybe they are added through hal, meaning Ubuntu > shipped > > > and > > > installed the fdi file for input hotplugging. > > > > No, there is nothing in the log file after the initial startup. > > Log file ends: > > (**) Option "Protocol" "ImPS/2" > > (**) Configured Mouse: Device: "/dev/psaux" > > Us, quoting from "make menuconfig": "The data available through /dev/psaux > is > exactly the same as the data from /dev/input/mice." > So you are still using a multiplexer, that gives you the data of all mice > together. Try using one device of /dev/input/{mouse,event}*, if there is > one > for your PS2 mouse. Thanks Sascha, that solved it for me. udev has mapped the PS2 port to /dev/input/mouse1 > > Sascha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbn.lists at gmail.com Sun Dec 9 14:00:01 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sun, 9 Dec 2007 14:00:01 -0800 Subject: Multiple mouse problem In-Reply-To: References: <200712091701.02228.saschahlusiak@arcor.de> <200712091901.02022.saschahlusiak@arcor.de> Message-ID: <91705d080712091400t712df0e2n8831389af047387f@mail.gmail.com> On Dec 9, 2007 12:11 PM, Dave Joubert wrote: > On Dec 9, 2007 6:00 PM, Sascha Hlusiak wrote: > > > > > > Is anything added to the Xorg.0.log file as soon when you plug in the > > > > additional mice? Maybe they are added through hal, meaning Ubuntu > shipped > > > > and > > > > installed the fdi file for input hotplugging. > > > > > > No, there is nothing in the log file after the initial startup. > > > Log file ends: > > > (**) Option "Protocol" "ImPS/2" > > > (**) Configured Mouse: Device: "/dev/psaux" > > > > Us, quoting from "make menuconfig": "The data available through /dev/psaux > is > > exactly the same as the data from /dev/input/mice." > > So you are still using a multiplexer, that gives you the data of all mice > > together. Try using one device of /dev/input/{mouse,event}*, if there is > one > > for your PS2 mouse. > > Thanks Sascha, that solved it for me. udev has mapped the PS2 port to > /dev/input/mouse1 One thing you might want to do is use the persistent symlinks that recent udev sets up. Since the order it receives events from the kernel isn't consistent across boots, that device may not always be at input/mouse1. Instead, look at the symlinks in /dev/input/by-id. -- Dan From simon.thum at gmx.de Sun Dec 9 14:22:45 2007 From: simon.thum at gmx.de (Simon Thum) Date: Sun, 09 Dec 2007 23:22:45 +0100 Subject: Build problem In-Reply-To: References: <475A947B.60006@gmx.de> <91705d080712080849x6dd7f21cgd8ec8a3c3720971a@mail.gmail.com> Message-ID: <475C6AB5.5090107@gmx.de> James Cloos wrote: > doc/xorg-sgml-doctools > app/fdclock > app/xkbutils > app/xphelloworld > app/xrestop > app/xrx > > and pushed those when the bug about doc/xorg-sgml-doctools came thru. > > I don't find any others grep(1)ing thru the git/xorg tree. My build went (quite) well now, so I guess no package is left broken. Thank you! From rkfrancis at comcast.net Sun Dec 9 15:32:56 2007 From: rkfrancis at comcast.net (Robert Ken Francis) Date: Sun, 9 Dec 2007 18:32:56 -0500 Subject: RgbPath doesn't exist Message-ID: <000001c83abb$d3eeff50$0a2ea8c0@monster4c> Excuse my n00biness but... In my xorg.conf.new I have: RgbPath "/usr/local/share/X11/rgb" but that path doesn't exist. Will this be a problem? What is this used for? I'm running FreeBSD stable, xorg 7.3. Thanks the n00b No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.17/1179 - Release Date: 12/9/2007 11:06 AM From andrew at mcmillan.net.nz Sun Dec 9 16:01:32 2007 From: andrew at mcmillan.net.nz (Andrew McMillan) Date: Mon, 10 Dec 2007 13:01:32 +1300 Subject: MoinMoin to MediaWiki Conversion In-Reply-To: <20071128200439.GE30794@bryceharrington.org> References: <20071128183851.GM3067@fooishbar.org> <20071128200439.GE30794@bryceharrington.org> Message-ID: <1197244892.31714.224.camel@hippy.mcmillan.net.nz> On Wed, 2007-11-28 at 12:04 -0800, Bryce Harrington wrote: > On Wed, Nov 28, 2007 at 08:38:51PM +0200, Daniel Stone wrote: > > Hi, > > As you may have noticed, our website is pretty crap. I had fairly grand > > plans to fix it, but the current spam influx with Moin has drained any > > will I had to work on it, and realistically, I'm overcommitted anyway. > > > > So, does anyone want to work on the website? It looks like an ideal > > solution will involve moving away from Moin, as well as properly > > namespacing a lot of stuff, cleaning everything up, doing a tiny bit of > > design work to make it look good, and generally making it something > > people will want to work with to improve, rather than just battle > > against. > > Would mediawiki be an option? I set up mediawiki for Inkscape > (http://wiki.inkscape.org) which has turned out quite nicely. > > We had some spam issues at first, but I tightened up the settings and > installed a couple spam plugins, and we've not really had any issues > since (see RecentChanges). I added a few moderators who take care of > the oddball stuff that slips through, but otherwise it's been > maintenance-free for me. It's also proven to be quite ameniable to > theming. There seems to be quite a bit of experienced mediawiki users > out there to make good use of its features, too. > > Anyway, my time's also pretty limited, but I've set up many mediawiki's, > and I think this is something that'd pay off well - I'm frequently > looking for X.org info that *ought* to be on wiki.x.org but isn't. :-) Hi, We're in the process of converting an internal MoinMoin wiki (roughly 3500 pages) to Mediawiki and have found a couple of tools to help do the job. Unfortunately both tools we have found aren't very complete (one in Perl & one in Python) so I have someone working on enhancing them and that should be in a releasable state in about a week. Code for the work is in our public Git repository here: http://git.catalyst.net.nz/gw/moin2media.git This is based on an original conversion program by Jeff Licquia, merged to use the Wiki parser from MoinMoin itself, which builds a MediaWiki export format XML file. This is combined with some additional code (in Ruby) to handle splitting / uploading of that file because it turns out to be too large to do in one hit. Later on this week we'll be publishing some more detailed usage instructions and so forth, but it seems timely to at least mention the existence of this in case there is a decision to switch from MoinMoin. Regards, Andrew McMillan. ------------------------------------------------------------------------- Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 It is often easier to tame a wild idea than to breathe life into a dull one. -- Alex Osborn ------------------------------------------------------------------------- From mailinglists at who-t.net Sun Dec 9 17:00:09 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Mon, 10 Dec 2007 11:30:09 +1030 Subject: Input events through network In-Reply-To: <20071210011605.L3771@artificial-stupidity.net> References: <47b5508f0712081021q39a18a7i55228a7c42f47f81@mail.gmail.com> <20071210011605.L3771@artificial-stupidity.net> Message-ID: <475C8F99.4020608@who-t.net> Jaymz Julian wrote: > On Sat, Dec 08, 2007 at 11:51:37PM +0530, jenny tc wrote: >> Is it possible to generate input events through the network?If so how? > > You could always use XTEST if you can run a simple client on there. Alternatively, you could just write a simple input driver that listens for events on the network and passes them up through the proper APIs. Cheers, Peter From mailinglists at who-t.net Sun Dec 9 17:02:52 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Mon, 10 Dec 2007 11:32:52 +1030 Subject: Window initial position In-Reply-To: References: Message-ID: <475C903C.8090104@who-t.net> Itamar Axelrod wrote: > How can I be sure the coor. I receive are the correct ones? IIRC you should get a configure notify each time the WM moves your window. Subscribe to those and you know when your window has been moved. Cheers, Peter From florian.harmuth at googlemail.com Sun Dec 9 23:21:47 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Mon, 10 Dec 2007 08:21:47 +0100 Subject: Using XVideo extension? In-Reply-To: <475815AE.50703@hummingbird.com> References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> Message-ID: Sorry that i have to reask again -> actually i get my image informations as XImage struct. Is it possible to convert/cast this information to the XRenders Picture format? Best Regards, flo 2007/12/6, Peter Harris : > > Florian Harmuth wrote: > > Hello, > > thx for your answer -> how to find a documentation about the XRender > > lib/api? > > This documents the protocol: > > http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt > > The API in > > http://gitweb.freedesktop.org/?p=xorg/lib/libXrender.git;a=blob;f=include/X11/extensions/Xrender.h > follows the protocol fairly closely. > > > Are there any new books about programming under X? ( newer as > > 1993...) > > Not that I am aware of. I generally prefer to read source code (as it is > always more accurate). > > Peter Harris > > -- > Hummingbird Connectivity - A Division of Open Text > Peter Harris http://connectivity.hummingbird.com > Research and Development Phone: +1 905 762 6001 > peter.harris at hummingbird.com Toll Free: 1 877 359 4866 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LongdaFeng at viatech.com.cn Mon Dec 10 00:44:00 2007 From: LongdaFeng at viatech.com.cn (LongdaFeng at viatech.com.cn) Date: Mon, 10 Dec 2007 16:44:00 +0800 Subject: how to get memory's physical address in user-mode? In-Reply-To: Message-ID: <00DA072AF14656448C31F5C0182E7D0A069B90A7@exchsh01.viatech.com.sh> Dear friends: I am sorry for asking this question here? But it trouble me much, and thank you very much whatever you suggest!!!!! The question is as down: I malloc 16k memory in user mode (1) how to make this memory reserved, it means that it can?t be swap out (2) how to get this memory?s physical address I know the method implement this in kernel mode, but I don?t know how to do this in user mode. Thank you very much!!! Best regards Longda Feng -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at tungstengraphics.com Mon Dec 10 01:18:38 2007 From: michel at tungstengraphics.com (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Mon, 10 Dec 2007 10:18:38 +0100 Subject: [PATCH] add EXA relocation function In-Reply-To: <200712071333.56545.jbarnes@virtuousgeek.org> References: <200712071333.56545.jbarnes@virtuousgeek.org> Message-ID: <1197278318.15055.128.camel@thor.sulgenrain.local> On Fri, 2007-12-07 at 13:33 -0800, Jesse Barnes wrote: > In order to avoid having a fixed offset for the EXA offscreen area (which is > nice if the driver is using TTM) drivers need to update the base offset of > EXA memory in EnterVT, and may need to update any private pointers they've > allocated as well (e.g. for the cursor or scanout buffers, etc.). > > Since the server already kicks out all the pixmaps at VT switch time, the > relocation is trivial and will typically just involve the one, big free area > and any locked driver allocations; this function reflects that. > > One possible enhancement would be to call back into a driver provided function > to update the private allocations, but it wouldn't really save any code... > > Any thoughts on this? I'm not sure it's really worth it, compared to using the existing CreatePixmap hook for allocating pixmaps from a generic memory manager such as TTM in the first place. Is there anything the latter can't do that the former can? -- Earthling Michel D?nzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer From matthieu.herrb at laas.fr Mon Dec 10 01:41:57 2007 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Mon, 10 Dec 2007 10:41:57 +0100 Subject: radeon zaphod the return... In-Reply-To: <21d7e9970712062146l37db83cfv3907d938d75a0c0a@mail.gmail.com> References: <21d7e9970712062146l37db83cfv3907d938d75a0c0a@mail.gmail.com> Message-ID: <475D09E5.6060406@laas.fr> Dave Airlie wrote: > Okay if you take a look at the zaphod-lolz branch > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=zaphod-lolz > > I've managed to bring back zaphod without majorly impacting on the > driver, randr-1.2 actually makes it quite easy to implement. > > Each head in theory still exports randr-1.2 interfaces in non-Xinerama mode.... > > I'd like to merge this into master quickly and also into > atombios-support so I can do this on r500 class cards. The zaphod-lolz branch ore or less works for me while none of the recent 6.6 release did (see https://bugs.freedesktop.org/show_bug.cgi?id=11852) Remaining problems: - The monitors come up inverted by default (ie Screen :0.0 is now on VGA and :0.1 is now on DVI-0, it used to be the opposite with the last working driver), but I can live with that. - Upon exit text mode is not restored correctly, - XVideo produces garbage on screen :0.1 (it used to work long ago). -- Matthieu Herrb -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4033 bytes Desc: S/MIME Cryptographic Signature URL: From bve at gmx.de Mon Dec 10 02:45:59 2007 From: bve at gmx.de (Ben E. Hard) Date: Mon, 10 Dec 2007 11:45:59 +0100 Subject: blank screen on LVDS when VGA connected Message-ID: <200712101146.00103.bve@gmx.de> Hi, Hallo, when I have a VGA-Monitor connected to my Sony Vaio Laptop (PCG-R600 HFPD), the internal LVDS gets deactivated. I tried all the xrandr --output LVDS --left-of VGA stuff, nothing changes. System: debian lenny, xserver-xorg-video-intel 2.1.0-2 (now trying with xserver-xorg-video-intel 2.2.0-1 from debian unstable). However, kde thinks, that there is a second monitor, where it can put my applications, which I cannot see than. The tool i810switch or i810rotate permits me to reactivate the internal monitor, giving me a clone of the other. xrandr -q shows me, that I can disconnect the ouptut VGA with i810rotate, but not the LVDS, which is always shown as "connected" in xrandr -q. xrandr -q output: Screen 0: minimum 320 x 200, current 2048 x 768, maximum 2048 x 768 VGA connected 1024x768+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x768 60.0 1024x768 60.0* 800x600 60.3 640x480 59.9 LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 1280x768 60.0 800x600 60.3 640x480 59.9 Part of xorg.conf Driver "intel" Option "monitor-VGA" "externer" Option "monitor-LVDS" "interner" Option "NoDDC" Option "DDCmode" "off" Option "IgnoreEDID" "on" Option "XAANoOffscreenPixmaps" "true" Option "DRI" "true" EndSection Section "Monitor" Identifier "interner" Option "PreferredMode" "1024x768" DisplaySize 270 203 EndSection Section "Monitor" Identifier "externer" Option "RightOf" "interner" EndSection Section "Screen" Identifier "Default Screen" Device "intel" Monitor "interner" Monitor "externer" DefaultDepth 16 SubSection "Display" Virtual 2048 768 Depth 16 EndSubSection SubSection "Display" Depth 24 Virtual 2048 768 EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" "AlwaysCore" InputDevice "ALPS" "CorePointer" InputDevice "Vaio keys" "SendCoreEvents" Option "AIGLX" "true" EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "DRI" Group "video" Mode 0660 EndSection Any other information I can provide? Greetings, Ben From i.r.wezeman at hetnet.nl Mon Dec 10 03:53:38 2007 From: i.r.wezeman at hetnet.nl (i.r.wezeman at hetnet.nl) Date: Mon, 10 Dec 2007 12:53:38 +0100 Subject: xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' References: <4756BD58.5010208@tungstengraphics.com> Message-ID: In file included from /SOURCE/mesa/include/GL/xmesa.h:76, from xm_api.c:66: /SOURCE/mesa/include/GL/xmesa_xf86.h:172:1: warning: "CREATE_PIXMAP_USAGE_SCRATCH" redefined In file included from /SOURCE/mesa/include/GL/xmesa_xf86.h:43, from /SOURCE/mesa/include/GL/xmesa.h:76, from xm_api.c:66: ./../../include/scrnintstr.h:201:1: warning: this is the location of the previous definition In file included from /SOURCE/mesa/include/GL/xmesa.h:76, from xm_buffer.c:33: /SOURCE/mesa/include/GL/xmesa_xf86.h:172:1: warning: "CREATE_PIXMAP_USAGE_SCRATCH" redefined In file included from /SOURCE/mesa/include/GL/xmesa_xf86.h:43, from /SOURCE/mesa/include/GL/xmesa.h:76, from xm_buffer.c:33: ./../../include/scrnintstr.h:201:1: warning: this is the location of the previous definition xm_buffer.c: In function 'alloc_back_buffer': xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' make: *** [xm_buffer.lo] Error 1 make: *** Waiting for unfinished jobs.... xm_api.c: In function 'setup_8bit_hpcr': xm_api.c:877: error: too few arguments to function 'v->display->CreatePixmap' make: *** [xm_api.lo] Error 1 bash-3.1# -----Original Message----- From: Brian Paul [mailto:brian.paul at tungstengraphics.com] Sent: Wed 12/5/2007 4:01 PM To: i.r.wezeman at hetnet.nl Cc: xorg at lists.freedesktop.org Subject: Re: xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' i.r.wezeman at hetnet.nl wrote: > Today build drm and mesa without errors with branch master. > > When building branch master on xorg/xserver with --prefix=/G and > --with-mesa-source=/SOURCE/mesa the next error: > > > Making all in X > make[3]: Entering directory `/SOURCE/xorg/xserver/GL/mesa/X' > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi > -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl > -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD > -MP -MF .deps/xm_api.Tpo -c -o xm_api.lo xm_api.c > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I../../../include -I/SOURCE/mesa/include -I../X -I../glapi > -I../main -I../math -I../shader -I../swrast -I../swrast_setup -I../tnl > -I.. -I../../glx -I../../../GL/glx -I../../../GL/include > -I../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo > -MD -MP -MF deps/xm_buffer.Tpo -c -o xm_buffer.lo xm_buffer.c > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include > -I../X -I../glapi -I../main -I../math -I../shader -I../swrast > -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx > -I../../../GL/include -I../../../hw/xfree86/os-support > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_api.lo -MD > -MP -MF .deps/xm_api.Tpo -c xm_api.c -fPIC -DPIC -o libs/xm_api.o > gcc -DHAVE_CONFIG_H -I. -I../../../include -I/SOURCE/mesa/include > -I../X -I../glapi -I../main -I../math -I../shader -I../swrast > -I../swrast_setup -I../tnl -I.. -I../../glx -I../../../GL/glx > -I../../../GL/include -I../../../hw/xfree86/os-support > -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -DDBUS_API_SUBJECT_TO_CHANGE -I/G/include -I/G/include/freetype2 > -I/G/include/pixman-1 -I/G/include/hal -I/G/include/dbus-1.0 > -I/G/lib/dbus-1.0/include -I/G/include -I../../../include > -I../../../include -I../../../Xext -I../../../composite > -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi > -I../../../miext/shadow -I../../../miext/damage -I../../../render > -I../../../randr -I../../../fb -DXFree86Server -g -O2 -MT xm_buffer.lo > -MD -MP -MF .deps/xm_buffer.Tpo -c xm_buffer.c -fPIC -DPIC -o > libs/xm_buffer.o > xm_buffer.c: In function 'alloc_back_buffer': > xm_buffer.c:226: error: too few arguments to function > 'b->xm_visual->display->CreatePixmap' > make[3]: *** [xm_buffer.lo] Error 1 > make[3]: *** Waiting for unfinished jobs.... > xm_api.c: In function 'setup_8bit_hpcr': > xm_api.c:877: error: too few arguments to function > 'v->display->CreatePixmap' > make[3]: *** [xm_api.lo] Error 1 > make[3]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa/X' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/SOURCE/xorg/xserver/GL/mesa' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/SOURCE/xorg/xserver/GL' > make: *** [all-recursive] Error 1 In Mesa/include/GL/xmesa_xf86.h, try adding this: #define CREATE_PIXMAP_USAGE_SCRATCH before line 172. Let me know what the compiler does. CREATE_PIXMAP_USAGE_SCRATCH _should_ be defined in scrnintstr.h if the CreatePixmap function needs a 5th argument. I don't know why this isn't working otherwise. -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vignatti at c3sl.ufpr.br Mon Dec 10 04:58:43 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Mon, 10 Dec 2007 10:58:43 -0200 Subject: how to get memory's physical address in user-mode? In-Reply-To: <00DA072AF14656448C31F5C0182E7D0A069B90A7@exchsh01.viatech.com.sh> References: <00DA072AF14656448C31F5C0182E7D0A069B90A7@exchsh01.viatech.com.sh> Message-ID: <475D3803.3020803@c3sl.ufpr.br> LongdaFeng at viatech.com.cn escreveu: > I malloc 16k memory in user mode > > (1) how to make this memory reserved, it means that it can?t be > swap out > > (2) how to get this memory?s physical address > This seems pretty off topic to the xorg list. Anyway you can see some of my posts which will certainly interest you: http://vignatti.wordpress.com/2007/08/10/mlocking-adventure/ http://vignatti.wordpress.com/2007/07/27/page-fault-notifier/ http://vignatti.wordpress.com/2007/07/17/xorg-input-thread-summary-or-something-2/ If you have more questions, feel free to ask to me in private. my regards, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From Benjamin.Close at clearchain.com Mon Dec 10 06:17:20 2007 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Tue, 11 Dec 2007 00:47:20 +1030 Subject: [Notice]: DRI website shifted From gabe -> annarchy Message-ID: <475D4A70.1070701@clearchain.com> Hi All, Just letting you know that as part of the planned server migration plan, the dri.freedesktop.org virtual host (dns/website/files/wiki) have now moved from gabe to annarchy (people.fd.o). Files are still available on gabe but have all become read only. Please let me know if you notice anything no longer working. Cheers, Benjamin fd.o SiteWrangler From michel at tungstengraphics.com Mon Dec 10 06:45:58 2007 From: michel at tungstengraphics.com (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Mon, 10 Dec 2007 15:45:58 +0100 Subject: xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' In-Reply-To: References: <4756BD58.5010208@tungstengraphics.com> Message-ID: <1197297958.15055.163.camel@thor.sulgenrain.local> On Mon, 2007-12-10 at 12:53 +0100, i.r.wezeman at hetnet.nl wrote: > In file included from /SOURCE/mesa/include/GL/xmesa.h:76, > from xm_api.c:66: > /SOURCE/mesa/include/GL/xmesa_xf86.h:172:1: warning: > "CREATE_PIXMAP_USAGE_SCRATCH" redefined > In file included from /SOURCE/mesa/include/GL/xmesa_xf86.h:43, > from /SOURCE/mesa/include/GL/xmesa.h:76, > from xm_api.c:66: > ./../../include/scrnintstr.h:201:1: warning: this is the location of > the previous definition > In file included from /SOURCE/mesa/include/GL/xmesa.h:76, > from xm_buffer.c:33: > /SOURCE/mesa/include/GL/xmesa_xf86.h:172:1: warning: > "CREATE_PIXMAP_USAGE_SCRATCH" redefined > In file included from /SOURCE/mesa/include/GL/xmesa_xf86.h:43, > from /SOURCE/mesa/include/GL/xmesa.h:76, > from xm_buffer.c:33: > ./../../include/scrnintstr.h:201:1: warning: this is the location of > the previous definition > xm_buffer.c: In function 'alloc_back_buffer': > xm_buffer.c:226: error: too few arguments to function 'b->xm_visual->display->CreatePixmap' So /SOURCE/mesa/include/GL/xmesa_xf86.h doesn't seem to be from the current mesa Git master branch. -- Earthling Michel D?nzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer From Eeri.Kask at inf.tu-dresden.de Mon Dec 10 07:29:02 2007 From: Eeri.Kask at inf.tu-dresden.de (Eeri Kask) Date: Mon, 10 Dec 2007 16:29:02 +0100 Subject: [vtwm-hackers] TWM: truetype support (now for VTWM) In-Reply-To: <4731DA27.8030600@inf.tu-dresden.de> References: <473100BA.2090700@inf.tu-dresden.de> <20071107024256.GA52603@omma.gibson.athome> <4731DA27.8030600@inf.tu-dresden.de> Message-ID: <475D5B3E.8090700@inf.tu-dresden.de> >> }Hello twm users, >> } >> }let me kindly present recent advancements done to the twm window >> }manager. Attached is a tar file containing the following tar files: >> >> Thanks Eeri. Now we just need someone to port the diffs to vtwm. >> >> C > > > As there seems interest I definitely want to do that in principle. > The first part (preparatory cleanup work for porting > twm-1.0.3-diff1.MyFont_ChangeGC.tgz) is the most tedious part I think, > but not that hard. [....] Hello vtwm users, Here comes what I once promised: attached are (*) vtwm-5.4.7-diff0-2.tar (*) VTWM-Tweaked.sh (You can get these at www.inf.tu-dresden.de/~ek1/vtwm-5.4.7-diff0-2.tar www.inf.tu-dresden.de/~ek1/VTWM-Tweaked.sh as well.) In fact this is only a very preliminary patchset, I only ported some of the twm work to vtwm over the weekend with as little effort as I only could. Included are: (*) Imakefile.no-sound.diff this disables sound support (I don't have rplay installed, ... and I prefer silence anyway. :-) If you run VTWM-Tweaked.sh for automatic compile and want sound, then manually please comment out the appropriate line in that script you'll find easily. (*) Intro-twm.h.diff Intro-screen.h.diff I had problems with the 'Image'-data structure in util.h being unknown to the compiler so I had to change the order some header files are included. (*) vtwm-5.4.7-diff0.NO_I18N_SUPPORT.tgz This is the most intrusive cleanup patch I had to do to vtwm in order to start Xft support work at all. Hereby I ask anyone among vtwm developers with free time and interest in helping to read these line-by-line and detect places I have unintentionally screwed up. :-) NO_I18N_SUPPORT now actually only determines how window and icon names are retrieved from window properties, and I think this could be streamlined as well, i.e. one should remove this configuration parameter entirely (i18n support will be determined in run-time evaluating some locale-functions, as twm does). (*) vtwm-5.4.7-diff1.MyFont_ChangeGC.tgz (*) vtwm-5.4.7-diff2.TWM_USE_XFT.tgz These come directly from twm, I even was 'lazy' to change TWM_USE_XFT into VTWM_USE_XFT (as simply being irrelevant). (*) dot.vtwmrc Slightly edited system.vtwmrc file I used for testing, to reflect my keyboard shortcut preferences. If you are a vtwm user, please test this in all your configurations and lets sort out bugs et cetera you may encounter. I haven't tested the "doors" part because I dont know yet what they are and how to make use of them, thought. Spacing corrections are missing for now as vtwm code is a little harder to read in that respect but at least some icon labeling adjustments need to be done. Opacity support is as an easy part coming as well. Then later the sloppy-focus if finished for twm will follow for sure as my elbow unintentionally moves the mouse out of windows permanently otherwise resulting in constant hassle in using computers. :-) Greetings and have fun, Eeri Kask P.S. Apply against vtwm-5.4.7.tar.gz (or only run the script attached). -------------- next part -------------- A non-text attachment was scrubbed... Name: VTWM-Tweaked.sh Type: application/x-shellscript Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vtwm-5.4.7-diff0-2.tar Type: application/x-tar Size: 30720 bytes Desc: not available URL: From simon.thum at gmx.de Mon Dec 10 07:32:37 2007 From: simon.thum at gmx.de (Simon Thum) Date: Mon, 10 Dec 2007 16:32:37 +0100 Subject: build.sh stops with "not a git repository" and autogen error In-Reply-To: <8419385.24721196869136672.JavaMail.defaultUser@defaultHost> References: <8419385.24721196869136672.JavaMail.defaultUser@defaultHost> Message-ID: <475D5C15.5080207@gmx.de> Mattias Andersson wrote: > Hi all! > This is my first mail on the list. > I searched everywhere for the answer on > why the build.sh stops on two places: > luit and xconsole, both in the "app" directory. I recently did a build and it went ok. You should provide more details, e.g. what exactly you are trying to build (git, tarballs,...) E.g. I don't even have a luit/luit-1.0.2/ dir, it's app/luit. Build.sh is very dependent on tree structure. -- Simon From peter.harris at hummingbird.com Mon Dec 10 08:15:21 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Mon, 10 Dec 2007 11:15:21 -0500 Subject: Using XVideo extension? In-Reply-To: References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> Message-ID: <475D6619.8030106@hummingbird.com> Florian Harmuth wrote: > Sorry that i have to reask again -> actually i get my image informations > as XImage struct. Is it possible to convert/cast this information to the > XRenders Picture format? In order to implement your StretchImage(), the process would look something like: XRenderCreatePicture(window) XCreatePixmap() XRenderCreatePicture(pixmap) # If the input size is constant, the above only need to be done once XRenderSetPictureTransform(pixmap_picture) # The above line is only needed when the amount of stretch changes XPutImage(pixmap) # XImage struct used here XRenderCompositeImage(pixmap_picture, null_mask, window_picture) # Free pictures and pixmap here, unless cached Setting a non-default filter to smooth out the scaling is left as an exercise for the reader. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From alan.coopersmith at sun.com Mon Dec 10 08:52:00 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Mon, 10 Dec 2007 08:52:00 -0800 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <475A9CC5.2080107@netspace.net.au> References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> <475A9CC5.2080107@netspace.net.au> Message-ID: <475D6EB0.8000002@sun.com> Russell Shaw wrote: > Mirco M?ller wrote: >> Am Samstag, den 08.12.2007, 07:59 +0100 schrieb Mirco M?ller: >> >>> When calling XCreateWindow() like... >>> >>> window = XCreateWindow (pDisplay, >>> RootWindow (pDisplay, >>> pVisInfo[i].screen), >>> 50, >>> 50, >>> 300, >>> 300, >>> 0, >>> pVisInfo[i].depth, >>> InputOutput, >>> pVisInfo[i].visual, >>> iWindowAttribsMask, >>> &windowAttribs); >>> >>> I get a... >>> >>> X Error of failed request: BadMatch (invalid parameter attributes) >>> Major opcode of failed request: 1 (X_CreateWindow) >>> Serial number of failed request: 13 >>> Current serial number in output stream: 16 >> In the meantime I was able to fix this by the very "scientific" >> approach of trial-and-error. It turned out to be missing... >> >> windowAttribs.border_pixel = 0; >> >> ... and... >> >> iWindowAttribsMask = CWBorderPixel | CWEventMask | CWColormap; >> >> I really tried this by pure chance as there is nothing in the man-page >> of XCreateWindow() hinting someone towards this. This makes me wonder >> again how anybody can properly learn developing against X11. > > You really need the "XLIB Programming Manual". > > http://www.amazon.com/Programming-Manual-Definitive-Guides-Window/dp/1565920023/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1197120206&sr=8-1 > > also "XLIB Reference Manual R5": > > http://www.amazon.com/Reference-Manual-Definitive-Guides-Window/dp/1565920066/ref=pd_sim_b_title_1 O'Reilly has made the Xlib Reference Manual, and several other books from that series, available online for free - unfortunately, not yet the Programming Manual. I've put links to them in the wiki at: http://wiki.x.org/wiki/ProgrammingDocumentation and http://wiki.x.org/wiki/UserDocumentation -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From florian.harmuth at googlemail.com Mon Dec 10 10:44:52 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Mon, 10 Dec 2007 19:44:52 +0100 Subject: Using XVideo extension? In-Reply-To: <475D6619.8030106@hummingbird.com> References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> <475D6619.8030106@hummingbird.com> Message-ID: 2007/12/10, Peter Harris : > > Florian Harmuth wrote: > > Sorry that i have to reask again -> actually i get my image informations > > as XImage struct. Is it possible to convert/cast this information to the > > XRenders Picture format? > > In order to implement your StretchImage(), the process would look > something like: > > XRenderCreatePicture(window) > > XCreatePixmap() > XRenderCreatePicture(pixmap) > # If the input size is constant, the above only need to be done once > > XRenderSetPictureTransform(pixmap_picture) > # The above line is only needed when the amount of stretch changes > > XPutImage(pixmap) # XImage struct used here > XRenderCompositeImage(pixmap_picture, null_mask, window_picture) > > # Free pictures and pixmap here, unless cached > > Setting a non-default filter to smooth out the scaling is left as an > exercise for the reader. > > Peter Harris > > -- > Hummingbird Connectivity - A Division of Open Text > Peter Harris http://connectivity.hummingbird.com > Research and Development Phone: +1 905 762 6001 > peter.harris at hummingbird.com Toll Free: 1 877 359 4866 > Thanks a lot! Best regards from Germany flo -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at bitplanet.net Mon Dec 10 11:01:16 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 10 Dec 2007 14:01:16 -0500 Subject: [PATCH] add EXA relocation function In-Reply-To: <1197278318.15055.128.camel@thor.sulgenrain.local> References: <200712071333.56545.jbarnes@virtuousgeek.org> <1197278318.15055.128.camel@thor.sulgenrain.local> Message-ID: <59ad55d30712101101r6dcfc022q57ab85943b8c01@mail.gmail.com> On Dec 10, 2007 4:18 AM, Michel D?nzer wrote: > > On Fri, 2007-12-07 at 13:33 -0800, Jesse Barnes wrote: > > > In order to avoid having a fixed offset for the EXA offscreen area (which is > > nice if the driver is using TTM) drivers need to update the base offset of > > EXA memory in EnterVT, and may need to update any private pointers they've > > allocated as well (e.g. for the cursor or scanout buffers, etc.). > > > > Since the server already kicks out all the pixmaps at VT switch time, the > > relocation is trivial and will typically just involve the one, big free area > > and any locked driver allocations; this function reflects that. > > > > One possible enhancement would be to call back into a driver provided function > > to update the private allocations, but it wouldn't really save any code... > > > > Any thoughts on this? > > I'm not sure it's really worth it, compared to using the existing > CreatePixmap hook for allocating pixmaps from a generic memory manager > such as TTM in the first place. Is there anything the latter can't do > that the former can? I'm curious too, I thought we were going to use one BO per pixmap. Redirected direct rendering and texturing from pixmap both requires a BO per pixmap to work. cheers, Kristian From linuxhippy at gmail.com Mon Dec 10 11:20:42 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 10 Dec 2007 20:20:42 +0100 Subject: Looking for XRender examples In-Reply-To: <200712091346.47393.hcb@chaoticmind.net> References: <87tzmvels6.wl%cworth@cworth.org> <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> <200712091346.47393.hcb@chaoticmind.net> Message-ID: <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> Hello Helge, Thanks a lot for uploading the documentation, also for the not directly XRender related presentations. It really made it much easier to start with :) Just because I am curious: Is that teaching material used in a couse, and if yes, how is it called? One of the things which quite confuse me is how the problem of antialiased polygons is solved, if the are composed of several trapezoids ... however I've to look at cairo's source ^^ Thanks a lot, lg Clemens From airlied at gmail.com Mon Dec 10 11:56:09 2007 From: airlied at gmail.com (Dave Airlie) Date: Tue, 11 Dec 2007 05:56:09 +1000 Subject: [PATCH] add EXA relocation function In-Reply-To: <59ad55d30712101101r6dcfc022q57ab85943b8c01@mail.gmail.com> References: <200712071333.56545.jbarnes@virtuousgeek.org> <1197278318.15055.128.camel@thor.sulgenrain.local> <59ad55d30712101101r6dcfc022q57ab85943b8c01@mail.gmail.com> Message-ID: <21d7e9970712101156g1186fdb1x1b574ec484c56fd4@mail.gmail.com> > > > > > > One possible enhancement would be to call back into a driver provided function > > > to update the private allocations, but it wouldn't really save any code... > > > > > > Any thoughts on this? > > > > I'm not sure it's really worth it, compared to using the existing > > CreatePixmap hook for allocating pixmaps from a generic memory manager > > such as TTM in the first place. Is there anything the latter can't do > > that the former can? > > I'm curious too, I thought we were going to use one BO per pixmap. > Redirected direct rendering and texturing from pixmap both requires a > BO per pixmap to work. > Except maybe for glyphs, which really would need a single pixmap cache, with some pipelined upload for new glyphs.. Dave. From jbarnes at virtuousgeek.org Mon Dec 10 12:01:24 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 10 Dec 2007 12:01:24 -0800 Subject: [PATCH] add EXA relocation function In-Reply-To: <59ad55d30712101101r6dcfc022q57ab85943b8c01@mail.gmail.com> References: <200712071333.56545.jbarnes@virtuousgeek.org> <1197278318.15055.128.camel@thor.sulgenrain.local> <59ad55d30712101101r6dcfc022q57ab85943b8c01@mail.gmail.com> Message-ID: <200712101201.26217.jbarnes@virtuousgeek.org> On Monday, December 10, 2007 11:01 Kristian H?gsberg wrote: > On Dec 10, 2007 4:18 AM, Michel D?nzer wrote: > > On Fri, 2007-12-07 at 13:33 -0800, Jesse Barnes wrote: > > > In order to avoid having a fixed offset for the EXA offscreen > > > area (which is nice if the driver is using TTM) drivers need to > > > update the base offset of EXA memory in EnterVT, and may need to > > > update any private pointers they've allocated as well (e.g. for > > > the cursor or scanout buffers, etc.). > > > > > > Since the server already kicks out all the pixmaps at VT switch > > > time, the relocation is trivial and will typically just involve > > > the one, big free area and any locked driver allocations; this > > > function reflects that. > > > > > > One possible enhancement would be to call back into a driver > > > provided function to update the private allocations, but it > > > wouldn't really save any code... > > > > > > Any thoughts on this? > > > > I'm not sure it's really worth it, compared to using the existing > > CreatePixmap hook for allocating pixmaps from a generic memory > > manager such as TTM in the first place. Is there anything the > > latter can't do that the former can? > > I'm curious too, I thought we were going to use one BO per pixmap. > Redirected direct rendering and texturing from pixmap both requires a > BO per pixmap to work. Initially I was thinking there'd be a compatibility motivation for this (i.e. new driver on old kernel) but I don't think that's really a concern, so yeah it's probably not worth it. Jesse From cworth at cworth.org Mon Dec 10 12:37:59 2007 From: cworth at cworth.org (Carl Worth) Date: Mon, 10 Dec 2007 12:37:59 -0800 Subject: Looking for XRender examples In-Reply-To: <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> References: <87tzmvels6.wl%cworth@cworth.org> <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> <200712091346.47393.hcb@chaoticmind.net> <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> Message-ID: <878x42e15k.wl%cworth@cworth.org> On Mon, 10 Dec 2007 20:20:42 +0100, "Clemens Eisserer" wrote: > One of the things which quite confuse me is how the problem of > antialiased polygons is solved, if the are composed of several > trapezoids ... however I've to look at cairo's source ^^ I'm not sure what your question is, but I'd be glad to help answer it if that would be easier than browsing through cairo's source code. Cairo does tessellate complex polygons into a set of trapezoids for XRender to rasterize and composite. And Render does guarantee that the antialiased rasterization of trapezoids with shared edges will combine to exactly 1 so that there are no visible internal seams. Is there something else that you have a question about? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From linuxhippy at gmail.com Mon Dec 10 13:35:02 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 10 Dec 2007 22:35:02 +0100 Subject: Looking for XRender examples In-Reply-To: <878x42e15k.wl%cworth@cworth.org> References: <87tzmvels6.wl%cworth@cworth.org> <194f62550712061206s4d67040n65f296f9aa83989a@mail.gmail.com> <200712091346.47393.hcb@chaoticmind.net> <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> <878x42e15k.wl%cworth@cworth.org> Message-ID: <194f62550712101335k4bd551e0uef96a94315ffc967@mail.gmail.com> Hello Carl, > I'm not sure what your question is, but I'd be glad to help answer it > if that would be easier than browsing through cairo's source code. > Is there something else that you have a question about? For now not, but I fear I run into many problems when I actually start coding ;) > Cairo does tessellate complex polygons into a set of trapezoids for > XRender to rasterize and composite. And Render does guarantee that the > antialiased rasterization of trapezoids with shared edges will combine > to exactly 1 so that there are no visible internal seams. Oh, I thought there was some hidden magic with masks I should render to, glad that it can be solved this way too. Thanks a lot for helping, lg Clemens From jbarnes at virtuousgeek.org Mon Dec 10 17:38:19 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 10 Dec 2007 17:38:19 -0800 Subject: Output problems with 945GM In-Reply-To: <4759752C.9000205@kaasa.com> References: <4757FF1F.4060500@kaasa.com> <200712061041.27890.jbarnes@virtuousgeek.org> <4759752C.9000205@kaasa.com> Message-ID: <200712101738.19906.jbarnes@virtuousgeek.org> On Friday, December 07, 2007 8:30 am Matteo Brusa wrote: > Hi Jesse, thanks for the answer. > See my inline comments. > > Jesse Barnes wrote: > > On Thursday, December 06, 2007 5:54 am Matteo Brusa wrote: > >> Hi, > >> i have some HDTV configuration issues with my 945GM based pc, i hope i'm > >> in the right place to ask. I'm running Ubuntu 7.10 and therefore the > >> intel driver version 2:2.1.1-0ubuntu9. > >> > >> VGA output > >> The VGA output works great, it uses the 1360x768 resolution when plugged > >> to an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying > >> to get either HDMI (with DVI adapter cable) or component running. > >> LDVS > >> In X, LVDS is always enabled although i have no LCD screen. I tried > >> "xrandr --ouput LDVS --off" without success, and the intel module does > >> not support any xorg.conf option to shut it off. Could this be the > >> reason why xvidtune always shows 1024x768 and not the actual screen > >> value? Component I always get 1024x768, no matter which Modeline i > >> specify. Any suggestion? > > > > You actually can disable it: > > > > Section "Monitor" > > Identifier "Bogus LCD" > > Option "ignore" "true" > > EndSection > > > > Section "Driver" > > Identifier "Card0" > > Driver "intel" > > VendorName "Intel Corporation" > > BoardName "Unknown Board" > > Option "Monitor-LVDS" "Bogus LCD" > > EndSection > > > > And since we've been getting so many reports about this stuff and always > > end up pointing people at > > http://www.intellinuxgraphics.org/dualhead.html, I think I'll update the > > man page with some more detail... > > Great, this works. > That would be really helpful to have this mentioned in the man page. I added some more detail to the git tree, hopefully it'll help head off future FAQs. :) > >> TDMS-1 > >> I got 1280x768 working, with noticeable overscan. How can i use the same > >> 1360x768 with DVI, or get rid of the overscan? > > > > What's the output of 'xrandr'? > > Here's the snippet relative to this output: > TMDS-1 connected 1280x720+0+0 (0x62) normal (normal left inverted right) > 160mm x 90mm Identifier: 0x4e > Timestamp: -1361725529 > Subpixel: horizontal rgb > Clones: > CRTC: 0 > CRTCs: 0 1 > EDID_DATA: > 00ffffffffffff004c2d000200000000 > 2a0f01038010098c0ae2bda15b4a9824 > 15474a20000001010101010101010101 > 010101010101011d007251d01e206e28 > 5500a05a0000001e011d00bc52d01e20 > b8285540a05a0000001e000000fd0032 > 3d0f2e08000a202020202020000000fc > 0053414d53554e470a202020202001af > 1280x720 (0x62) 74.2MHz +HSync +VSync > h: width 1280 start 1390 end 1430 total 1650 skew 0 clock > 45.0KHz v: height 720 start 725 end 730 total 750 clock > 60.0Hz 1280x720 (0x63) 74.2MHz +HSync +VSync > h: width 1280 start 1720 end 1760 total 1980 skew 0 clock > 37.5KHz v: height 720 start 725 end 730 total 750 clock > 50.0Hz 640x480 (0x64) 25.2MHz -HSync -VSync > h: width 640 start 656 end 752 total 800 skew 0 clock > 31.5KHz v: height 480 start 490 end 492 total 525 clock > 60.0Hz Hm, I think using DVI is your best bet (it'll probably give you the best picture quality) but your TV doesn't seem to provide a 1360x768 resolution in its EDID data? Or are you overriding it somehow? Can you post your xorg.conf and Xorg.0.log files? Thanks, Jesse From pekane52 at gmail.com Mon Dec 10 20:56:32 2007 From: pekane52 at gmail.com (Pat Kane) Date: Mon, 10 Dec 2007 22:56:32 -0600 Subject: Unable to create a redirected window with a rgba-colormap In-Reply-To: <475D6EB0.8000002@sun.com> References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> <475A9CC5.2080107@netspace.net.au> <475D6EB0.8000002@sun.com> Message-ID: Alan, Thank you for those doc links. One of my favorite X books is: The X Window System Server X Version 11, Release 5 By: Elias Israel and Erik Fortune 1992 Digital Press, ISBN 1-55558-069-3 Is that available on the Web? Pat --- On Dec 10, 2007 10:52 AM, Alan Coopersmith wrote: > O'Reilly has made the Xlib Reference Manual, and several other books from > that series, available online for free - unfortunately, not yet the > Programming Manual. I've put links to them in the wiki at: > http://wiki.x.org/wiki/ProgrammingDocumentation > and > http://wiki.x.org/wiki/UserDocumentation > > -- > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith at Sun.COM Mon Dec 10 21:07:59 2007 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Mon, 10 Dec 2007 21:07:59 -0800 Subject: X books online (was: Unable to create a redirected window with a rgba-colormap) In-Reply-To: References: <1197097145.7222.26.camel@HAL9000> <1197119049.7222.77.camel@HAL9000> <475A9CC5.2080107@netspace.net.au> <475D6EB0.8000002@sun.com> Message-ID: <475E1B2F.5080504@sun.com> I would love to know if it was, but I've never seen it. I would be even happier if it was open sourced so we could update it for X11R7. I'm not aware of Digital Press having any program similar to O'Reilly's, but the three Digital Press X books I had other than the X server book seem to just be printed copies of the standard specs from X.Org and not containing any original material. (Unfortunately, my copies were borrowed and not returned, so I can't easily verify that.) -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Pat Kane wrote: > Alan, > > Thank you for those doc links. > > One of my favorite X books is: > > The X Window System Server > X Version 11, Release 5 > By: Elias Israel and Erik Fortune > 1992 Digital Press, > ISBN 1-55558-069-3 > > Is that available on the Web? > > Pat > --- > > On Dec 10, 2007 10:52 AM, Alan Coopersmith wrote: >> O'Reilly has made the Xlib Reference Manual, and several other books from >> that series, available online for free - unfortunately, not yet the >> Programming Manual. I've put links to them in the wiki at: >> http://wiki.x.org/wiki/ProgrammingDocumentation >> and >> http://wiki.x.org/wiki/UserDocumentation >> >> -- >> -Alan Coopersmith- alan.coopersmith at sun.com >> Sun Microsystems, Inc. - X Window System Engineering From joeprogrammer70 at gmail.com Mon Dec 10 21:18:51 2007 From: joeprogrammer70 at gmail.com (Joseph Alten) Date: Mon, 10 Dec 2007 21:18:51 -0800 Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem Message-ID: <9B3A8C91-4D9A-4CD7-99F0-B37074B877FE@gmail.com> Hello. I've installed Linux on my MacBook, and I'm having some issues getting Xorg (version 7.2 I think) to display correctly on my Dell 2407WFP monitor. Here are the technical specs of the monitor: Horizontal Scan Frequency kHz 30 kHz to 81 kHz (automatic) Vertical Scan Frequency Frequency kHz 56 Hz to 76 Hz (automatic) ), exception 1920 x 1200 at 60 Hz only Optimal Resolution 1920 x 1200 at 60 Hz Preset Display Modes * VESA, 720 x 400 - 31.5 kHz Horizontal, 70.0 Hz Vertical, 28.3 MHz * VESA, 640 x 480 - 31.5 kHz Horizontal, 59.9 Hz Vertical, 25.2 MHz * VESA, 640 x 480 - 37.5 kHz Horizontal, 75.0 Hz Vertical, 31.5 MHz * VESA, 800 x 600 - 37.9 kHz Horizontal, 60.3 Hz Vertical, 40.0 MHz * VESA, 800 x 600 - 46.9 kHz Horizontal, 75.0 Hz Vertical, 49.5 MHz * VESA, 1024 x 768 - 48.4 kHz Horizontal, 60.0 Hz Vertical, 65.0 MHz * VESA, 1024 x 768 - 60.0 kHz Horizontal, 75.0 Hz Vertical, 78.8 MHz * VESA, 1152 x 864 - 67.5 kHz Horizontal, 75.0 Hz Vertical, 108 MHz * VESA, 1280 x 1024 - 64.0 kHz Horizontal, 60.0 Hz Vertical, 108 MHz * VESA, 1280 x 1024 - 80.0 kHz Horizontal, 75.0 Hz Vertical, 135 MHz * VESA, 1600 x 1200 - 75.0 kHz Horizontal, 60.0 Hz Vertical, 162 MHz * VESA, 1920 x 1200 - 74.0 kHz Horizontal, 60.0 Hz Vertical, 154 MHz And here's what xrandr shows when the monitor is plugged in: TMDS-1 connected 1152x864+0+0 (normal left inverted right) 0mm x 0mm 1920x1200 60.0 + 1600x1200 59.9 1680x1050 60.0 1280x1024 75.0 59.9 1152x864 74.8* 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 59.9 720x400 70.1 Using xrandr, I can set the display resolution of the monitor from pretty much anywhere around 720x400 to 1680x1050. But I can't get any higher than that; when I try to set it to either 1600x1200 or 1920x1200 my monitor goes blank, and then I get a message that reads the following: "Out of range signal. Cannot display this video mode, change computer display input to 1920x1200 @ 60Hz" I've tried using the cvt tool to generate a reduced-blanking modeline and then using it with xrandr, but it doesn't help. I've also tried using Colas XFree Modeline Generator, but when I enter the range values according to the technical specifications of the monitor, the generator says that my resolution is too low. By the way, there is nothing wrong with my hardware, as Windows and Mac OS X currently exist on my hard drive as part of a triple-boot setup, and they have no issues whatsoever with using this monitor at its native resolution. Another thing worth noting is that I'm connecting to this thing via DVI; I had another machine that I tried connecting to this thing using VGA, and all I did was set the resolution in the xorg.conf file and it worked perfectly... Thanks in advance, Joe From hcb at chaoticmind.net Mon Dec 10 22:28:39 2007 From: hcb at chaoticmind.net (Helge Bahmann) Date: Tue, 11 Dec 2007 07:28:39 +0100 Subject: Looking for XRender examples In-Reply-To: <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> References: <87tzmvels6.wl%cworth@cworth.org> <200712091346.47393.hcb@chaoticmind.net> <194f62550712101120r77638301pd490c7a59961ba6@mail.gmail.com> Message-ID: <200712110728.39760.hcb@chaoticmind.net> Am Montag, 10. Dezember 2007 20:20 schrieb Clemens Eisserer: > Hello Helge, > > Thanks a lot for uploading the documentation, also for the not > directly XRender related presentations. It really made it much easier > to start with :) > > Just because I am curious: Is that teaching material used in a couse, > and if yes, how is it called? yes it is teaching material; it is the introduction into a multimedia course, specifically multimedia in the x window system (which is what my research project is about) > One of the things which quite confuse me is how the problem of > antialiased polygons is solved, if the are composed of several > trapezoids ... however I've to look at cairo's source ^^ well the basic idea usually is... slice your polygon vertically at every node point, then step through the segments top to bottom; it is easy to see that the resulting shapes will always be trapezoids or triangles if you manage to slice up your shape exactly at pixel boundaries, you can composite the segments directly to the target surface (because they do not overlap); otherwise you may need an intermediate mask (PictOpDisjointOver) Best regards -- Mathematicians stand on each other's shoulders while computer scientists stand on each other's toes. -- Richard Hamming From peppino_in_casa at hotmail.com Tue Dec 11 02:15:03 2007 From: peppino_in_casa at hotmail.com (Peppino Incasa) Date: Tue, 11 Dec 2007 10:15:03 +0000 Subject: Problem with different windows Message-ID: Hi, I have a problem with multiple X windows. I would realized a windows that draw the content of another window of different application (in this case this is a opengl window). I don't understand as I can retrive a opengl framebuffer for drawing this in new and different window, using GLX function. Thank you and sorry for my English. Peppino _________________________________________________________________ Passa a Windows Live Hotmail: per te GRATIS 5 GB di spazio! http://imagine-windowslive.com/hotmail/default.aspx?locale=it#0 From florian.harmuth at googlemail.com Tue Dec 11 05:20:09 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Tue, 11 Dec 2007 14:20:09 +0100 Subject: Using XVideo extension? In-Reply-To: References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> <475D6619.8030106@hummingbird.com> Message-ID: Hello again, i hope that this will be my last post ;-). How can i connect the data of pixmap and my XImage struct? I should use the data of my XImage struct instead of the pixmap in the XRenderCreatePicture(pixmap) call. Right? -> regards, flo 2007/12/10, Peter Harris : > > > > XRenderCreatePicture(window) > > XCreatePixmap() > XRenderCreatePicture(pixmap) > # If the input size is constant, the above only need to be done once > > XRenderSetPictureTransform(pixmap_picture) > # The above line is only needed when the amount of stretch changes > > XPutImage(pixmap) # XImage struct used here > XRenderCompositeImage(pixmap_picture, null_mask, window_picture) > > # Free pictures and pixmap here, unless cached > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at schildbach.de Tue Dec 11 06:50:27 2007 From: andreas at schildbach.de (Andreas Schildbach) Date: Tue, 11 Dec 2007 15:50:27 +0100 Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem In-Reply-To: <9B3A8C91-4D9A-4CD7-99F0-B37074B877FE@gmail.com> References: <9B3A8C91-4D9A-4CD7-99F0-B37074B877FE@gmail.com> Message-ID: Joseph Alten wrote: > Using xrandr, I can set the display resolution of the monitor from > pretty much anywhere around 720x400 to 1680x1050. But I can't get any > higher than that; when I try to set it to either 1600x1200 or > 1920x1200 my monitor goes blank, and then I get a message that reads > the following: > > "Out of range signal. > Cannot display this video mode, > change computer display input to 1920x1200 @ 60Hz" Sounds like you are using the -i810 driver, with which it is next to impossible to exactly get the signal the 2407FPW needs (I tried with the 2405 though). You should use the -intel driver, if possible. Regards, Andreas From peter.harris at hummingbird.com Tue Dec 11 07:40:32 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 11 Dec 2007 10:40:32 -0500 Subject: Using XVideo extension? In-Reply-To: References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> <475D6619.8030106@hummingbird.com> Message-ID: <475EAF70.8080803@hummingbird.com> Florian Harmuth wrote: > Hello again, > i hope that this will be my last post ;-). How can i connect the data of > pixmap and my XImage struct? > 2007/12/10, Peter Harris < peter.harris at hummingbird.com > >: > >> XPutImage(pixmap) # XImage struct used here -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From kristof.ralovich at gmail.com Tue Dec 11 08:49:52 2007 From: kristof.ralovich at gmail.com (=?UTF-8?Q?Ralovich_Krist=C3=B3f?=) Date: Tue, 11 Dec 2007 17:49:52 +0100 Subject: savage inproper init Message-ID: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> Hi, I would like to report about hard lockups (ping and ssh stops too) caused by the savage driver. I am getting the same results no matter if I use the savage fbdev or not. Neither EXA / XAA changes the situation. Additionally if I use EXA, it garbles the bitmaps and the X screen around the cursor. The machine is an IBM T22. I can not find any further details in the system logs or X log. The symptom is if boot up, X wont run, it hangs before switching to the desired resolution. But if I run windows first then reboot and start linux, everything is going fine. GL and Xv works too. The other way avoiding the lockup2 was putting the AGPMode "2" line to the Device section, it was a little bit slower, but it was stable at least. Details: Linux t22 2.6.23.8 #1 PREEMPT Tue Dec 11 14:23:29 CET 2007 i686 GNU/Linux 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13) ii xserver-xorg-core 1.3.0.0.dfsg-12lenny1 X.Org X server -- core server ... ii xserver-xorg-video-savage 2.1.3-1 X.Org X server -- Savage display driver Thanks in advance, Kristof PS1.: I had the same experience with X 1.1.1 and savage 2.1.2 PS2: For me this case seems to be similar the one with radeon cards a while ago: someone had to use the proprietary driver first, so it initializes all the registers, and later you could switch back to using the r200 driver since the card was initialized correctly. From alexdeucher at gmail.com Tue Dec 11 09:04:20 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 11 Dec 2007 12:04:20 -0500 Subject: savage inproper init In-Reply-To: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> References: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> Message-ID: On Dec 11, 2007 11:49 AM, Ralovich Krist?f wrote: > Hi, > > I would like to report about hard lockups (ping and ssh stops too) > caused by the savage driver. I am getting the same results no matter > if I use the savage fbdev or not. Neither EXA / XAA changes the > situation. Additionally if I use EXA, it garbles the bitmaps and the X > screen around the cursor. The machine is an IBM T22. I can not find > any further details in the system logs or X log. > > The symptom is if boot up, X wont run, it hangs before switching to > the desired resolution. But if I run windows first then reboot and > start linux, everything is going fine. GL and Xv works too. > > The other way avoiding the lockup2 was putting the AGPMode "2" line to > the Device section, it was a little bit slower, but it was stable at > least. Savage IX/MX cards are only AGP 2x cards. Some savage agp 2x cards do not like 1x mode (the driver default). I never had a chance to figure out which cards this affected as it was hit or miss. We should probably just default to whatever AGP mode the bios sets up. Alex From daniel at fooishbar.org Tue Dec 11 09:17:13 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Tue, 11 Dec 2007 19:17:13 +0200 Subject: [Members] X.Org Foundation Board Nominations Reopened In-Reply-To: <1197391483.5667.404.camel@pont> References: <200712040806.lB486UN5028313@wezen.cs.pdx.edu> <1197391483.5667.404.camel@pont> Message-ID: <20071211171713.GD11399@fooishbar.org> On Tue, Dec 11, 2007 at 11:44:42AM -0500, Matthew Rubenstein wrote: > I note that I have not seen any communications with the members since > the last election. I will therefore prioritize communications with the > members as a campaign issue in this election. I recommend everyone else > do the same. Is there any good reason why members are not on xorg@? > Please advise when a legitimate election will take place. Helpful. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bart at cs.pdx.edu Tue Dec 11 09:40:58 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Tue, 11 Dec 2007 09:40:58 -0800 Subject: [Members] X.Org Foundation Board Nominations Reopened In-Reply-To: Your message of "Tue, 11 Dec 2007 11:44:42 EST." <1197391483.5667.404.camel@pont> References: <1197391483.5667.404.camel@pont> <200712040806.lB486UN5028313@wezen.cs.pdx.edu> Message-ID: <200712111740.lBBHew07003608@murzim.cs.pdx.edu> In message <1197391483.5667.404.camel at pont> you wrote: > I just received this morning your reopening message quoted appended > below. The SMTP headers (also appended below) show that expo.x.org > bounced it around internally from 4 Dec 2007 to 11 Dec 2007. That means > the announcement wasn't received by the members on the list until 2 days > after the voting deadline: Understood. My apologies. > The SMTP headers on Paul Schenker's message, sent 2 Dec > 2007 / received 11 Dec 2007 (received at the same time as > Barton Massey's message sent 4 Dec 2007), show it was also > caught in the same trap. > > The extended period was therefore consumed by your > mail server's week+ of delay sending the announcement. The > extended deadline therefore is as useless as the original. Indeed. > Didn't you notice that no one responded to your > extension message, even though several of us commented > that an extension was necessary? Why didn't you email at > least one of us to see why we would make such an empty > demand? Several people did respond to my extension message, since it was also posted to the general xorg list, which was working fine throughout the period, and to a number of individuals. I assumed that those who did not respond were simply happy with the outcome. I was mistaken. > I note that I have not seen any communications with the members since > the last election. I will therefore prioritize communications with the > members as a campaign issue in this election. I recommend everyone else > do the same. In particular, since you feel strongly on this issue, please feel free to nominate yourself to the X.Org Foundation Board election, so that you can work to help make the Board's communication with the membership better in the most direct possible way. > Please advise when a legitimate election will take place. We plan to spend today figuring out what to do, and make a second revised announcement of the election schedule tomorrow. As I said earlier, I am truly sorry for the communication issues. All the work the Board and its Election Committee has done has been in public as much as possible, and with the interests of the organization and its members at heart. I truly regret the procedural and technical mistakes that have led to this situation. Beyond apologizing, there's not much I and the committee can do except try to make the situation right. We will do that as best we can. Sincerely, Bart Massey Election Committee X.Org Foundation Board bart at cs.pdx.edu From kristof.ralovich at gmail.com Tue Dec 11 11:09:51 2007 From: kristof.ralovich at gmail.com (=?UTF-8?Q?Ralovich_Krist=C3=B3f?=) Date: Tue, 11 Dec 2007 20:09:51 +0100 Subject: savage inproper init In-Reply-To: References: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> Message-ID: <5712ce4f0712111109rd2e1ecfw1f4d1b81acf10c9a@mail.gmail.com> On Dec 11, 2007 6:04 PM, Alex Deucher wrote: > On Dec 11, 2007 11:49 AM, Ralovich Krist?f wrote: > > Hi, > > > > I would like to report about hard lockups (ping and ssh stops too) > > caused by the savage driver. I am getting the same results no matter > > if I use the savage fbdev or not. Neither EXA / XAA changes the > > situation. Additionally if I use EXA, it garbles the bitmaps and the X > > screen around the cursor. The machine is an IBM T22. I can not find > > any further details in the system logs or X log. > > > > The symptom is if boot up, X wont run, it hangs before switching to > > the desired resolution. But if I run windows first then reboot and > > start linux, everything is going fine. GL and Xv works too. > > > > The other way avoiding the lockup2 was putting the AGPMode "2" line to > > the Device section, it was a little bit slower, but it was stable at > > least. > > Savage IX/MX cards are only AGP 2x cards. Some savage agp 2x cards do > not like 1x mode (the driver default). I never had a chance to figure > out which cards this affected as it was hit or miss. We should > probably just default to whatever AGP mode the bios sets up. > > Alex > Alex, first of all, thanks for the fast reply. You were right, even win is using the card in agp 2x mode, so from now on I am using that too. With agp 2x the cold startup problem is vanished again. But now I have some messages in /var/log/kern.log. After X startup: Dec 11 18:26:55 t22 kernel: mtrr: base(0xf2000000) is not aligned on a size(0x5000000) boundary Dec 11 18:26:55 t22 last message repeated 2 times Dec 11 18:26:55 t22 kernel: agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0. Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode X is working properly, so is Xv! But if I start glxgears, there is a reproducible lockup again: Dec 11 18:28:01 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! OR Dec 11 19:27:15 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! Dec 11 19:27:15 t22 kernel: [drm] status=0x00009631, e=0x9633 Dec 11 19:27:28 t22 kernel: [drm:savage_bci_wait_fifo_shadow] *ERROR* failed! Dec 11 19:27:28 t22 kernel: [drm] status=0x003c7620, threshold=0x00007620 with the above lines in kern.log. I am still able to restart the machine using keys, so the kernel keeps running. Putting ShadowStatus "off" into xorg.conf wont solve the problem, but the kernel message is different: Dec 11 19:36:53 t22 kernel: [drm:savage_bci_wait_event_reg] *ERROR* failed! Dec 11 19:36:53 t22 kernel: [drm] status=0x00000002, e=0x0004 and causing a hard lockup again! With BCIforXv "off" the result is always soft lockup: Dec 11 20:02:27 t22 kernel: [drm:savage_bci_wait_event_reg] *ERROR* failed! Dec 11 20:02:27 t22 kernel: [drm] status=0x00000003, e=0x0005 Can you please give any hints, do you think it is possible make GL and Xv both work reliably? If I am able to, I would like to help to trace down this matter. What should I do to provide some more info? Keep in touch, Kristof From alexdeucher at gmail.com Tue Dec 11 11:20:12 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 11 Dec 2007 14:20:12 -0500 Subject: savage inproper init In-Reply-To: <5712ce4f0712111109rd2e1ecfw1f4d1b81acf10c9a@mail.gmail.com> References: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> <5712ce4f0712111109rd2e1ecfw1f4d1b81acf10c9a@mail.gmail.com> Message-ID: On Dec 11, 2007 2:09 PM, Ralovich Krist?f wrote: > On Dec 11, 2007 6:04 PM, Alex Deucher wrote: > > On Dec 11, 2007 11:49 AM, Ralovich Krist?f wrote: > > > Hi, > > > > > > I would like to report about hard lockups (ping and ssh stops too) > > > caused by the savage driver. I am getting the same results no matter > > > if I use the savage fbdev or not. Neither EXA / XAA changes the > > > situation. Additionally if I use EXA, it garbles the bitmaps and the X > > > screen around the cursor. The machine is an IBM T22. I can not find > > > any further details in the system logs or X log. > > > > > > The symptom is if boot up, X wont run, it hangs before switching to > > > the desired resolution. But if I run windows first then reboot and > > > start linux, everything is going fine. GL and Xv works too. > > > > > > The other way avoiding the lockup2 was putting the AGPMode "2" line to > > > the Device section, it was a little bit slower, but it was stable at > > > least. > > > > Savage IX/MX cards are only AGP 2x cards. Some savage agp 2x cards do > > not like 1x mode (the driver default). I never had a chance to figure > > out which cards this affected as it was hit or miss. We should > > probably just default to whatever AGP mode the bios sets up. > > > > Alex > > > > Alex, > > first of all, thanks for the fast reply. You were right, even win is > using the card in agp 2x mode, so from now on I am using that too. > With agp 2x the cold startup problem is vanished again. But now I have > some messages in /var/log/kern.log. After X startup: > > Dec 11 18:26:55 t22 kernel: mtrr: base(0xf2000000) is not aligned on a > size(0x5000000) boundary > Dec 11 18:26:55 t22 last message repeated 2 times > Dec 11 18:26:55 t22 kernel: agpgart: Found an AGP 1.0 compliant device > at 0000:00:00.0. > Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at > 0000:00:00.0 into 2x mode > Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at > 0000:01:00.0 into 2x mode > > X is working properly, so is Xv! But if I start glxgears, there is a > reproducible lockup again: > > Dec 11 18:28:01 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! > > OR > > Dec 11 19:27:15 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! > Dec 11 19:27:15 t22 kernel: [drm] status=0x00009631, e=0x9633 > Dec 11 19:27:28 t22 kernel: [drm:savage_bci_wait_fifo_shadow] *ERROR* failed! > Dec 11 19:27:28 t22 kernel: [drm] status=0x003c7620, threshold=0x00007620 > > with the above lines in kern.log. I am still able to restart the > machine using keys, so the kernel keeps running. > > Putting ShadowStatus "off" into xorg.conf wont solve the problem, but > the kernel message is different: > > Dec 11 19:36:53 t22 kernel: [drm:savage_bci_wait_event_reg] *ERROR* failed! > Dec 11 19:36:53 t22 kernel: [drm] status=0x00000002, e=0x0004 > > and causing a hard lockup again! IIRC, you need one or more of the following options: Option "DmaMode" "None" Option "BusType" "PCI" see the savage man page for more info. > > With BCIforXv "off" the result is always soft lockup: BCIforXv has no affect on old savage cards like the MX/IX. It only affects savage4 and IGP cards. Alex From jgrosshart at gmail.com Tue Dec 11 13:32:29 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Tue, 11 Dec 2007 16:32:29 -0500 Subject: Updating the wiki and other issues Message-ID: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> Greets all. I'm interested in whipping this page into shape. http://wiki.x.org/wiki/Releases/ModuleVersions It hasn't been updated for 7.3 and if you compare what IS listed there, it doesn't jive with what tarballs can be found at: hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} For instance, xf86-video-wsfb... What's up with this guy? It's listed as a part of 7.2 on the wiki but is no where to be found in http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . It's not even in everything/. So either someone forgot to upload it to the driver/ directory or the wiki is wrong. It is in individual/ but that doesn't do anyone any good. I'm seeing MANY discrepancies like this and want to fix them. I have no control over mistakes on the download server but can fix the wiki. So.. this leads me to ask, where is THE definitive source for determining what modules are supposed to be included with what release versions? Thus far, with the switch to modular X, I've been solely relying on proper tarball documentation and uploading to hxxp://xorg.freedesktop.org/releases/$VERSION/src/ which doesn't appear to be happening 100% of the time. On a related note, I'm not sure what's up with xf86-video-i810 in 7.3... If it was dropped or possibly even merged with xf86-video-intel, then why isn't it listed in http://xorg.freedesktop.org/releases/X11R7.3/src/deprecated/ ? I haven't enough time to subscribe to the mailing list and keep up on every aspect of Xorg development in order to know what is going on with every module in every release. That would be insane IMO. Excuse me if I'm overlooking the obvious on how to determine module versions that are supposed to be matched with release versions. Someone previously told me on this list it wasn't exactly rocket science, but I beg to differ. The apparent discrepancies on the freedesktop server are frustrating to say the least. Months ago, I found a driver module listed in another directory entirely; lib maybe (which I posted about here and the module was eventually removed). If checking the release directories is indeed the proper way to go about getting the correct source for an Xorg build (I don't use git at all), then we really need some consistency in that regard as far as organization and documentation on the official release download server. Once that happens, updating the wiki should be relatively painless and will provide an accurate list of what is included with each release version. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at floor51.com Tue Dec 11 13:18:50 2007 From: chris at floor51.com (Chris Newman) Date: Tue, 11 Dec 2007 21:18:50 +0000 Subject: Xserver starts in some 16:9 resolution Message-ID: <475EFEBA.3070707@floor51.com> Hi, I've upgraded xorg to xorg-server 2:1.4.1~git20071119-1 from the debian package and had a similar problem to thread 24968 ( http://lists.freedesktop.org/pipermail/xorg/2007-May/024968.html ) where the server selects 1280x768 despite the ServerLayout specifying a Screen with other configurations and the -layout option specified on the command line. I found that the previous xorg server was accepting slightly inaccurate HorizSync and VerticalSync settings whereas the newer one requires accurate settings. It's using the Intel i810 driver. chris From egore at gmx.de Tue Dec 11 13:41:14 2007 From: egore at gmx.de (Christoph Brill) Date: Tue, 11 Dec 2007 22:41:14 +0100 Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> Message-ID: <1197409274.6389.3.camel@egore912.egore.lan> Am Dienstag, den 11.12.2007, 16:32 -0500 schrieb Jon Grosshart: > Greets all. I'm interested in whipping this page into shape. > > http://wiki.x.org/wiki/Releases/ModuleVersions > > It hasn't been updated for 7.3 and if you compare what IS listed > there, it doesn't jive with what tarballs can be found at: > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > For instance, xf86-video-wsfb... What's up with this guy? It's listed > as a part of 7.2 on the wiki but is no where to be found in > http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . It's not > even in everything/. So either someone forgot to upload it to the > driver/ directory or the wiki is wrong. It is in individual/ but that > doesn't do anyone any good. I'm seeing MANY discrepancies like this > and want to fix them. I have no control over mistakes on the download > server but can fix the wiki. > > So.. this leads me to ask, where is THE definitive source for > determining what modules are supposed to be included with what release > versions? Thus far, with the switch to modular X, I've been solely > relying on proper tarball documentation and uploading to > hxxp://xorg.freedesktop.org/releases/$VERSION/src/ which doesn't > appear to be happening 100% of the time. > > On a related note, I'm not sure what's up with xf86-video-i810 in > 7.3... If it was dropped or possibly even merged with > xf86-video-intel, then why isn't it listed in > http://xorg.freedesktop.org/releases/X11R7.3/src/deprecated/ ? > > I haven't enough time to subscribe to the mailing list and keep up on > every aspect of Xorg development in order to know what is going on > with every module in every release. That would be insane IMO. > > Excuse me if I'm overlooking the obvious on how to determine module > versions that are supposed to be matched with release versions. > Someone previously told me on this list it wasn't exactly rocket > science, but I beg to differ. The apparent discrepancies on the > freedesktop server are frustrating to say the least. Months ago, I > found a driver module listed in another directory entirely; lib maybe > (which I posted about here and the module was eventually removed). > > If checking the release directories is indeed the proper way to go > about getting the correct source for an Xorg build (I don't use git at > all), then we really need some consistency in that regard as far as > organization and documentation on the official release download > server. Once that happens, updating the wiki should be relatively > painless and will provide an accurate list of what is included with > each release version. > > Jon Wouldn't it make sense to autogenerate this page? One could write a simple PHP/Perl/Python/SH/whatever script to generate this page on the fly or at release time. This way noone would have to keep this page up to date (which IMO is just a huge amout of useless work since most packages just jump into http://xorg.freedesktop.org/releases/ and grab all the exciting stuff from there). From dbn.lists at gmail.com Tue Dec 11 13:57:23 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 11 Dec 2007 13:57:23 -0800 Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> Message-ID: <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> On Dec 11, 2007 1:32 PM, Jon Grosshart wrote: > Greets all. I'm interested in whipping this page into shape. > > http://wiki.x.org/wiki/Releases/ModuleVersions > > It hasn't been updated for 7.3 and if you compare what IS listed there, it > doesn't jive with what tarballs can be found at: > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} Not addressing the possibly deprecated modules, you can find the 7.3 list here: http://wiki.x.org/wiki/Releases/7.3 I've been trying to keep the 7.4 list up to date, but it's about a month since I went through xorg-announce to update things: http://wiki.x.org/wiki/Releases/7.4 -- Dan From reed at reedmedia.net Tue Dec 11 14:03:50 2007 From: reed at reedmedia.net (reed at reedmedia.net) Date: Tue, 11 Dec 2007 16:03:50 -0600 (CST) Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> Message-ID: On Tue, 11 Dec 2007, Jon Grosshart wrote: > For instance, xf86-video-wsfb... What's up with this guy? It's listed as a > part of 7.2 on the wiki but is no where to be found in > http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . It's not even in > everything/. So either someone forgot to upload it to the driver/ directory > or the wiki is wrong. It is in individual/ but that doesn't do anyone any > good. I'm seeing MANY discrepancies like this and want to fix them. I have > no control over mistakes on the download server but can fix the wiki. I last made a release of it over a year ago. I don't think it had a release since. What is the procedure for getting it added to http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ ? I have seen other tarballs missing too and heard a few times that the end-user is supposed to hunt in previous download locations for them. I'd prefer to see everything available in one place (but maybe that is the plan now). From jgrosshart at gmail.com Tue Dec 11 14:05:50 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Tue, 11 Dec 2007 17:05:50 -0500 Subject: Updating the wiki and other issues In-Reply-To: <1197409274.6389.3.camel@egore912.egore.lan> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <1197409274.6389.3.camel@egore912.egore.lan> Message-ID: <9cf823c60712111405i659bac67sca07032af6b92337@mail.gmail.com> On Dec 11, 2007 4:41 PM, Christoph Brill wrote: > Am Dienstag, den 11.12.2007, 16:32 -0500 schrieb Jon Grosshart: > > Greets all. I'm interested in whipping this page into shape. > > > > http://wiki.x.org/wiki/Releases/ModuleVersions > > > > It hasn't been updated for 7.3 and if you compare what IS listed > > there, it doesn't jive with what tarballs can be found at: > > > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > > > For instance, xf86-video-wsfb... What's up with this guy? It's listed > > as a part of 7.2 on the wiki but is no where to be found in > > http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . It's not > > even in everything/. So either someone forgot to upload it to the > > driver/ directory or the wiki is wrong. It is in individual/ but that > > doesn't do anyone any good. I'm seeing MANY discrepancies like this > > and want to fix them. I have no control over mistakes on the download > > server but can fix the wiki. > > > > So.. this leads me to ask, where is THE definitive source for > > determining what modules are supposed to be included with what release > > versions? Thus far, with the switch to modular X, I've been solely > > relying on proper tarball documentation and uploading to > > hxxp://xorg.freedesktop.org/releases/$VERSION/src/ which doesn't > > appear to be happening 100% of the time. > > > > On a related note, I'm not sure what's up with xf86-video-i810 in > > 7.3... If it was dropped or possibly even merged with > > xf86-video-intel, then why isn't it listed in > > http://xorg.freedesktop.org/releases/X11R7.3/src/deprecated/ ? > > > > I haven't enough time to subscribe to the mailing list and keep up on > > every aspect of Xorg development in order to know what is going on > > with every module in every release. That would be insane IMO. > > > > Excuse me if I'm overlooking the obvious on how to determine module > > versions that are supposed to be matched with release versions. > > Someone previously told me on this list it wasn't exactly rocket > > science, but I beg to differ. The apparent discrepancies on the > > freedesktop server are frustrating to say the least. Months ago, I > > found a driver module listed in another directory entirely; lib maybe > > (which I posted about here and the module was eventually removed). > > > > If checking the release directories is indeed the proper way to go > > about getting the correct source for an Xorg build (I don't use git at > > all), then we really need some consistency in that regard as far as > > organization and documentation on the official release download > > server. Once that happens, updating the wiki should be relatively > > painless and will provide an accurate list of what is included with > > each release version. > > > > Jon > > Wouldn't it make sense to autogenerate this page? One could write a > simple PHP/Perl/Python/SH/whatever script to generate this page on the > fly or at release time. This way noone would have to keep this page up > to date (which IMO is just a huge amout of useless work since most > packages just jump into http://xorg.freedesktop.org/releases/ and grab > all the exciting stuff from there). > > It would, and that's exactly what I do on my own end, but without something to refer to, where do you pull your info from? Therin lies the problem. I have a script that auto generates a list of packages and their version numbers intended for whatever $VERSION I specify, but it keeps breaking at worst and is inaccurate at best due to the lack of organization on the download server (that's where I get my info from :-). Saying that the wiki page is useless is rubbish. Proper documentation is key to understanding what is going on. IMO, that's probably THE MOST IMPORTANT page on the wiki... :-) So again... If the wiki is wrong and/or individual developers 'forget' to upload their tarball to the server, where do you start? Who do you believe? I'm certainly not psychic and as I've stated, I don't have the time to know what's going on at all times with hundreds of packages... Ultimately, the wiki is unimportant, yes... I rely on what is listed on the release download server when I build and package Xorg. What I'm really pushing for is 100% accuracy with the releases/X11R7.?/src/ directories. Refer to xf86-video-i810 comment in my first post. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.coopersmith at sun.com Tue Dec 11 14:18:39 2007 From: alan.coopersmith at sun.com (Alan Coopersmith) Date: Tue, 11 Dec 2007 14:18:39 -0800 Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> Message-ID: <475F0CBF.2090100@sun.com> Jon Grosshart wrote: > Greets all. I'm interested in whipping this page into shape. > > http://wiki.x.org/wiki/Releases/ModuleVersions > > It hasn't been updated for 7.3 and if you compare what IS listed there, > it doesn't jive with what tarballs can be found at: > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} Sorry - I haven't had a chance to update it for 7.3 - I'd be happy if others did. I originally created it via a script going over the output of the tarballs in the website, I'm not sure how discrepancies crept in. > For instance, xf86-video-wsfb... What's up with this guy? It's listed as > a part of 7.2 on the wiki but is no where to be found in > http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . Since it doesn't build on Linux (it's a BSD/Solaris version of fbdev), it often gets overlooked by the release managers. > On a related note, I'm not sure what's up with xf86-video-i810 in 7.3... > If it was dropped or possibly even merged with xf86-video-intel, then > why isn't it listed in > http://xorg.freedesktop.org/releases/X11R7.3/src/deprecated/ ? It was simply renamed to -intel. -i810 is no more deprecated than -ati 6.5, it's just replaced by a newer version. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From jgrosshart at gmail.com Tue Dec 11 14:23:51 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Tue, 11 Dec 2007 17:23:51 -0500 Subject: Updating the wiki and other issues In-Reply-To: <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> Message-ID: <9cf823c60712111423i37c573acvc792057fa21554fb@mail.gmail.com> On Dec 11, 2007 4:57 PM, Dan Nicholson wrote: > On Dec 11, 2007 1:32 PM, Jon Grosshart wrote: > > Greets all. I'm interested in whipping this page into shape. > > > > http://wiki.x.org/wiki/Releases/ModuleVersions > > > > It hasn't been updated for 7.3 and if you compare what IS listed there, > it > > doesn't jive with what tarballs can be found at: > > > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > Not addressing the possibly deprecated modules, you can find the 7.3 list > here: > > http://wiki.x.org/wiki/Releases/7.3 > > I've been trying to keep the 7.4 list up to date, but it's about a > month since I went through xorg-announce to update things: > > http://wiki.x.org/wiki/Releases/7.4 > > -- > Dan The 7.3 link is what I've been referring to when I decided to make the jump to 7.3 yesterday. That and the download server of course. I was looking thru 'picklist' on my webserver and noticed that it now has some minor breakage with the release of 7.3... I don't know how you guys do it Dan. My ultimate goal with picklist was to come up with the blfs wget files consistently and accurately but it's just not happening at present. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbn.lists at gmail.com Tue Dec 11 14:41:08 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 11 Dec 2007 14:41:08 -0800 Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111423i37c573acvc792057fa21554fb@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> <9cf823c60712111423i37c573acvc792057fa21554fb@mail.gmail.com> Message-ID: <91705d080712111441o56cff2ccxeab022a2ca7bf5b3@mail.gmail.com> On Dec 11, 2007 2:23 PM, Jon Grosshart wrote: > > On Dec 11, 2007 4:57 PM, Dan Nicholson wrote: > > > > On Dec 11, 2007 1:32 PM, Jon Grosshart wrote: > > > Greets all. I'm interested in whipping this page into shape. > > > > > > http://wiki.x.org/wiki/Releases/ModuleVersions > > > > > > It hasn't been updated for 7.3 and if you compare what IS listed there, > it > > > doesn't jive with what tarballs can be found at: > > > > > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > > > Not addressing the possibly deprecated modules, you can find the 7.3 list > here: > > > > http://wiki.x.org/wiki/Releases/7.3 > > > > I've been trying to keep the 7.4 list up to date, but it's about a > > month since I went through xorg-announce to update things: > > > > http://wiki.x.org/wiki/Releases/7.4 > > > > -- > > Dan > > The 7.3 link is what I've been referring to when I decided to make the jump > to 7.3 yesterday. That and the download server of course. I was looking thru > 'picklist' on my webserver and noticed that it now has some minor breakage > with the release of 7.3... > > I don't know how you guys do it Dan. My ultimate goal with picklist was to > come up with the blfs wget files consistently and accurately but it's just > not happening at present. It's a lot of manual effort at the moment, nothing as sophisticated as your script. That was part of the reason why I've been trying to stay on top of the wiki for 7.4. Alan has done a nice job on the wiki, but stuff just slips through. Your best bet is just to stay on top of the releases when they happen: http://lists.freedesktop.org/archives/xorg-announce/ That said, I think there's a lot of duplicated effort here. I'd personally like to see a canonical list of tarballs in git, rather than on the wiki. Something like this: http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules but with the released versions rather than always pointing to git. -- Dan From jgrosshart at gmail.com Tue Dec 11 14:51:35 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Tue, 11 Dec 2007 17:51:35 -0500 Subject: Updating the wiki and other issues In-Reply-To: <475F0CBF.2090100@sun.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <475F0CBF.2090100@sun.com> Message-ID: <9cf823c60712111451k6918a9c2q65ecd1e41f0f8b03@mail.gmail.com> On Dec 11, 2007 5:18 PM, Alan Coopersmith wrote: > Jon Grosshart wrote: > > Greets all. I'm interested in whipping this page into shape. > > > > http://wiki.x.org/wiki/Releases/ModuleVersions > > > > It hasn't been updated for 7.3 and if you compare what IS listed there, > > it doesn't jive with what tarballs can be found at: > > > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > Sorry - I haven't had a chance to update it for 7.3 - I'd be happy if > others did. I originally created it via a script going over the output > of the tarballs in the website, I'm not sure how discrepancies crept in. Right. That's pretty much what I was going to do... > > > > For instance, xf86-video-wsfb... What's up with this guy? It's listed as > > a part of 7.2 on the wiki but is no where to be found in > > http://xorg.freedesktop.org/releases/X11R7.2/src/driver/ . > > Since it doesn't build on Linux (it's a BSD/Solaris version of fbdev), it > often gets overlooked by the release managers. Thanks. That clarifies things a bit. > > > > On a related note, I'm not sure what's up with xf86-video-i810 in 7.3... > > If it was dropped or possibly even merged with xf86-video-intel, then > > why isn't it listed in > > http://xorg.freedesktop.org/releases/X11R7.3/src/deprecated/ ? > > It was simply renamed to -intel. -i810 is no more deprecated than > -ati 6.5, it's just replaced by a newer version. Hmmmm... We could split hairs on that one all day I'm afraid. It really needs to be listed in deprecated since there is no longer a driver tarball of that name. That's the foremost definition of deprecated. "no longer relevant"... We don't have a mkcfm tarball anymore either and that was properly documented in 7.2... O.k.. I'm being a tad selfish because this kind of thing is playing havoc with my script. I have both i810 and intel drivers listed in my driver text file for 7.3. I use a base-line 'build-order' file that is meant to be backwards compatible with previous versions. If i810 was documented in deprecated/ then my script would catch it and chuck i810 out the window if $VERSION = 7.3.... Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgrosshart at gmail.com Tue Dec 11 15:47:42 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Tue, 11 Dec 2007 18:47:42 -0500 Subject: Updating the wiki and other issues In-Reply-To: <91705d080712111441o56cff2ccxeab022a2ca7bf5b3@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> <9cf823c60712111423i37c573acvc792057fa21554fb@mail.gmail.com> <91705d080712111441o56cff2ccxeab022a2ca7bf5b3@mail.gmail.com> Message-ID: <9cf823c60712111547o39875ec2x46de867d8bed1c2f@mail.gmail.com> On Dec 11, 2007 5:41 PM, Dan Nicholson wrote: > On Dec 11, 2007 2:23 PM, Jon Grosshart wrote: > > > > On Dec 11, 2007 4:57 PM, Dan Nicholson wrote: > > > > > > On Dec 11, 2007 1:32 PM, Jon Grosshart wrote: > > > > Greets all. I'm interested in whipping this page into shape. > > > > > > > > http://wiki.x.org/wiki/Releases/ModuleVersions > > > > > > > > It hasn't been updated for 7.3 and if you compare what IS listed > there, > > it > > > > doesn't jive with what tarballs can be found at: > > > > > > > > hxxp://xorg.freedesktop.org/releases/X11R7.{1,2} > > > > > > Not addressing the possibly deprecated modules, you can find the 7.3list > > here: > > > > > > http://wiki.x.org/wiki/Releases/7.3 > > > > > > I've been trying to keep the 7.4 list up to date, but it's about a > > > month since I went through xorg-announce to update things: > > > > > > http://wiki.x.org/wiki/Releases/7.4 > > > > > > -- > > > Dan > > > > The 7.3 link is what I've been referring to when I decided to make the > jump > > to 7.3 yesterday. That and the download server of course. I was looking > thru > > 'picklist' on my webserver and noticed that it now has some minor > breakage > > with the release of 7.3... > > > > I don't know how you guys do it Dan. My ultimate goal with picklist was > to > > come up with the blfs wget files consistently and accurately but it's > just > > not happening at present. > > It's a lot of manual effort at the moment, nothing as sophisticated as > your script. That was part of the reason why I've been trying to stay > on top of the wiki for 7.4. Alan has done a nice job on the wiki, but > stuff just slips through. Your best bet is just to stay on top of the > releases when they happen: > > http://lists.freedesktop.org/archives/xorg-announce/ Ugh..... Yea.... Umm... The whole reason for picklist... If I can get someone or something to do it for me, all the better... :-) The idea is sound anyway. I just need a tiny, tiny push from the Xorg folks is all. That or come up with a re-write which I really don't want to do. > > > That said, I think there's a lot of duplicated effort here. I agree. It's not a very good feeling really. > I'd > personally like to see a canonical list of tarballs in git, rather > than on the wiki. Something like this: > > http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules > > but with the released versions rather than always pointing to git. Yep, so would I and that's a start atleast. Thanks for the link. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joeprogrammer70 at gmail.com Tue Dec 11 17:57:02 2007 From: joeprogrammer70 at gmail.com (Joseph Alten) Date: Tue, 11 Dec 2007 17:57:02 -0800 Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem In-Reply-To: References: <9B3A8C91-4D9A-4CD7-99F0-B37074B877FE@gmail.com> Message-ID: <105EB0BB-2414-43A2-8CCB-C23BF35764DE@gmail.com> On 11-Dec-07, at 6:50 AM, Andreas Schildbach wrote: > Sounds like you are using the -i810 driver, with which it is next to > impossible to exactly get the signal the 2407FPW needs (I tried > with the > 2405 though). > > You should use the -intel driver, if possible. Well, I actually was using the xf86-video-intel driver, but your suggestion gave me an idea. I thought my driver might be out of date, so I tried compiling the latest source code from intellinuxgraphics.org, and all of a sudden it worked! So, a big thank you. One last thing... the resolution isn't set at 1920x1200 by default -- so I have to set it manually with xrandr each time I start X. Here's the relevant sections from my xorg.conf: Section "Device" Identifier "Intel 945G " Driver "intel" Option "monitor-LVDS" "Builtin" Option "monitor-TMDS-1" "External Monitor" EndSection Section "Monitor" Identifier "Builtin" Option "PreferredMode" "1280x800" EndSection Section "Monitor" Identifier "External Monitor" VendorName "DEL" ModelName "DELL 2407WFP" Option "LeftOf" "Builtin" Option "PreferredMode" "1920x1200" EndSection Section "Screen" Identifier "Default Screen" Device "Intel 945G" Monitor "Builtin" Monitor "External Monitor" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1920x1200" "1600x1200" "1680x1050" "1280x800" "1024x768" "640x480" # This optional entry specifies the virtual screen resolution to be used. # If this entry is not present, the virtual screen resolution will be set to # accommodate all the valid video modes given in the Modes entry. # There is a known issue that DRI doesn't work on pre-965 if maximum is larger than 2048x2048. Virtual 2560 2560 EndSubSection EndSection When I run xrandr with no arguments after starting X, it says that TMDS-1 is at some weird resolution, like 1152x700, but it always shows whatever resolution I set as 'PreferredMode' at the top of the available resolutions list. I must be missing something here. Thanks again, Joe From cry_regarder at yahoo.com Tue Dec 11 10:52:01 2007 From: cry_regarder at yahoo.com (Cry Regarder) Date: Tue, 11 Dec 2007 10:52:01 -0800 (PST) Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem In-Reply-To: Message-ID: <788431.70015.qm@web43134.mail.sp1.yahoo.com> Good luck. I still get this problem with th e --- Andreas Schildbach wrote: > Joseph Alten wrote: > >> Using xrandr, I can set the display resolution of >> higher than that; when I try to set it to either >> 1600x1200 or 1920x1200 my monitor goes blank, and >> then I get a message that reads the following: >> >> "Out of range signal. > impossible to exactly get the signal the 2407FPW > needs (I tried with the 2405 though). > > You should use the -intel driver, if possible. Good luck. I still get this with the intel driver. What I find is that I just have to try and start X a billion times and then sooner or later, sometimes a day later, it will just work. This monitor is extraordinarily frustrating. Never buy a 2407FPW. I've tried every option I could think of or find on the web. Cry From galibert at pobox.com Tue Dec 11 21:41:21 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Dec 2007 06:41:21 +0100 Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111451k6918a9c2q65ecd1e41f0f8b03@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <475F0CBF.2090100@sun.com> <9cf823c60712111451k6918a9c2q65ecd1e41f0f8b03@mail.gmail.com> Message-ID: <20071212054121.GA38079@dspnet.fr.eu.org> On Tue, Dec 11, 2007 at 05:51:35PM -0500, Jon Grosshart wrote: > Hmmmm... We could split hairs on that one all day I'm afraid. It really > needs to be listed in deprecated since there is no longer a driver tarball > of that name. That's the foremost definition of deprecated. "no longer > relevant"... We don't have a mkcfm tarball anymore either and that was > properly documented in 7.2... Well, the difference is between deprecated code and deprecated names. And the deprecated directory is more for deprecated code... OG. From thep at linux.thai.net Tue Dec 11 22:08:09 2007 From: thep at linux.thai.net (Theppitak Karoonboonyanan) Date: Wed, 12 Dec 2007 13:08:09 +0700 Subject: [PATCH] NumLock/CapsLock masks in Thai XIM Message-ID: <20071212060808.GA4600@cedar> Hello, As reported in Bug #12517 [1], Thai XIM component in libx11 stops checking input seqences when NumLock/CapsLock is on. This problem is similar to what was once found in GTK+ Thai-Lao IM module, as per GNOME Bug #438261 [2]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=12517 [2] http://bugzilla.gnome.org/show_bug.cgi?id=438261 I have posted a patch to the fd.o bug for a few months, and would like to get it reviewed. The patch is quite small. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 023_thai-im-filter.diff Type: text/x-diff Size: 674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From russ at ashlandhome.net Tue Dec 11 22:06:44 2007 From: russ at ashlandhome.net (Russell Whitaker) Date: Tue, 11 Dec 2007 22:06:44 -0800 (PST) Subject: Updating the wiki and other issues In-Reply-To: <9cf823c60712111547o39875ec2x46de867d8bed1c2f@mail.gmail.com> References: <9cf823c60712111332u2ce2c26g58218bc8514b3818@mail.gmail.com> <91705d080712111357t461d97a6la0ae8944c36ae181@mail.gmail.com> <9cf823c60712111423i37c573acvc792057fa21554fb@mail.gmail.com> <91705d080712111441o56cff2ccxeab022a2ca7bf5b3@mail.gmail.com> <9cf823c60712111547o39875ec2x46de867d8bed1c2f@mail.gmail.com> Message-ID: Concidering the timeline between major releases, and all the bugs that are fixed, what is missing is offical "bug-fix-only" releases, 7.1.1, 7.2.1, 7.3.1, etc, etc. Although, that would make even more work. Russ From remi at gentoo.org Tue Dec 11 23:03:50 2007 From: remi at gentoo.org (=?ISO-8859-1?Q?R=E9mi_Cardona?=) Date: Wed, 12 Dec 2007 08:03:50 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv Message-ID: <475F87D6.1040008@gentoo.org> Hi all, We've recently updated the intel driver to 2.2.0 in Gentoo and while the overall experience is fine, Xv support on my 855 had major regressions since 2.1.1 Usually, playing a video will crash X at some point without any user input (after something like 10 to 20 minutes). If I touch the video program - totem or mplayer in my trials - like minimizing or putting another window in front of it, or switching VT, then X will crash a few seconds to a few minutes after restarting playback. (or even instantaneously if the video is still running) Most of the time, only X crashes (with a randomly colorful screen) but sometimes X will freeze the whole machine. Attached is a Xorg log of one of my many crashes. It's the only log I managed to get, since all other crashes produced no output whatsoever. What's changed wrt Xv support since 2.1 on 855? Are there any alternatives to git-bisect to help find the change? Cheers, -- R?mi Cardona LRI, Universit? Paris-Sud remi.cardona at lri.fr remi at gentoo.org -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log.old URL: From sdl.web at gmail.com Tue Dec 11 23:26:32 2007 From: sdl.web at gmail.com (Leo) Date: Wed, 12 Dec 2007 07:26:32 +0000 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv References: <475F87D6.1040008@gentoo.org> Message-ID: On 2007-12-12 07:03 +0000, R?mi Cardona wrote: > Hi all, > > We've recently updated the intel driver to 2.2.0 in Gentoo and while the > overall experience is fine, Xv support on my 855 had major regressions > since 2.1.1 I seem to have similar problems. I am running Fedora 8 and my video is intel 855 GME. > > Usually, playing a video will crash X at some point without any user > input (after something like 10 to 20 minutes). If I touch the video > program - totem or mplayer in my trials - like minimizing or putting > another window in front of it, or switching VT, then X will crash a few > seconds to a few minutes after restarting playback. (or even > instantaneously if the video is still running) > > Most of the time, only X crashes (with a randomly colorful screen) but > sometimes X will freeze the whole machine. > > Attached is a Xorg log of one of my many crashes. It's the only log I > managed to get, since all other crashes produced no output whatsoever. > > What's changed wrt Xv support since 2.1 on 855? Are there any > alternatives to git-bisect to help find the change? > > Cheers, -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the best OS -- http://www.fedoraproject.org/ From foss-ml at wm1.at Wed Dec 12 02:05:15 2007 From: foss-ml at wm1.at (Willi Mann) Date: Wed, 12 Dec 2007 11:05:15 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <475F87D6.1040008@gentoo.org> References: <475F87D6.1040008@gentoo.org> Message-ID: <475FB25B.8030709@wm1.at> R?mi Cardona schrieb: > Hi all, > > We've recently updated the intel driver to 2.2.0 in Gentoo and while the > overall experience is fine, Xv support on my 855 had major regressions > since 2.1.1 > > Usually, playing a video will crash X at some point without any user > input (after something like 10 to 20 minutes). If I touch the video > program - totem or mplayer in my trials - like minimizing or putting > another window in front of it, or switching VT, then X will crash a few > seconds to a few minutes after restarting playback. (or even > instantaneously if the video is still running) > > Most of the time, only X crashes (with a randomly colorful screen) but > sometimes X will freeze the whole machine. > > Attached is a Xorg log of one of my many crashes. It's the only log I > managed to get, since all other crashes produced no output whatsoever. > > What's changed wrt Xv support since 2.1 on 855? Are there any > alternatives to git-bisect to help find the change? https://bugs.freedesktop.org/show_bug.cgi?id=13108 Might actually be an xserver bug, that's fixed in xserver git. I haven't tested yet. Willi From illth at gmx.de Wed Dec 12 03:01:55 2007 From: illth at gmx.de (Thomas Ilnseher) Date: Wed, 12 Dec 2007 12:01:55 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <475F87D6.1040008@gentoo.org> References: <475F87D6.1040008@gentoo.org> Message-ID: <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> I was using 2.2.0 on gentoo (GL960 Chipset), and noticed that teh 2D performance under compiz-fusion REALLY sucked! (ie. pingus running with 14fps, scrolling in FF feels slow). Reverted to 2.1.1 and everything seems fine again. I would recommend everyone to avoid 2.2.0 ! Tom From remi at gentoo.org Wed Dec 12 03:25:09 2007 From: remi at gentoo.org (=?ISO-8859-1?Q?R=E9mi_Cardona?=) Date: Wed, 12 Dec 2007 12:25:09 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> Message-ID: <475FC515.20701@gentoo.org> Thomas Ilnseher a ?crit : > I was using 2.2.0 on gentoo (GL960 Chipset), and noticed that teh 2D > performance under compiz-fusion REALLY sucked! (ie. pingus running with > 14fps, scrolling in FF feels slow). Reverted to 2.1.1 and everything > seems fine again. > > I would recommend everyone to avoid 2.2.0 ! > > Tom > Well, I'm really thinking about masking 2.2.0 in portage for the time being, as it's creating more problems for users than it is solving. @Intel developpers: As the new maintainer for this driver in Gentoo, could I humbly ask you guys try to push out more releases, even if they are alpha/beta and clearly marked as such (2.x.9[0-9]) so that we can provide better feedback? That would be greatly appreciated. @Willi, Thanks for that bug report. Do you know by any chance which commit in xorg-server fixed this so I can try it on my laptop? Cheers, -- R?mi Cardona LRI, Universit? Paris-Sud remi.cardona at lri.fr remi at gentoo.org From svh at dds.nl Wed Dec 12 03:30:06 2007 From: svh at dds.nl (S. J. van Harmelen) Date: Wed, 12 Dec 2007 12:30:06 +0100 Subject: compile xorg-video-intel driver from source (more info) In-Reply-To: <1197458003.5970.10.camel@localhost> References: <1197458003.5970.10.camel@localhost> Message-ID: <1197459006.5970.12.camel@localhost> I quess I should add that I'm using kernel 2.6.26.5 and Xorg R6.9 On Wed, 2007-12-12 at 12:13 +0100, S. J. van Harmelen wrote: > Hi list, > > I'm trying to compile the xorg-video-intel driver from source in a > thinclient environment and I'm afraid I need some help. > > I downloaded the latest version using gid (git-clone > git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel) and am > now trying to run the autogen.sh script. > > The script unfortunaly stops with this error: > > ====================================================================== > > src/Makefile.am:118: warning: automake does not support conditional > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > src/Makefile.am:118: warning: automake does not support conditional > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > src/Makefile.am:118: warning: automake does not support conditional > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > src/Makefile.am:118: warning: automake does not support conditional > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > Use of uninitialized value in concatenation (.) or string > at /usr/local/bin/automake line 8449. > : am_intel_drv_la_OBJECTS was already defined in condition DRI_TRUE, > which is implied by condition TRUE > am_intel_drv_la_OBJECTS (Automake, where = undefined) = > { > DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > $(am__objects_1) > } > Use of uninitialized value in concatenation (.) or string > at /usr/local/bin/automake line 8449. > : am_intel_drv_la_OBJECTS was already defined in condition TRUE, which > implies condition XMODES_TRUE > am_intel_drv_la_OBJECTS (Automake, where = undefined) = > { > TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > $(am__objects_1) > } > autoreconf: automake failed with exit status: 1 > > ====================================================================== > > Can anyone point me in the right direction to get the driver compiled? > > Thanks! > > Sander From svh at dds.nl Wed Dec 12 03:41:26 2007 From: svh at dds.nl (S. J. van Harmelen) Date: Wed, 12 Dec 2007 12:41:26 +0100 Subject: compile xorg-video-intel driver from source (more info) In-Reply-To: <1197459006.5970.12.camel@localhost> References: <1197458003.5970.10.camel@localhost> <1197459006.5970.12.camel@localhost> Message-ID: <1197459686.5970.16.camel@localhost> On Wed, 2007-12-12 at 12:30 +0100, S. J. van Harmelen wrote: > I quess I should add that I'm using kernel 2.6.26.5 and Xorg R6.9 > > > On Wed, 2007-12-12 at 12:13 +0100, S. J. van Harmelen wrote: > > Hi list, > > > > I'm trying to compile the xorg-video-intel driver from source in a > > thinclient environment and I'm afraid I need some help. > > > > I downloaded the latest version using gid (git-clone > > git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel) and am > > now trying to run the autogen.sh script. > > > > The script unfortunaly stops with this error: > > > > ====================================================================== > > > > src/Makefile.am:118: warning: automake does not support conditional > > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > > src/Makefile.am:118: warning: automake does not support conditional > > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > > src/Makefile.am:118: warning: automake does not support conditional > > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > > src/Makefile.am:118: warning: automake does not support conditional > > definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES > > Use of uninitialized value in concatenation (.) or string > > at /usr/local/bin/automake line 8449. > > : am_intel_drv_la_OBJECTS was already defined in condition DRI_TRUE, > > which is implied by condition TRUE > > am_intel_drv_la_OBJECTS (Automake, where = undefined) = > > { > > DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > > $(am__objects_1) > > } > > Use of uninitialized value in concatenation (.) or string > > at /usr/local/bin/automake line 8449. > > : am_intel_drv_la_OBJECTS was already defined in condition TRUE, which > > implies condition XMODES_TRUE > > am_intel_drv_la_OBJECTS (Automake, where = undefined) = > > { > > TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > > DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo > > i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo > > i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo > > i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo > > i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo > > i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo > > i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo > > $(am__objects_1) > > } > > autoreconf: automake failed with exit status: 1 > > > > ====================================================================== > > > > Can anyone point me in the right direction to get the driver compiled? > > > > Thanks! > > > > Sander Maybe I'm doing this all wrong? My goal is to get the intel driver (not the i810 driver, but the intel driver) to work on the thinclient which runs Xorg R6.9 Is this possible? And if so, how do I get started? Did I download the right source and what to do next? Thanks!! Sander From eikke at eikke.com Wed Dec 12 03:40:09 2007 From: eikke at eikke.com (Nicolas Trangez) Date: Wed, 12 Dec 2007 12:40:09 +0100 Subject: compile xorg-video-intel driver from source (more info) In-Reply-To: <1197459006.5970.12.camel@localhost> References: <1197458003.5970.10.camel@localhost> <1197459006.5970.12.camel@localhost> Message-ID: <1197459610.14640.274.camel@sky.nicolast.be> On Wed, 2007-12-12 at 12:30 +0100, S. J. van Harmelen wrote: > I'm using kernel 2.6.26.5 Cool! Where did you get that? ;-) Nicolas -------------- 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 svh at dds.nl Wed Dec 12 03:47:21 2007 From: svh at dds.nl (S. J. van Harmelen) Date: Wed, 12 Dec 2007 12:47:21 +0100 Subject: compile xorg-video-intel driver from source (more info) In-Reply-To: <1197459610.14640.274.camel@sky.nicolast.be> References: <1197458003.5970.10.camel@localhost> <1197459006.5970.12.camel@localhost> <1197459610.14640.274.camel@sky.nicolast.be> Message-ID: <1197460041.5970.18.camel@localhost> On Wed, 2007-12-12 at 12:40 +0100, Nicolas Trangez wrote: > On Wed, 2007-12-12 at 12:30 +0100, S. J. van Harmelen wrote: > > I'm using kernel 2.6.26.5 > > Cool! Where did you get that? > > ;-) Oeps... Running way ahead of myself ;) I meant 2.6.16.5! > > Nicolas From saschahlusiak at arcor.de Wed Dec 12 03:49:31 2007 From: saschahlusiak at arcor.de (Sascha Hlusiak) Date: Wed, 12 Dec 2007 12:49:31 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> Message-ID: <200712121249.36811.saschahlusiak@arcor.de> Am Mittwoch 12 Dezember 2007 12:01:55 schrieb Thomas Ilnseher: > I was using 2.2.0 on gentoo (GL960 Chipset), and noticed that teh 2D > performance under compiz-fusion REALLY sucked! (ie. pingus running with > 14fps, scrolling in FF feels slow). Reverted to 2.1.1 and everything > seems fine again. That's probably because of the default acceleration method moved from XAA to EXA. Try to move back to XAA (option "AccelMethod") and you should have performance as before. Sascha -------------- 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 svh at dds.nl Wed Dec 12 03:13:23 2007 From: svh at dds.nl (S. J. van Harmelen) Date: Wed, 12 Dec 2007 12:13:23 +0100 Subject: compile xorg-video-intel driver from source Message-ID: <1197458003.5970.10.camel@localhost> Hi list, I'm trying to compile the xorg-video-intel driver from source in a thinclient environment and I'm afraid I need some help. I downloaded the latest version using gid (git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel) and am now trying to run the autogen.sh script. The script unfortunaly stops with this error: ====================================================================== src/Makefile.am:118: warning: automake does not support conditional definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES src/Makefile.am:118: warning: automake does not support conditional definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES src/Makefile.am:118: warning: automake does not support conditional definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES src/Makefile.am:118: warning: automake does not support conditional definition of intel_drv_la_SOURCES in intel_drv_la_SOURCES Use of uninitialized value in concatenation (.) or string at /usr/local/bin/automake line 8449. : am_intel_drv_la_OBJECTS was already defined in condition DRI_TRUE, which is implied by condition TRUE am_intel_drv_la_OBJECTS (Automake, where = undefined) = { DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo $(am__objects_1) } Use of uninitialized value in concatenation (.) or string at /usr/local/bin/automake line 8449. : am_intel_drv_la_OBJECTS was already defined in condition TRUE, which implies condition XMODES_TRUE am_intel_drv_la_OBJECTS (Automake, where = undefined) = { TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo DRI_TRUE => i810_accel.lo i810_cursor.lo i810_dga.lo i810_driver.lo i810_io.lo i810_memory.lo i810_video.lo i810_wmark.lo i830_3d.lo i830_accel.lo i830_bios.lo i830_crt.lo i830_cursor.lo i830_debug.lo i830_display.lo i830_quirks.lo i830_driver.lo i830_dvo.lo i830_i2c.lo i830_io.lo i830_lvds.lo i830_memory.lo i830_modes.lo i830_video.lo i830_sdvo.lo i830_tv.lo i915_3d.lo i915_video.lo i965_video.lo i830_exa.lo i830_xaa.lo i830_render.lo i915_render.lo i965_render.lo $(am__objects_1) } autoreconf: automake failed with exit status: 1 ====================================================================== Can anyone point me in the right direction to get the driver compiled? Thanks! Sander From j at bitron.ch Wed Dec 12 05:54:30 2007 From: j at bitron.ch (=?ISO-8859-1?Q?J=FCrg?= Billeter) Date: Wed, 12 Dec 2007 14:54:30 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <475F87D6.1040008@gentoo.org> References: <475F87D6.1040008@gentoo.org> Message-ID: <1197467670.6107.4.camel@juerg-d820.bitron.ch> On Wed, 2007-12-12 at 08:03 +0100, R?mi Cardona wrote: > Hi all, > > We've recently updated the intel driver to 2.2.0 in Gentoo and while the > overall experience is fine, Xv support on my 855 had major regressions > since 2.1.1 > > Usually, playing a video will crash X at some point without any user > input (after something like 10 to 20 minutes). If I touch the video > program - totem or mplayer in my trials - like minimizing or putting > another window in front of it, or switching VT, then X will crash a few > seconds to a few minutes after restarting playback. (or even > instantaneously if the video is still running) > > Most of the time, only X crashes (with a randomly colorful screen) but > sometimes X will freeze the whole machine. I've also had X crashes with Xv on my Q35 with two monitors with 2.2.0 but not with 2.1.x. J?rg From regina.anger at hotmail.com Wed Dec 12 07:23:35 2007 From: regina.anger at hotmail.com (Regina Anger) Date: Wed, 12 Dec 2007 16:23:35 +0100 Subject: Status of EXA with intel-2.2.0 Message-ID: How well does EXA work with the latest intel-2.2.0 driver? Has anybody done some benchmarking? Has the synchronous request problem Carl Worth reported already been fixed in this release? I ask because if it works well I tend to upgrade my system (my xorg installation is too old to run the driver), otherwise I'll wait again. Greets, Regina _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexdeucher at gmail.com Wed Dec 12 08:23:31 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Wed, 12 Dec 2007 11:23:31 -0500 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: <20071207081343.GB16163@guug.org> References: <20071207071823.GA16163@guug.org> <20071207081343.GB16163@guug.org> Message-ID: On Dec 7, 2007 3:13 AM, Otto Solares wrote: > > On Fri, Dec 07, 2007 at 02:37:05AM -0500, Alex Deucher wrote: > > On Dec 7, 2007 2:18 AM, Otto Solares wrote: > > > Hi! > > > > > > Video card on x86 laptop: > > > > > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > > > > > I used to have an old external CRT monitor attached to the VGA-0 > > > connector and the command `xrand --output LVDS --off` would > > > correctly turn off the laptop's LCD so I can work in the external > > > without having both monitors powered-on. > > > > > > Problem now is that I buy a new external LCD monitor and the > > > above command would turn off both the new LCD and the laptop's > > > LCD. > > > > > > But when `xrandr --output VGA-0 --crtc 0` everything works as > > > expected so I pressume is a bug in the crtc detection when a > > > LCD is attached in the VGA-0 connector both monitors are driven > > > by the same crtc. As I said, plugging the CRT monitor doesn't > > > exhibit this problem. > > > > > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. > > > > Please file a bug (https://bugs.freedesktop.org) and attach your xorg > > log and config. > > Done: Bug # 13557 As per the bug report, can you try again with ati git master? Thanks, Alex From mcnichol at austin.ibm.com Wed Dec 12 08:42:00 2007 From: mcnichol at austin.ibm.com (mcnichol at austin.ibm.com) Date: Wed, 12 Dec 2007 10:42:00 -0600 Subject: [PATCH] NumLock/CapsLock masks in Thai XIM Message-ID: <200712121642.lBCGg0d35004@xanth.austin.ibm.com> > Date: Wed, 12 Dec 2007 13:08:09 +0700 > To: xorg at lists.freedesktop.org > Subject: [PATCH] NumLock/CapsLock masks in Thai XIM > From: Theppitak Karoonboonyanan > > Hello, > > As reported in Bug #12517 [1], Thai XIM component in libx11 stops > checking input seqences when NumLock/CapsLock is on. This problem is > similar to what was once found in GTK+ Thai-Lao IM module, as per GNOME > Bug #438261 [2]. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=3D12517 > [2] http://bugzilla.gnome.org/show_bug.cgi?id=3D438261 > > I have posted a patch to the fd.o bug for a few months, and would like > to get it reviewed. The patch is quite small. > > Regards, > -- > Theppitak Karoonboonyanan > http://linux.thai.net/~thep/ Hi Theppitak, The patch assumes that NumLock is always mapped to Mod2. That may not be true on all systems. I know AIX uses Mod5. Dan From bart at cs.pdx.edu Wed Dec 12 09:10:50 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 12 Dec 2007 09:10:50 -0800 Subject: Second extended call for X.Org Board nominations Message-ID: <200712121710.lBCHAoeG023431@murzim.cs.pdx.edu> As many of you are aware, the initial announcements of the nomination period for the upcoming X.Org Foundation Board election were inadvertently not sent to the X.Org members' email list, although they were sent to the public list. The Election Committee thus reopened nominations. However, when the second announcement was sent to the members' email list, the list server malfunctioned, delaying the message until after the close of the nomination period. Having received several complaints about this, the Election Committee has voted to reopen the nominations for a suitable period, so that those members who were not aware of the earlier nomination periods can participate. Those who were nominated in earlier rounds need not be nominated again. If someone on the xorg list sees a problem with this third announcement, please send email right away to bart at cs.pdx.edu, so that the problem can be promptly resolved. Thanks very much for your attention to this, and for your patience in what is proving to be a difficult process. Nominees will have 24 hours from the time that nominations close to submit their personal statements and, if needed, membership applications. Thus, it is important that those who are nominating do so sooner rather than later. Nominations for the 2007 X.Org Foundation Board of Directors election are currently open and will remain open until 23.59 UTC on Monday, 17 December 2007. All X.Org Foundation members are eligible for election to the board, and there is still time to apply for membership before the deadline. The Board consists of Directors elected from the membership. Each Director is elected to serve a two-year term. Each year, an election is held to bring the total number of Directors to eight. There are currently four Directors (Stuart Anderson, Stuart Kreitman, Kevin Martin, and Jim McQuillan) whose current term terminates in 2007, and four Directors (Egbert Eich, Bart Massey, Keith Packard, and Daniel Stone) whose current term continues through 2008. We thus need at least four nominees to fill the 2008 roster. Directors are expected to participate in regular email list discussions, IRC chats and conference calls to discuss current business. Directors are required to attend (at Foundation expense if necessary) the annual meeting of the X.Org Foundation, which will be held early in 2008 at a location to be determined by the Board of Directors. Directors are also encouraged to attend other official X.Org meetings and X-related events. Nominations must be made by a current X.Org member in good standing. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at: elections at x.org Nominees shall be required to be current members of the X.Org Foundation by the time the election is held, and to submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation submitted in the membership application, will be made available to all voters to help them make their voting decisions. Note that membership in the X.Org Foundation is required to be elected to the Board. Nominees must satisfy the membership criteria by the end of the nomination period. Nominations, membership application or renewal and completed personal statements must be received no later than 23.59 UTC on Sunday, 9 December 2007. Please feel free to forward or repost this message as appropriate. The Election Committee X.Org Foundation From tony at awtrey.com Wed Dec 12 08:51:46 2007 From: tony at awtrey.com (Anthony L. Awtrey) Date: Wed, 12 Dec 2007 11:51:46 -0500 Subject: Regression Problem in Xorg 7.3 Message-ID: <476011A2.9040502@awtrey.com> Hello the list, Short Version: I've got a weird regression performance problem between Xorg 6.5 and Xorg 7.x and I don't know where to report the bug or the details that I need to provide to hopefully get a fix. Basically, it looks like that some image and pixmap display operations now take 50% to 100% longer in Xorg 7.3 when compared to Xorg 6.5. Using Debian Etch and Debian Lenny (pre-release) as baselines, I can demonstrate this issue very clearly. Details including x11perf and test applications are here: http://www.awtrey.com/files/xorg-performance/Xorg_Performance.tar.gz Long Version: I've got a Debian-based touchscreen application that runs on Panasonic Toughbook hardware, specifically the CF-18, the CF-19 and CF-74 models. Panasonic revs the hardware periodically without changing the model number and the "Mark III" version of the CF-74 utilizes a "Intel Corporation Mobile Integrated Graphics Controller" that has required that I look past our Debian Etch baseline, which runs a 2.6.18 kernel + Xorg 6.5, to get hardware acceleration to work. Once I home rolled the 2.6.23 kernel and hand-built the Debian packages for Xorg 7.3, I noticed a performance problem relating to the display of images. To prove that it wasn't something I introduced in my franken-distro, I was able to reproduce the same issue with the current pre-release of Debian Lenny running 2.6.22 and Xorg 7.2. The touchscreen application is written in Qt4, so to minimize the possibility of the issue being related to Qt4 we scripted both an example application in C++ / Qt4 and a Python/GTK2 script that demonstrates the same issue using two different implementations. In most cases Xorg 7.x is faster than Xorg 6.5, but in some very specific cases (unfortunately the ones that I need) it is much, much slower. The best example of this is the Python / Gtk2 code. In one case, we used the lower level Gtk pixmap functions to display an image with a transparent overlay as fast as possible. As expected, the test runs faster on Lenny. However, if we use the more typical high level Gtk.Image functions, Lenny is much slower than Etch. Here are the actual results from runs on our CF-18 hardware: Debian Etch cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 15.002710 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 17.241337 Debian Lenny cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 12.012802 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 25.642715 The Qt4 test application we provided is much closer to what the touchscreen application actually does and when you run the application under Debian Etch, touching the "Toggle" button to display the overlay happens immediately. When you do the same thing under Debian Lenny, you see a very noticeable 1/2 second hesitation before the overlay displays. Since this is how we pop menus up all over our touch screen application, the usability of the application has been significantly reduced. I searched the bug list and couldn't find an issue that seemed to address this performance issue. I don't know if it is related to the Intel driver (we tried 2.0, 2.1 and 2.2 with no improvement) or some other library or component of Xorg. Any help or insight you guys can provide would be greatly appreciated. I'll be happy to test anything you suggest. Tony From bart at cs.pdx.edu Wed Dec 12 09:17:54 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 12 Dec 2007 09:17:54 -0800 Subject: Second extended call for X.Org Board nominations Message-ID: <200712121717.lBCHHsvS023515@murzim.cs.pdx.edu> (My previous message had conflicting dates on it. The date of Monday 17 December was of course correct. My apologies for the repost.) As many of you are aware, the initial announcements of the nomination period for the upcoming X.Org Foundation Board election were inadvertently not sent to the X.Org members' email list, although they were sent to the public list. The Election Committee thus reopened nominations. However, when the second announcement was sent to the members' email list, the list server malfunctioned, delaying the message until after the close of the nomination period. Having received several complaints about this, the Election Committee has voted to reopen the nominations for a suitable period, so that those members who were not aware of the earlier nomination periods can participate. Those who were nominated in earlier rounds need not be nominated again. If someone on the xorg list sees a problem with this third announcement, please send email right away to bart at cs.pdx.edu, so that the problem can be promptly resolved. Thanks very much for your attention to this, and for your patience in what is proving to be a difficult process. Nominees will have 24 hours from the time that nominations close to submit their personal statements and, if needed, membership applications. Thus, it is important that those who are nominating do so sooner rather than later. Nominations for the 2007 X.Org Foundation Board of Directors election are currently open and will remain open until 23.59 UTC on Monday, 17 December 2007. All X.Org Foundation members are eligible for election to the board, and there is still time to apply for membership before the deadline. The Board consists of Directors elected from the membership. Each Director is elected to serve a two-year term. Each year, an election is held to bring the total number of Directors to eight. There are currently four Directors (Stuart Anderson, Stuart Kreitman, Kevin Martin, and Jim McQuillan) whose current term terminates in 2007, and four Directors (Egbert Eich, Bart Massey, Keith Packard, and Daniel Stone) whose current term continues through 2008. We thus need at least four nominees to fill the 2008 roster. Directors are expected to participate in regular email list discussions, IRC chats and conference calls to discuss current business. Directors are required to attend (at Foundation expense if necessary) the annual meeting of the X.Org Foundation, which will be held early in 2008 at a location to be determined by the Board of Directors. Directors are also encouraged to attend other official X.Org meetings and X-related events. Nominations must be made by a current X.Org member in good standing. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at: elections at x.org Nominees shall be required to be current members of the X.Org Foundation by the time the election is held, and to submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation submitted in the membership application, will be made available to all voters to help them make their voting decisions. Note that membership in the X.Org Foundation is required to be elected to the Board. Nominees must satisfy the membership criteria by the end of the nomination period. Nominations, membership application or renewal and completed personal statements must be received no later than 23.59 UTC on Monday, 17 December 2007. Please feel free to forward or repost this message as appropriate. The Election Committee X.Org Foundation From jbarnes at virtuousgeek.org Wed Dec 12 09:26:18 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 12 Dec 2007 09:26:18 -0800 Subject: Status of EXA with intel-2.2.0 In-Reply-To: References: Message-ID: <200712120926.18862.jbarnes@virtuousgeek.org> On Wednesday, December 12, 2007 7:23 am Regina Anger wrote: > How well does EXA work with the latest intel-2.2.0 driver? Has anybody done > some benchmarking? Has the synchronous request problem Carl Worth reported > already been fixed in this release? > > I ask because if it works well I tend to upgrade my system (my xorg > installation is too old to run the driver), otherwise I'll wait again. Well it depends on what you're doing... We moved to EXA by default because XAA doesn't support (and never will) several features that the driver provides, like a tiled front buffer, framebuffer compression, Xv, and others. However, in certain configurations you may see slowness due to the way Render acceleration is implemented; we're working toward a fix now, but in the meantime you can use the "ExaNoComposite" option if you see slowness. Jesse From adr3nald0s at gmail.com Wed Dec 12 10:01:47 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Wed, 12 Dec 2007 12:01:47 -0600 Subject: Mouse problems with mixed monitor rotations Message-ID: <308083c30712121001y463cf5f3jfd8143fc8ae1b7bc@mail.gmail.com> I just submitted bug 13624 for this problem, https://bugs.freedesktop.org/show_bug.cgi?id=13624. Now that basic xrandr works with my configuration, I have found problems with the mouse cursor. I have a monitor configuration where my laptop's LVDS is oriented normally but my external VGA-0 monitor is left-rotated into portrait orientation as follows: +-----+ +---+ | | | | +-----+ | | | | +---+ Here is the pertinent output from xrandr: $ xrandr -q Screen 0: minimum 320 x 200, current 3120 x 1600, maximum 3520 x 1920 VGA-0 connected 1200x1600+1920+0 left (normal left inverted right) 408mm x 306mm 1600x1200 60.0*+ 59.9 ... LVDS connected 1920x1200+0+0 (normal left inverted right) 0mm x 0mm 1920x1200 60.0*+ ... There are two related issues. The mouse cursor is left-rotated and appears correctly on the portrait monitor. But it is turned on its side when moved to the landscape laptop display. This is not _too_ disturbing, but could be better. It gets even stranger, if you set the position of the VGA-0 to overlap the region displayed by the LVDS and move the mouse into the shared area, it will be oriented correctly on the VGA-0 and incorrectly on the LVDS. Now I under stand from a video-memory perspective they are both being drawn in the same "direction". The second more important bug is that on the landscape display the cursor's apparent and actual hot point differ. Visually the mouse points to what seems to be the lower-left corner of its sprite space, but the actual hot point as detected by hovering over a button or clicking on something is the upper-left corner. This is further evidenced by the fact that you cannot move the pointer clear to the top of the screen. From Dj_Doe at gmx.de Wed Dec 12 10:49:18 2007 From: Dj_Doe at gmx.de (=?iso-8859-1?Q?Nikolas_D=F6rfler?=) Date: Wed, 12 Dec 2007 19:49:18 +0100 Subject: Multi Pointer X MPX Build problem Message-ID: <001301c83cef$b4007bc0$15b2a8c0@fuckup> Hi, I'm trying to build the Multi Pointer X branch. Following the documentation at http://wearables.unisa.edu.au/mpx/?q=downloads and the Xorg Modular developers guide I first downloaded all necessary packages with the git script, and then switched to the MPX branch as described. Now I tried to compile X with glx support. For this I need mesa available. I first tried to use Mesa 6.5.2 as described in the documentation. This did not work and stopped when configuring >checking for XLIB... yes >checking for GL... yes >Creating destination directories for mesa module ... > error: Source directory >/home/doerflen/mpx_new/Mesa-6.5.2/src/mesa/vbo does not exist >configure: error: Failed to link Mesa source tree. Please specify a >proper path to Mesa sources, or disable GLX. Then I got the newest Master Branch Version of Mesa. Now the build seemed to work but when linking the libglx.a I got the following error: gcc -DHAVE_DIX_CONFIG_H -DNO_HW_ONLY_EXTS -DNO_MODULE_EXTS -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/tmp/modular//include -I/tmp/modular//include/pixman-1 -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -g -O2 -o Xvfb InitInput.o InitOutput.o dpmsstubs.o stubs.o miinitext.o ../../fb/.libs/libfb.a ../../xfixes/.libs/libxfixes.a ../../Xext/.libs/libXext.a ../../dbe/.libs/libdbe.a ../../XTrap/.libs/libxtrap.a ../../record/.libs/librecord.a ../../GL/glx/.libs/libglx.a ../../GL/mesa/.libs/libGLcore.a ../../render/.libs/librender.a ../../randr/.libs/librandr. a ../../damageext/.libs/libdamageext.a ../../miext/damage/.libs/libdamage.a ../../miext/shadow/.libs/libshadow.a ../../Xi/.libs/libXi.a ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a ../../composite/.libs/libcomposite.a ../../dix/.libs/libxpstubs.a ../../os/.libs/libcwrapper.a libfbcmap.a ../../dix/.libs/libdix.a ../../config/libconfig.a ../../mi/.libs/libmi.a ../../os/.libs/libos.a -L/tmp/modular//lib -L/lib /tmp/modular//lib/libXfont.so /usr/lib/libfreetype.so /tmp/modular//lib/libXau.so /tmp/modular/lib/libfontenc.so -lz /tmp/modular/lib/libpixman-1.so /usr/lib/libhal.so /usr/lib/libusb.so -ldl -luuid -ldbus-1 /tmp/modular//lib/libXdmcp.so -lcrypto -lm -lrt -Wl,--rpath -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib -Wl,--rpath -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function `__glXDisp_ProgramParameter4fvNV': /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5190: undefined reference to `CALL_ProgramParameter4fvNV' ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function `__glXDisp_ProgramParameter4dvNV': /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5181: undefined reference to `CALL_ProgramParameter4dvNV' ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function `__glXDispSwap_ProgramParameter4fvNV': /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5346: undefined reference to `CALL_ProgramParameter4fvNV' ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function `__glXDispSwap_ProgramParameter4dvNV': /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5337: undefined reference to `CALL_ProgramParameter4dvNV' collect2: ld returned 1 exit status make[3]: *** [Xvfb] Fehler 1 make[3]: Leaving directory `/home/doerflen/mpx/xserver/hw/vfb' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/doerflen/mpx/xserver/hw/vfb' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/doerflen/mpx/xserver/hw' make: *** [all-recursive] Fehler 1 Since I could not locate the "CALL_ProgramParameter4dvNV" function I'm not sure what to do to fix this problem. Maybe I have a wrong version of Mesa? Has anyone experience in building MPX? Thanks for your help Niko D?rfler -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Wed Dec 12 10:51:29 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 12 Dec 2007 19:51:29 +0100 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <200712120926.18862.jbarnes@virtuousgeek.org> References: <200712120926.18862.jbarnes@virtuousgeek.org> Message-ID: <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> Hi Jesse, I am also quite interested in EXA on the GMA950/945GM. Does the current driver still wait after each command sent to the GPU (i830WaitSynnc), and if so, will this also fixed for GMA900/GMA950 chips or only on 965 based GPUs? lg Clemens 2007/12/12, Jesse Barnes : > On Wednesday, December 12, 2007 7:23 am Regina Anger wrote: > > How well does EXA work with the latest intel-2.2.0 driver? Has anybody done > > some benchmarking? Has the synchronous request problem Carl Worth reported > > already been fixed in this release? > > > > I ask because if it works well I tend to upgrade my system (my xorg > > installation is too old to run the driver), otherwise I'll wait again. > > Well it depends on what you're doing... We moved to EXA by default because > XAA doesn't support (and never will) several features that the driver > provides, like a tiled front buffer, framebuffer compression, Xv, and others. > However, in certain configurations you may see slowness due to the way Render > acceleration is implemented; we're working toward a fix now, but in the > meantime you can use the "ExaNoComposite" option if you see slowness. > > Jesse > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From ajax at nwnk.net Wed Dec 12 11:45:38 2007 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 12 Dec 2007 14:45:38 -0500 Subject: Regression Problem in Xorg 7.3 In-Reply-To: <476011A2.9040502@awtrey.com> References: <476011A2.9040502@awtrey.com> Message-ID: <1197488738.30771.32.camel@localhost.localdomain> On Wed, 2007-12-12 at 11:51 -0500, Anthony L. Awtrey wrote: > Hello the list, > > Short Version: > > I've got a weird regression performance problem between Xorg 6.5 and > Xorg 7.x and I don't know where to report the bug or the details that I > need to provide to hopefully get a fix. Basically, it looks like that > some image and pixmap display operations now take 50% to 100% longer in > Xorg 7.3 when compared to Xorg 6.5. Using Debian Etch and Debian Lenny > (pre-release) as baselines, I can demonstrate this issue very clearly. > Details including x11perf and test applications are here: > > http://www.awtrey.com/files/xorg-performance/Xorg_Performance.tar.gz I really don't think you mean 6.5, but regardless. One first-order thing you could do is compare the performance numbers for those tests against the Xvfb's from Etch and Lenny. That would at least give you a hint whether the overhead is in the DDX or in the core server. Likewise, comparing between the i810 and vesa drivers from each release would hint whether it's a driver problem. - ajax -------------- 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 irwin at beluga.phys.uvic.ca Wed Dec 12 11:37:44 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 12 Dec 2007 11:37:44 -0800 (PST) Subject: [xorg] Regression Problem in Xorg 7.3 In-Reply-To: <476011A2.9040502@awtrey.com> References: <476011A2.9040502@awtrey.com> Message-ID: On 2007-12-12 11:51-0500 Anthony L. Awtrey wrote: > Hello the list, > > Short Version: > > I've got a weird regression performance problem between Xorg 6.5 and > Xorg 7.x and I don't know where to report the bug or the details that I > need to provide to hopefully get a fix. Basically, it looks like that > some image and pixmap display operations now take 50% to 100% longer in > Xorg 7.3 when compared to Xorg 6.5. Using Debian Etch and Debian Lenny > (pre-release) as baselines, I can demonstrate this issue very clearly. I wonder if that is an XAA (default on earlier X versions) versus EXA (default on latest X versions) performance difference? For the intel driver (which I assume you are using since your hardware is "Intel Corporation Mobile Integrated Graphics Controller") you can specify Option "AccelMethod" "XAA" in the Device Section to insure you use XAA for the latest X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From tony at awtrey.com Wed Dec 12 11:51:04 2007 From: tony at awtrey.com (Anthony L. Awtrey) Date: Wed, 12 Dec 2007 14:51:04 -0500 Subject: [xorg] Regression Problem in Xorg 7.3 In-Reply-To: References: <476011A2.9040502@awtrey.com> Message-ID: <47603BA8.7000306@awtrey.com> On 12/12/2007 02:37 PM, Alan W. Irwin wrote: > I wonder if that is an XAA (default on earlier X versions) versus EXA > (default on latest X versions) performance difference? > > For the intel driver (which I assume you are using since your hardware is > "Intel Corporation Mobile Integrated Graphics Controller") you can specify > > Option "AccelMethod" "XAA" > > in the Device Section to insure you use XAA for the latest X. Thanks for the reply Alan, we are using the intel driver. Adding that option had no affect on this particular issue, but when we starting using it a few weeks ago, it did fix some other issues like disappearing fonts, odd image artifacts, etc. which were issues we found reported in the Debian bug system. Tony From daniel at fooishbar.org Wed Dec 12 12:46:21 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Wed, 12 Dec 2007 22:46:21 +0200 Subject: [ANNOUNCE] xorg-server 1.4.0.90 Message-ID: <20071212204621.GA26358@fooishbar.org> A quick pre-release so distros can start shipping something before 1.4.1 comes out, whenever that is. Aaron Plattner (2): Don't segfault on shutdown if we never managed to connect to dbus. Set noCompositeExtension to TRUE when failing to initialize the extension (e.g. when Xinerama is enabled). Alan Coopersmith (1): Actually build Secure RPC authentication support (missed in modularization) Bartosz Fabianowski (1): Input: Fix proximity events with valuators Daniel Stone (17): configure.ac/XFree86: Only build XF86Misc and XF86VidMode when appropriate Xi: Include XI protocol header in exevents.h XKB: Add more bits to xkbsrv.h XFree86: Remove ridiculous SIGIO debugging XKB: Don't update indicators on all devices, add missing include file XKB: Cope with all events in XkbProcessKeyboardEvent Input: Generate XKB mapping changes for all core-sending devices (bug #12523) DIX: XKB: Set xkbInfo to NULL as well as freeing it (bug #10639) .gitignore: Ignore build directories XFree86 Misc/VidMode: Remove ridiculous debug ErrorFs GetKeyboardEvents: Reject out-of-range keycodes (bug #12528) XKB: Don't ring the bell when we don't have a BellProc (bug #13246) ProcessOtherEvent: Don't do double translation of button events WaitForSomething: Ignore EAGAIN XKB: Actions: Don't run certain actions on the core keyboard KDrive: Xephyr: Fix non-GLX builds Bump to 1.4.0.90 Dodji Seketeli (1): Xephyr: don't initialise the GLX extension Elvis Pranskevichus (1): Config: D-Bus: Fix dbus_bus_request_name failure check Kanru Chen (1): Config: HAL: Fix XKB option parsing Keith Packard (1): Screen size changing should leave FB alone when X is inactive. Mark Vytlacil (1): XFree86: Input: Save/restore errno around SIGIO (bug #10683) Markku Vire (1): Config: HAL: Touchpads are pointers too Matthias Hopf (1): Prefer configured DisplaySize to probed DDC data, if available. Michel D?nzer (3): EXA: Punt on fallback case not handled correctly in exaFillRegionTiled. EXA: Make sure tile offsets passed to drivers are never negative. EXA: Don't attempt to move in pixmaps that can't be accelerated. Naoki Hamada (1): Input: Fix key down test (bug #12858) Peter Harris (1): Add missing swaps in panoramiXSwap.c Peter Hutterer (11): config: return BadValue to caller if add/remove doesn't have parameters. config: Use [config/dbus] consistently for error messages. xkb: Store the action filters per device in the XkbSrvInfoRec. Save processInputProc before wrapping it and restore it later, instead of xkb: enable XI event processing for xkb. dix: add XI event support to FixKeyState. dix: don't compress motion events from different devices (EventEnqueue) xkb: xkbHandleActions: let wrapping take care of event delivery. xkb: Unwrap properly in ProcessPointerEvent. xfree86: wrap keyboard devices for XKB. XKB: Generate correct key repeat events (bug #13114) Rich Coe (2): OS: Connection: Don't shut down disappeared clients (bug #7876) OS: Connection: Keep trying select while it gets interrupted (bug #9240) git tag: xorg-server-1.4.0.90 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.4.0.90.tar.bz2 MD5: bb16e969850dbb5d3805cb88d35656d0 xorg-server-1.4.0.90.tar.bz2 SHA1: 7c492ac32bd83b521f5c016e4728fccf9cba55db xorg-server-1.4.0.90.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.4.0.90.tar.gz MD5: 07e3e82113d433905f6013cd676c371a xorg-server-1.4.0.90.tar.gz SHA1: 5b422ae33315c836865792140afd9e2d9c09fc36 xorg-server-1.4.0.90.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tony at awtrey.com Wed Dec 12 13:30:09 2007 From: tony at awtrey.com (Anthony L. Awtrey) Date: Wed, 12 Dec 2007 16:30:09 -0500 Subject: Regression Problem in Xorg 7.3 In-Reply-To: <1197488738.30771.32.camel@localhost.localdomain> References: <476011A2.9040502@awtrey.com> <1197488738.30771.32.camel@localhost.localdomain> Message-ID: <476052E1.5090908@awtrey.com> On 12/12/2007 02:45 PM, Adam Jackson wrote: > I really don't think you mean 6.5, but regardless. You are correct, it was not 6.5. Debian changed their version numbers and it threw me off. As best I can determine Etch shipped with Xorg 7.0. > One first-order thing you could do is compare the performance numbers > for those tests against the Xvfb's from Etch and Lenny. That would at > least give you a hint whether the overhead is in the DDX or in the core > server. Likewise, comparing between the i810 and vesa drivers from each > release would hint whether it's a driver problem. I installed xvfb as you suggested. I ran my pixmap_perf.py and image_perf.py applications against both Xorg and Xrbf servers. Etch benchmark using Xorg: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 15.002710 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 17.241337 Etch benchmark using Xvfb: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 0.217493 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 30.973030 Lenny benchmark using Xorg: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 12.012802 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 25.642715 Lenny benchmark using Xvfb: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 0.336718 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 18.626873 I'm not sure what this means... The image_perf.py on Lenny running Xvfb is much faster than the same code running on Etch running Xvfb. So does the slow Lenny Xorg performance mean it is more likely the Intel driver? Tony From tony at awtrey.com Wed Dec 12 13:48:27 2007 From: tony at awtrey.com (Anthony L. Awtrey) Date: Wed, 12 Dec 2007 16:48:27 -0500 Subject: Regression Problem in Xorg 7.3 In-Reply-To: <1197488738.30771.32.camel@localhost.localdomain> References: <476011A2.9040502@awtrey.com> <1197488738.30771.32.camel@localhost.localdomain> Message-ID: <4760572B.6040702@awtrey.com> On 12/12/2007 02:45 PM, Adam Jackson wrote: > Likewise, comparing between the i810 and vesa drivers from each > release would hint whether it's a driver problem. Missed that comment. Here are those numbers as well: Etch benchmark with Xorg/Vesa: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 55.300165 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 38.392552 Lenny benchmark with Xorg/Vesa: cf-18:~/Xorg_Performance/pygtk$ ./pixmap_perf.py Time to draw a pixmap over a pixmap 5000 times: 56.187047 cf-18:~/Xorg_Performance/pygtk$ ./image_perf.py Time to flip the blue overlay 500 times: 38.075571 Very consistent performance running with the Vesa driver... Tony From rafaelmejiasc at gmail.com Wed Dec 12 14:18:28 2007 From: rafaelmejiasc at gmail.com (=?ISO-8859-1?Q?Rafael_Mej=EDas?=) Date: Thu, 13 Dec 2007 17:48:28 +1930 Subject: Resolution problem with i810 Message-ID: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> Hi. I'm having a problem. I own a Gateway Laptop Computer M305S with an Intel 82852/855GM Integrated Graphics Card. I'm using Debian Etch with 2.6.18-5-686 Kernel and I can't get a resolution bigger than 800x600 (I know that it works with at least 1024x768 resolution on WinXp). I'd really like to know what do I need to do in order to get a higher resolution: Do I need - a newer kernel? - a newer xserver-xorg? - new drivers for my card? - all of the above? - more than the above? - a new computer??? I've found little documentation on the Internet about this exact problem. Some say that I need to perform so many steps that is better to forget it... I've even tried a Debian Lenny Live CD with better results but I was not able to install it on my laptop. Is it possible to achieve 1024x768 without having to install a new system? Thanks for any help. Here's is my xorg.conf and the log (sorry; they're very long but I'm desperate): ******************************************************* ******************************************************* ******************************************************* /etc/X11/xorg.conf: Section "Files" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load "bitmap" Load "ddc" Load "dri" Load "extmod" Load "freetype" Load "glx" Load "int10" Load "vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/dev/psaux" Option "Protocol" "auto-dev" Option "HorizScrollDelta" "0" EndSection Section "Device" Identifier "Intel Corporation 82852/855GM Integrated Graphics Device" Driver "i810" BusID "PCI:0:2:0" EndSection Section "Monitor" Identifier "Monitor gen?rico" Option "DPMS" HorizSync 28-49 VertRefresh 43-72 EndSection Section "Screen" Identifier "Default Screen" Device "Intel Corporation 82852/855GM Integrated Graphics Device" Monitor "Monitor gen?rico" DefaultDepth 24 SubSection "Display" Depth 1 Modes "1024x768" EndSubSection SubSection "Display" Depth 4 Modes "1024x768" EndSubSection SubSection "Display" Depth 8 Modes "1024x768" EndSubSection SubSection "Display" Depth 15 Modes "1024x768" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" EndSubSection SubSection "Display" Depth 24 Modes "1024x768" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" InputDevice "Synaptics Touchpad" EndSection Section "DRI" Mode 0666 EndSection ******************************************************* ******************************************************* ******************************************************* /var/log/Xorg.0.log: X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: UNKNOWN Current Operating System: Linux laptop-or 2.6.18-5-686 #1 SMP Sat Dec 1 22:58:58 UTC 2007 i686 Build Date: 04 September 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Wed Dec 12 16:53:06 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Monitor gen?rico" (**) | |-->Device "Intel Corporation 82852/855GM Integrated Graphics Device" (**) |-->Input Device "Generic Keyboard" (**) |-->Input Device "Configured Mouse" (**) |-->Input Device "Synaptics Touchpad" (WW) The directory "/usr/X11R6/lib/X11/fonts/misc" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi/" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/Type1" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi" does not exist. Entry deleted from font path. (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. Entry deleted from font path. (**) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3580 card 107b,0402 rev 01 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 8086,3584 card 107b,0402 rev 01 class 08,80,00 hdr 00 (II) PCI: 00:00:3: chip 8086,3585 card 107b,0402 rev 01 class 08,80,00 hdr 80 (II) PCI: 00:02:0: chip 8086,3582 card 107b,0402 rev 01 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,3582 card 107b,0402 rev 01 class 03,80,00 hdr 80 (II) PCI: 00:1d:0: chip 8086,24c2 card 107b,0402 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 107b,0402 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 107b,0402 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev 83 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24cc card 0000,0000 rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24ca card 107b,0402 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,24c3 card 107b,0402 rev 03 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 107b,0402 rev 03 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,24c6 card 144f,1050 rev 03 class 07,03,00 hdr 00 (II) PCI: 02:02:0: chip 1217,6972 card 3401,0000 rev 00 class 06,07,00 hdr 02 (II) PCI: 02:08:0: chip 8086,103d card 107b,0402 rev 83 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,3), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,6), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xe0200000 - 0xe02fffff (0x100000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0x30000000 - 0x31ffffff (0x2000000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 3: bridge is at (2:2:0), (2,3,6), BCTRL: 0x0580 (VGA_EN is cleared) (II) Bus 3 I/O range: [0] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [1] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] (II) Bus 3 prefetchable memory range: [0] -1 0 0x30000000 - 0x31ffffff (0x2000000) MX[B] (--) PCI:*(0:2:0) Intel Corporation 82852/855GM Integrated Graphics Device rev 1, Mem @ 0xe8000000/27, 0xe0000000/19, I/O @ 0x1800/3 (--) PCI: (0:2:1) Intel Corporation 82852/855GM Integrated Graphics Device rev 1, Mem @ 0xf0000000/27, 0xe0080000/19 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [1] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [2] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [3] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [4] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [5] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [6] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [7] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [8] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [9] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [10] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [11] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [12] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [13] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [14] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [15] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [16] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [17] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [18] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [1] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [2] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [3] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [4] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [5] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [6] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [7] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [8] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [9] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [10] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [11] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [12] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [13] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [14] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [15] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [16] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [17] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [18] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x31ffffff (0x31f00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x31ffffff (0x31f00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [5] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [6] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [7] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [8] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [9] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [10] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [11] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [16] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [17] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [18] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [19] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [20] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [21] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [22] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [23] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [24] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) (II) LoadModule: "bitmap" (II) Reloading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Loading font Bitmap (II) LoadModule: "ddc" (II) Loading /usr/lib/xorg/modules/libddc.so (II) Module ddc: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/lib/xorg/modules/linux/libdrm.so (II) Module drm: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "freetype" (II) Loading /usr/lib/xorg/modules/fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 7.1.1, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules/libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) LoadModule: "vbe" (II) Loading /usr/lib/xorg/modules/libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 ABI class: X.Org Video Driver, version 1.0 (II) LoadModule: "i810" (II) Loading /usr/lib/xorg/modules/drivers/i810_drv.so (II) Module i810: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.7.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.0 (II) LoadModule: "kbd" (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.6 (II) LoadModule: "mouse" (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.6 (II) LoadModule: "synaptics" (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so (II) Module synaptics: vendor="The XFree86 Project" compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 XInput Driver ABI class: XFree86 XInput driver, version 0.3 (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 965G, 965G, 965Q, 946GZ (II) Primary Device is: PCI 00:02:0 (--) Chipset 852GM/855GM found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x31ffffff (0x31f00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [5] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [6] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [7] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [8] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [9] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [10] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [11] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [16] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [17] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [18] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [19] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [20] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [21] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [22] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [23] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [24] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x31ffffff (0x31f00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [5] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [6] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [7] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [8] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [9] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [10] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [11] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [12] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [13] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B] [14] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [15] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [18] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [19] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [20] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [21] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [22] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [23] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [24] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [25] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [26] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [27] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) [28] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B] [29] 1 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Reloading /usr/lib/xorg/modules/libvbe.so (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules/libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 7.1.1, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.0 (**) I810(0): Depth 24, (--) framebuffer bpp 32 (==) I810(0): RGB weight 888 (==) I810(0): Default visual is TrueColor (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) I810(0): initializing int10 (II) Loading sub module "vm86" (II) LoadModule: "vm86" (II) Loading /usr/lib/xorg/modules/libvm86.so (II) Module vm86: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) I810(0): Primary V_BIOS segment is: 0xc000 (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 8000 kB (II) I810(0): VESA VBE OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 852GM (--) I810(0): Chipset: "852GM/855GM" (--) I810(0): Linear framebuffer at 0xE8000000 (--) I810(0): IO registers at addr 0xE0000000 (II) I810(0): 2 display pipes available. (II) I810(0): detected 8060 kB stolen memory. (II) I810(0): Kernel reported 110080 total, 1 used (II) I810(0): I830CheckAvailableMemory: 440316 kB available (II) I810(0): Monitoring connected displays enabled (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (WW) I810(0): Extended BIOS function 0x5f11 not supported. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) I810(0): initializing int10 (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000 (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 12288 kB (II) I810(0): VESA VBE OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Tweak BIOS image to 12288 kB VideoRAM (--) I810(0): Pre-allocated VideoRAM: 8060 kByte (==) I810(0): VideoRAM: 65536 kByte (==) I810(0): video overlay key set to 0x101fe (**) I810(0): page flipping disabled (==) I810(0): Using gamma correction (1.0, 1.0, 1.0) (II) I810(0): BIOS Build: 2880 (==) I810(0): Device Presence: disabled. (==) I810(0): Display Info: enabled. (II) I810(0): Broken BIOSes cause the system to hang here. If you encounter this problem please add Option "DisplayInfo" "FALSE" to the Device section of your XF86Config file. (II) I810(0): Display Info: CRT: attached: FALSE, present: TRUE, size: (0,0) (II) I810(0): Display Info: TV: attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: TRUE, size: (1024,768) (II) I810(0): Display Info: Second (second CRT): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP2 (second digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: LFP2 (second local flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Size of device LFP (local flat panel) is 1024 x 768 (II) I810(0): No active displays on Pipe A. (II) I810(0): Currently active displays on Pipe B: (II) I810(0): LFP (local flat panel) (II) I810(0): Lowest common panel size for pipe B is 1024 x 768 (==) I810(0): Display is using Pipe B (--) I810(0): Maximum frambuffer space: 65368 kByte (II) I810(0): VESA VBE PanelID read successfully (II) I810(0): PanelID returned panel resolution : 1024x768 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/lib/xorg/modules/libddc.so (II) I810(0): VESA VBE DDC supported (II) I810(0): VESA VBE DDC Level none (II) I810(0): VESA VBE DDC transfer in appr. 0 sec. (II) I810(0): VESA VBE DDC read failed (--) I810(0): A non-CRT device is attached to pipe B. No refresh rate overrides will be attempted. (--) I810(0): Maximum space available for video modes: 12288 kByte Mode: 30 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 37 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 37 LinNumberOfImagePages: 37 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 32 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 800 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 26 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 800 BnkNumberOfImagePages: 26 LinNumberOfImagePages: 26 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 34 (1024x768) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 15 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 15 LinNumberOfImagePages: 15 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 36 (1024x600) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1024 XResolution: 1024 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 20 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 20 LinNumberOfImagePages: 20 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 38 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 8 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 8 LinNumberOfImagePages: 8 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3a (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 3c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1920 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 3 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1920 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 41 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 20 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 20 LinNumberOfImagePages: 20 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 43 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 11 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 11 LinNumberOfImagePages: 11 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 45 (1024x768) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 47 (1024x600) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 2048 XResolution: 1024 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 49 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 4b (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 Mode: 4d (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 3840 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3840 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 230000000 *Mode: 50 (640x480) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 *Mode: 52 (800x600) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 54 (1024x768) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 56 (1024x600) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 4096 XResolution: 1024 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 58 (1280x1024) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5a (1600x1200) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 6400 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 6400 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 Mode: 5c (1920x1440) ModeAttributes: 0x9a WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0006f3a BytesPerScanline: 7680 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xe8000000 LinBytesPerScanLine: 7680 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 230000000 (II) I810(0): Monitor gen?rico: Using hsync range of 28.00-49.00 kHz (II) I810(0): Monitor gen?rico: Using vrefresh range of 43.00-72.00 Hz (II) I810(0): Not using mode "1024x768" (no mode of this name) (II) I810(0): Increasing the scanline pitch to allow tiling mode (800 -> 1024). (--) I810(0): Virtual size is 800x600 (pitch 1024) (**) I810(0): Built-in mode "800x600" (**) I810(0): Built-in mode "640x480" (++) I810(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules/libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/lib/xorg/modules/libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/lib/xorg/modules/libramdac.so (II) Module ramdac: vendor="X.Org Foundation" compiled for 7.1.1, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.0 (==) I810(0): VBE Restore workaround: enabled. (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/lib/xorg/modules/libshadow.so (II) Module shadow: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 ABI class: X.Org ANSI C Emulation, version 0.3 (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 1 0 0xe0000000 - 0xe007ffff (0x80000) MS[B] [1] 1 0 0xe8000000 - 0xefffffff (0x8000000) MS[B] [2] -1 0 0x00100000 - 0x31ffffff (0x31f00000) MX[B]E(B) [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [6] -1 0 0xe0200000 - 0xe0200fff (0x1000) MX[B] [7] -1 0 0xe0100800 - 0xe01008ff (0x100) MX[B] [8] -1 0 0xe0100c00 - 0xe0100dff (0x200) MX[B] [9] -1 0 0x32000000 - 0x320003ff (0x400) MX[B] [10] -1 0 0xe0100000 - 0xe01003ff (0x400) MX[B] [11] -1 0 0xe0080000 - 0xe00fffff (0x80000) MX[B](B) [12] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B) [13] -1 0 0xe0000000 - 0xe007ffff (0x80000) MX[B](B) [14] -1 0 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [15] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [16] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [17] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [18] 1 0 0x00001800 - 0x00001807 (0x8) IS[B] [19] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [20] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [21] -1 0 0x00003000 - 0x0000303f (0x40) IX[B] [22] -1 0 0x00002000 - 0x0000207f (0x80) IX[B] [23] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [24] -1 0 0x00001880 - 0x000018bf (0x40) IX[B] [25] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B] [26] -1 0 0x00001600 - 0x0000161f (0x20) IX[B] [27] -1 0 0x00001810 - 0x0000181f (0x10) IX[B] [28] -1 0 0x00001840 - 0x0000185f (0x20) IX[B] [29] -1 0 0x00001820 - 0x0000183f (0x20) IX[B] [30] -1 0 0x00001800 - 0x00001807 (0x8) IX[B](B) [31] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [32] 1 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) I810(0): initializing int10 (II) I810(0): Primary V_BIOS segment is: 0xc000 (II) I810(0): VESA BIOS detected (II) I810(0): VESA VBE Version 3.0 (II) I810(0): VESA VBE Total Mem: 8000 kB (II) I810(0): VESA VBE OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Allocated 128 kB for the ring buffer at 0x0 (II) I810(0): Allocating at least 512 scanlines for pixmap cache (II) I810(0): Initial framebuffer allocation size: 5248 kByte (II) I810(0): Allocated 4 kB for HW cursor at 0x7fff000 (0x18bbb000) (II) I810(0): Allocated 16 kB for HW (ARGB) cursor at 0x7ffb000 (0x185ec000) (II) I810(0): Allocated 4 kB for Overlay registers at 0x7ffa000 (0x18b95000). (II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fea000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) I810(0): [drm] loaded kernel module for "i915" driver (II) I810(0): [drm] DRM interface version 1.2 (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) I810(0): [drm] added 8192 byte SAREA at 0xe0380000 (II) I810(0): [drm] mapped SAREA 0xe0380000 to 0xb7a7a000 (II) I810(0): [drm] framebuffer handle = 0xe8020000 (II) I810(0): [drm] added 1 reserved context for kernel (II) I810(0): Allocated 32 kB for the logical context at 0x7fe2000. (II) I810(0): Allocated 2432 kB for the back buffer at 0x7800000. (II) I810(0): Allocated 2432 kB for the depth buffer at 0x7400000. (II) I810(0): Allocated 55040 kB for textures at 0x540000 (II) I810(0): 0x81fd6f0: Memory at offset 0x00020000, size 5248 kBytes (II) I810(0): 0x81fe558: Memory at offset 0x07fff000, size 4 kBytes (II) I810(0): 0x81fe7d8: Memory at offset 0x07ffb000, size 16 kBytes (II) I810(0): 0x81fe73c: Memory at offset 0x00000000, size 128 kBytes (II) I810(0): 0x81fd730: Memory at offset 0x07fea000, size 64 kBytes (II) I810(0): 0x81fea28: Memory at offset 0x07ffa000, size 4 kBytes (II) I810(0): 0x81fd8c8: Memory at offset 0x07fe2000, size 32 kBytes (II) I810(0): 0x81fd8e8: Memory at offset 0x07800000, size 2432 kBytes (II) I810(0): 0x81fd908: Memory at offset 0x07400000, size 2432 kBytes (II) I810(0): 0x81fd928: Memory at offset 0x00540000, size 55040 kBytes (II) I810(0): Activating tiled memory for the back buffer. (II) I810(0): Activating tiled memory for the depth buffer. (II) I810(0): [drm] Registers = 0xe0000000 (II) I810(0): [drm] ring buffer = 0xe8000000 (II) I810(0): [drm] init sarea width,height = 800 x 600 (pitch 1024) (II) I810(0): [drm] Mapping front buffer (II) I810(0): [drm] Front Buffer = 0xe8020000 (II) I810(0): [drm] Back Buffer = 0xef800000 (II) I810(0): [drm] Depth Buffer = 0xef400000 (II) I810(0): [drm] textures = 0xe8540000 (II) I810(0): [drm] Initialized kernel agp heap manager, 56360960 (II) I810(0): [dri] visual configs initialized (==) I810(0): Write-combining range (0xe8000000,0x8000000) (II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (WW) I810(0): Extended BIOS function 0x5f05 failed. (II) I810(0): xf86BindGARTMemory: bind key 7 at 0x007df000 (pgoffset 2015) (II) I810(0): xf86BindGARTMemory: bind key 0 at 0x07fff000 (pgoffset 32767) (II) I810(0): xf86BindGARTMemory: bind key 1 at 0x07ffb000 (pgoffset 32763) (II) I810(0): xf86BindGARTMemory: bind key 3 at 0x07fea000 (pgoffset 32746) (II) I810(0): xf86BindGARTMemory: bind key 2 at 0x07ffa000 (pgoffset 32762) (II) I810(0): xf86BindGARTMemory: bind key 4 at 0x07fe2000 (pgoffset 32738) (II) I810(0): xf86BindGARTMemory: bind key 5 at 0x07800000 (pgoffset 30720) (II) I810(0): xf86BindGARTMemory: bind key 6 at 0x07400000 (pgoffset 29696) (--) I810(0): A non-CRT device is attached to pipe B. No refresh rate overrides will be attempted. (II) I810(0): Display plane A is disabled and connected to Pipe A. (II) I810(0): Display plane B is enabled and connected to Pipe B. (II) I810(0): Enabling plane B. (II) I810(0): Display plane A is now disabled and connected to Pipe A. (II) I810(0): Display plane B is now enabled and connected to Pipe B. (II) I810(0): PIPEACONF is 0x80000000 (II) I810(0): PIPEBCONF is 0x80000000 (II) I810(0): Mode bandwidth is 28 Mpixel/s (II) I810(0): maxBandwidth is 760 Mbyte/s, pipe bandwidths are 156 Mbyte/s, 0 Mbyte/s (II) I810(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Horizontal and Vertical Lines Offscreen Pixmaps Setting up tile and stipple cache: 16 128x128 slots 4 256x256 slots (==) I810(0): Backing store disabled (==) I810(0): Silken mouse enabled (II) I810(0): Initializing HW Cursor (**) Option "dpms" (**) I810(0): DPMS enabled (II) I810(0): Set up overlay video (II) I810(0): X context handle = 0x1 (II) I810(0): [drm] installed DRM signal handler (II) I810(0): [DRI] installation complete (II) I810(0): [drm] dma control initialized, using IRQ 11 (II) I810(0): direct rendering: Enabled (II) I810(0): RandR enabled, ignore the following RandR disabled message. (II) I810(0): Rotating to 0 degrees (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 (WW) AIGLX: 3D driver claims to not support visual 0x25 (WW) AIGLX: 3D driver claims to not support visual 0x26 (WW) AIGLX: 3D driver claims to not support visual 0x27 (WW) AIGLX: 3D driver claims to not support visual 0x28 (WW) AIGLX: 3D driver claims to not support visual 0x29 (WW) AIGLX: 3D driver claims to not support visual 0x2a (WW) AIGLX: 3D driver claims to not support visual 0x2b (WW) AIGLX: 3D driver claims to not support visual 0x2c (WW) AIGLX: 3D driver claims to not support visual 0x2d (WW) AIGLX: 3D driver claims to not support visual 0x2e (WW) AIGLX: 3D driver claims to not support visual 0x2f (WW) AIGLX: 3D driver claims to not support visual 0x30 (WW) AIGLX: 3D driver claims to not support visual 0x31 (WW) AIGLX: 3D driver claims to not support visual 0x32 (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so (II) GLX: Initialized DRI GL provider for screen 0 (**) Option "CoreKeyboard" (**) Generic Keyboard: Core Keyboard (**) Option "Protocol" "standard" (**) Generic Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Generic Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc104" (**) Generic Keyboard: XkbModel: "pc104" (**) Option "XkbLayout" "us" (**) Generic Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Generic Keyboard: CustomKeycodes disabled (**) Option "Protocol" "ImPS/2" (**) Configured Mouse: Device: "/dev/input/mice" (**) Configured Mouse: Protocol: "ImPS/2" (**) Option "CorePointer" (**) Configured Mouse: Core Pointer (**) Option "Device" "/dev/input/mice" (**) Option "Emulate3Buttons" "true" (**) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 (**) Configured Mouse: Buttons: 9 (II) Synaptics touchpad driver version 0.14.6 (1406) (--) Synaptics Touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3" (**) Option "HorizScrollDelta" "0" (--) Synaptics Touchpad touchpad found (**) Option "SendCoreEvents" "true" (**) Synaptics Touchpad: always reports core events (II) XINPUT: Adding extended input device "Synaptics Touchpad" (type: MOUSE) (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD) xkb_keycodes { include "xfree86+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compatibility { include "complete" }; xkb_symbols { include "pc(pc105)+us" }; xkb_geometry { include "pc(pc104)" }; Synaptics DeviceInit called SynapticsCtrl called. (II) Configured Mouse: ps2EnableDataReporting: succeeded Synaptics DeviceOn called (--) Synaptics Touchpad auto-dev sets device to /dev/input/event3 (**) Option "Device" "/dev/input/event3" (--) Synaptics Touchpad touchpad found ProcXCloseDevice to close or not ? From daniel.naughton at gmail.com Wed Dec 12 14:36:39 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Wed, 12 Dec 2007 16:36:39 -0600 Subject: intel driver with ADD2 card - getting dual independent displays working Message-ID: I've been at this for a few hours, I have both DVIs from the ADD2 card working in clone mode, but I can't get them to work independently. There is one snippet in the Xorg.0.log file that looks suspicious: (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TMDS-2 is connected to pipe A (II) intel(0): Output TV is connected to pipe none I think I want it to say : Output TMDS-2 is connected to pipe B I can't find anything anywhere that says what TMDS-1,2 are. I was assuming in was SDVO 1&2 from the ADD2 card. I think that's all that's left. My motherboard has has the 945GM on it with VGA,LVDS,TV and the two SDVO outputs. I think I shut off the VGA and LVDS screens with the "bogus" screen section. xorg.conf for reference: # Xorg configuration Section "ServerLayout" Identifier "Default layout" InputDevice "Keyboard0" "CoreKeyboard" Screen 0 "Screen0" Screen 1 "Screen1" Option "Xinerama" "on" Option "Clone" "off" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us+inet" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Envision" ModelName "LCD Panel 1440x900" HorizSync 31.5 - 56.0 VertRefresh 56.0 - 65.0 Option "dpms" Option "RightOf" "Monitor0" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Envision" ModelName "LCD Panel 1440x900" HorizSync 31.5 - 56.0 VertRefresh 56.0 - 65.0 Option "dpms" EndSection Section "Monitor" Identifier "LVDS Interface" Option "ignore" "true" EndSection Section "Monitor" Identifier "VGA Interface" Option "ignore" "true" EndSection Section "Device" Identifier "Intel 945GM" Driver "intel" Option "monitor-TMDS-0" "Monitor0" Option "monitor-TDMS-1" "Monitor1" Option "monitor-LVDS" "LVDS Interface" Option "monitor-VGA" "VGA Interface" # Option "MonitorLayout" "DFP,DFP2" # This options is in the docs, but gets ignored in the log files. # Valid monitors are CRT, LFP, DFP, TV, CRT2, LFP2, DFP2, TV2 and NONE. EndSection Section "Screen" Identifier "Screen0" Monitor "Monitor0" Device "Intel 945GM" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Intel 945GM" Monitor "Monitor1" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection From mrmazda at ij.net Wed Dec 12 15:06:24 2007 From: mrmazda at ij.net (Felix Miata) Date: Wed, 12 Dec 2007 18:06:24 -0500 Subject: Resolution problem with i810 In-Reply-To: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> Message-ID: <47606970.2020601@ij.net> On 2007/12/13 17:48 (GMT+1930) Rafael Mej?as apparently typed: > Hi. I'm having a problem. I own a Gateway Laptop Computer M305S with > an Intel 82852/855GM Integrated Graphics Card. I'm using Debian Etch > with 2.6.18-5-686 Kernel and I can't get a resolution bigger than > 800x600 (I know that it works with at least 1024x768 resolution on > WinXp). > I'd really like to know what do I need to do in order to get a higher > resolution: > Do I need > - a newer kernel? > - a newer xserver-xorg? > - new drivers for my card? > - all of the above? > - more than the above? > - a new computer??? > I've found little documentation on the Internet about this exact > problem. Some say that I need to perform so many steps that is better > to forget it... I've even tried a Debian Lenny Live CD with better > results but I was not able to install it on my laptop. > Is it possible to achieve 1024x768 without having to install a new system? 97%+ probability you only need an adjustment or two or three in /etc/X11/xorg.conf. Intel is often a problem to get set up initially, for various reasons, but generally works fine once configured. I have Etch and Kubuntu and more running on i815 video, and Kubuntu, Mandriva & OpenSUSE on i845G. HorizSync looks suspiciously low to me, so I suspect you might be able to get 1024x768 by merely changing HorizSync 28-49 to HorizSync 28-75 If that fails to get the job done, try switching in Section "Device" from Driver "i810" to Driver "intel" If that fails, try adding to Section "Device": Option "NoDDC" If it doesn't help, remove it, and check for a motherboard BIOS upgrade. If none of the above works, try grafting in the complete sections of the following from xorg.conf from a Lenny boot: Section "Device" Section "Monitor" Section "Screen" >From Section "Screen" you can safely omit all subsections except those for the DefaultDepth. Nothing in Section "Files" is relevant either, so that can be left out if you need to paste again. > Here's is my xorg.conf and the log (sorry; they're very long but I'm desperate): If you have any personal web space, better to put there and just include a link in the email. Don't forget to back up xorg.conf before changing it. -- " Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other." John Adams Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From elupus at ecce.se Wed Dec 12 14:52:54 2007 From: elupus at ecce.se (elupus) Date: Wed, 12 Dec 2007 23:52:54 +0100 Subject: Intel driver problem with TV output References: <4752CC21.8090701@fascinationsoftware.com> Message-ID: <17l19tc5mo24c.1c1ztfmhbwh9z$.dlg@40tude.net> On Sun, 02 Dec 2007 10:15:45 -0500, Richard Goedeken wrote: > Hello, > > I am setting up an HTPC using an AOpen MiniPC (GM965 chipset, X3100 accelerator) loaded with Fedora 8 and I'm having > numerous problems with the video drivers. The major problem is that I can't get the TV output working. I have tried > with both the current software in the Fedora 8 repository (xorg server 1.3.0.0-33.fc8 and xorg-drv-i810 2.1.1-7.fc8) and > the latest in the Fedora 9 (rawhide) repository (xorg server 1.4.99.1-0.10.fc9 and xorg-drv-i810 2.2.0-1.fc9). I have > attached the config and log files from the Fedora 8 setup. > > As far as I can tell, everything in the log files look good. Compiz is disabled. I can even drag windows off the > desktop to the right (where the TV screen should be) and can move them totally off the screen, but the TV display is > always blank. I've tried both the composite and component outputs. I know the electrical path is good because the TV > flashes when starting the X server (with the newer drivers). > > At one point when I was loading and bringing up the new drivers, I had booted in init level 3 (text only) and did a > 'telinit 5' to bring up X, and I actually got a cursor on the TV. But there was only the cursor on the TV (with a small > Fedora blue dot animation) and the main CRT monitor was blank, so I couldn't log in. I restarted the X server and then > lost the cursor display on the TV. I was unable to replicate this condition. > > Has anyone been successful getting TV output to work on this chipset/hardware? > > There are other major bugs that I've found as well. Is there a Bugzilla server where I can log these? In particular: > 1. With the F9 (rawhide) drivers, the monitor goes into power-save mode when switching to a text VT. Switching back to > X gives a blank screen (monitor powers up though), and requires an X restart or reboot to bring the display back. > 2. With the F8 drivers, switching to a text VT works fine, but sometimes when switching back to X the screen is blank. > After switching back and forth several times the graphical display will appear correctly, without having to restart X. > > Thanks, > Richard Hi, I'm having the exact same issue on Ubuntu gutsy and hardy with the same AOpen Mini PC. Hardy uses the 2.2.0 tag. Which should include those fixes. Video comes on during boot on TV if nothing else is connected, but as soon as the x drivers init, screen turns of. According to log, everything seem to have gone allright, and X has been started, but as said, there is no output on the SVIDEO/COMPOSITE or COMPONENT outputs. Some friends of mines have been able to get the exact same type of Mini PC to display with ubuntu gutsy. I've tried with exact same drivers/xorg.conf with not luck. One potential issue could be that this system have been booted with windows on it, so maybe it has changes something in the display driver. I've supplied xorg.conf, log and xrandr outuput. Hopefully this could give somebody an idea The fix for ignoring the LVDS output on these mainboards doesn't seem to be working either. It's still listed by xrandr if you don't ignore it in xorg.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 2426 bytes Desc: Attached file: xorg.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.log Type: application/octet-stream Size: 30897 bytes Desc: Attached file: Xorg.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xrandr.log Type: application/octet-stream Size: 1477 bytes Desc: Attached file: xrandr.log URL: From dkasak at nusconsulting.com.au Wed Dec 12 15:13:33 2007 From: dkasak at nusconsulting.com.au (Daniel Kasak) Date: Thu, 13 Dec 2007 10:13:33 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712121249.36811.saschahlusiak@arcor.de> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> <200712121249.36811.saschahlusiak@arcor.de> Message-ID: <1197501213.9989.9.camel@dkasak.nusconsulting.com.au> On Wed, 2007-12-12 at 12:49 +0100, Sascha Hlusiak wrote: > Am Mittwoch 12 Dezember 2007 12:01:55 schrieb Thomas Ilnseher: > > I was using 2.2.0 on gentoo (GL960 Chipset), and noticed that teh 2D > > performance under compiz-fusion REALLY sucked! (ie. pingus running with > > 14fps, scrolling in FF feels slow). Reverted to 2.1.1 and everything > > seems fine again. > That's probably because of the default acceleration method moved from XAA to > EXA. Try to move back to XAA (option "AccelMethod") and you should have > performance as before. Oh! If it were only that easy. XAA is broken in 2.2.0. From memory, I get an instant lockup when starting compiz with XAA. The word at the time was that XAA isn't really going to get any further attention, and we should get used to EXA. Unfortunately that means absolutely horrendous performance on my chip ( 845G ). I've set the "EXANoComposite" option in my device section, and that helps a really tiny little bit, but obviously I'm still complaining :) I suppose this means I support the recommendation that people with chips like mine hold off on updating to 2.2.0, which may very be better 'under the hood' than 2.1.1, but from an end user's point of view, it really only means a huge performance hit. As for the stability side of things, I must admit it's been rock solid, other than the very occasional lockup when hibernating. I don't use XV though - this is a work PC. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: dkasak at nusconsulting.com.au website: http://www.nusconsulting.com.au From jbarnes at virtuousgeek.org Wed Dec 12 09:24:00 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 12 Dec 2007 09:24:00 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <475FC515.20701@gentoo.org> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> <475FC515.20701@gentoo.org> Message-ID: <200712120924.00676.jbarnes@virtuousgeek.org> On Wednesday, December 12, 2007 3:25 am R?mi Cardona wrote: > Thomas Ilnseher a ?crit : > > I was using 2.2.0 on gentoo (GL960 Chipset), and noticed that teh 2D > > performance under compiz-fusion REALLY sucked! (ie. pingus running with > > 14fps, scrolling in FF feels slow). Reverted to 2.1.1 and everything > > seems fine again. > > > > I would recommend everyone to avoid 2.2.0 ! > > > > Tom > > Well, I'm really thinking about masking 2.2.0 in portage for the time > being, as it's creating more problems for users than it is solving. > > > @Intel developpers: > > As the new maintainer for this driver in Gentoo, could I humbly ask you > guys try to push out more releases, even if they are alpha/beta and > clearly marked as such (2.x.9[0-9]) so that we can provide better feedback? I'm working on a 2.2.1 release now to address these types of problems. The only Xv related change I can think of was to avoid crashes on some machines where if you used Xv and exited the server you'd get a crash; I can't think of anything else that would cause the problem you're seeing. Is there a bug filed? Jesse From joeprogrammer70 at gmail.com Wed Dec 12 17:18:52 2007 From: joeprogrammer70 at gmail.com (Joseph Alten) Date: Wed, 12 Dec 2007 17:18:52 -0800 Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem In-Reply-To: <788431.70015.qm@web43134.mail.sp1.yahoo.com> References: <788431.70015.qm@web43134.mail.sp1.yahoo.com> Message-ID: On 11-Dec-07, at 10:52 AM, Cry Regarder wrote: > Good luck. I still get this with the intel driver. > What I find is that I just have to try and start X a > billion times and then sooner or later, sometimes a > day later, it will just work. This monitor is > extraordinarily frustrating. Never buy a 2407FPW. > I've tried every option I could think of or find on > the web. Well, for me it's been fairly reliable -- either my configuration works, or it doesn't. :-) But my only question now is, how do I set the resolution through the xorg.conf file? Obviously it shouldn't be too hard, given that the only command I have to run to set it at runtime is 'xrandr --output TMDS-1 --mode 1920x1200'. IMHO, the old Intel driver configuration seemed much simpler, when there was a screen section for each monitor and you just set it with 'modes'. But whatever. Joe From rafaelmejiasc at gmail.com Wed Dec 12 17:36:23 2007 From: rafaelmejiasc at gmail.com (=?ISO-8859-1?Q?Rafael_Mej=EDas?=) Date: Thu, 13 Dec 2007 21:06:23 +1930 Subject: Resolution problem with i810 In-Reply-To: <47606970.2020601@ij.net> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> <47606970.2020601@ij.net> Message-ID: <2f96467a0712121736y78c6fd08l82b860b7cefd682d@mail.gmail.com> Hi. Thanks for the answer. I did all the changes in xorg.conf and restarted gdm with the following results: > HorizSync 28-49 > to > HorizSync 28-75 nothing weird happened, Same resolution (800x600) > Driver "i810" > to > Driver "intel" gdm did not start. The log said I don't have the "intel" driver installed. Fixed it with the "i810" driver again and restarted gdm. Back to the old 800x600... > If that fails, try adding to Section "Device": > > Option "NoDDC" and still nothing... > If it doesn't help, remove it, and check for a motherboard BIOS upgrade. I just downloaded the latest available bios from www.gateway.com and installed it. And still nothing... > If none of the above works, try grafting in the complete sections of the > following from xorg.conf from a Lenny boot: > > Section "Device" > Section "Monitor" > Section "Screen" Here it goes: I copied these sections to my xorg.conf and restarted gdm. And guess what! 800x600 again... ****************************************************** #From Debian Lenny: Section "Device" Identifier "Intel Corporation 82852/855GM Integrated Graphics Device" Driver "i810" BusID "PCI:0:2:0" EndSection Section "Monitor" Identifier "Generic Monitor" Option "DPMS" HorizSync 30-70 VertRefresh 50-160 EndSection Section "Screen" Identifier "Default Screen" Device "Intel Corporation 82852/855GM Integrated Graphics Device" Monitor "Generic Monitor" DefaultDepth 24 EndSection ****************************************************** I believe I have to compile stuff :-( but have no idea where to start. I would not like to install a lot of packages that won't work in the end... Please help... :'''( From jbarnes at virtuousgeek.org Wed Dec 12 14:59:41 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 12 Dec 2007 14:59:41 -0800 Subject: Resolution problem with i810 In-Reply-To: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> Message-ID: <200712121459.41978.jbarnes@virtuousgeek.org> On Wednesday, December 12, 2007 2:18 Rafael Mej?as wrote: > Hi. I'm having a problem. I own a Gateway Laptop Computer M305S with > an Intel 82852/855GM Integrated Graphics Card. I'm using Debian Etch > with 2.6.18-5-686 Kernel and I can't get a resolution bigger than > 800x600 (I know that it works with at least 1024x768 resolution on > WinXp). > > I'd really like to know what do I need to do in order to get a higher > resolution: > > Do I need > - a newer kernel? > - a newer xserver-xorg? > - new drivers for my card? > - all of the above? > - more than the above? > - a new computer??? > > I've found little documentation on the Internet about this exact > problem. Some say that I need to perform so many steps that is better > to forget it... I've even tried a Debian Lenny Live CD with better > results but I was not able to install it on my laptop. > > Is it possible to achieve 1024x768 without having to install a new > system? > (II) LoadModule: "i810" > (II) Loading /usr/lib/xorg/modules/drivers/i810_drv.so > (II) Module i810: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.7.2 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 1.0 Well, you're using the 1.7.2 version of the Intel driver, so you'll be at the mercy of your video BIOS as far as mode setting is concerned. > (II) Reloading /usr/lib/xorg/modules/libddc.so > (II) I810(0): VESA VBE DDC supported > (II) I810(0): VESA VBE DDC Level none > (II) I810(0): VESA VBE DDC transfer in appr. 0 sec. > (II) I810(0): VESA VBE DDC read failed > (--) I810(0): A non-CRT device is attached to pipe B. > No refresh rate overrides will be attempted. > (--) I810(0): Maximum space available for video modes: 12288 kByte [snip mode list] What's weird is that a 1024x768 mode seems to be in your available mode list, but isn't being made available somehow. So you could either try using something like i915resolution to reprogram your 1024x768 mode into something that might work on your LCD or you could upgrade to a newer Intel driver that will program the mode natively, as well as controlling all the video outputs on your machine dynamically... Jesse From cry_regarder at yahoo.com Wed Dec 12 22:03:22 2007 From: cry_regarder at yahoo.com (Cry Regarder) Date: Wed, 12 Dec 2007 22:03:22 -0800 (PST) Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem Message-ID: <931350.35953.qm@web43135.mail.sp1.yahoo.com> From: Joseph Alten > works, or it doesn't. :-) But my only question now is, how do I set > the resolution through the xorg.conf file? Obviously it shouldn't be > too hard, given that the only command I have to run to set it at > runtime is 'xrandr --output TMDS-1 --mode 1920x1200'. IMHO, the old > Intel driver configuration seemed much simpler, when there was a > screen section for each monitor and you just set it with 'modes'. But > whatever. works or doesn't...not my experience. Two months later it stopped working again...and then three days later, it spontaneously started working again. Anywho, here is the xorg that lets you control the resolution: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "Device" Identifier "Videocard0" Driver "intel" Option "monitor-TMDS-2" "left" Option "monitor-TMDS-1" "right" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "right" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 3840 1200 EndSubSection EndSection Section "Monitor" Identifier "left" Option "PreferredMode" "1920x1200" Option "Position" "0 0" EndSection Section "Monitor" Identifier "right" Option "PreferredMode" "1920x1200" Option "Position" "1920 0" EndSection Joe _______________________________________________ xorg mailing list xorg at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg From thep at linux.thai.net Wed Dec 12 22:10:28 2007 From: thep at linux.thai.net (Theppitak Karoonboonyanan) Date: Thu, 13 Dec 2007 13:10:28 +0700 Subject: [PATCH] NumLock/CapsLock masks in Thai XIM In-Reply-To: <200712121642.lBCGg0d35004@xanth.austin.ibm.com> References: <200712121642.lBCGg0d35004@xanth.austin.ibm.com> Message-ID: <20071213061028.GA25121@cedar> On Wed, Dec 12, 2007 at 10:42:00AM -0600, mcnichol at austin.ibm.com wrote: > The patch assumes that NumLock is always mapped to Mod2. > That may not be true on all systems. I know AIX uses Mod5. Mod5 is mapped for AltGr on Linux. And it should also be passed to the XIM, like NumLock. So, it should be OK to add Mod5Mask to the list as well. However, is this assumption reliable? In summary, the masks that should be passed to the sequence checking routine are Shift, CapsLock, NumLock, and AltGr. And the known mappings are: bin. Macro Linux AIX Operation ---- ----------- --------- -------- --------- 0x01 ShiftMask Shift Shift Pass 0x02 LockMask CapsLock CapsLock Pass 0x04 ControlMask Ctrl Ctrl Block 0x08 Mod1Mask Alt Alt(?) Block 0x10 Mod2Mask NumLock ? Pass(?) 0x20 Mod3Mask ? ? ? 0x40 Mod4Mask Win ? Block(?) 0x80 Mod5Mask AltGr NumLock Pass Or is there more reliable way to handle this? Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From remi at gentoo.org Wed Dec 12 22:44:49 2007 From: remi at gentoo.org (=?ISO-8859-1?Q?R=E9mi_Cardona?=) Date: Thu, 13 Dec 2007 07:44:49 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712120924.00676.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> <475FC515.20701@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> Message-ID: <4760D4E1.3060900@gentoo.org> Jesse Barnes wrote: > I'm working on a 2.2.1 release now to address these types of problems. The > only Xv related change I can think of was to avoid crashes on some machines > where if you used Xv and exited the server you'd get a crash; I can't think > of anything else that would cause the problem you're seeing. Is there a bug > filed? Willi Mann pointed out bug #13108, and it looks very similar. Unfortunately, it's not marked as fixed and there's no reference to a patch either in xf86-video-intel nor xorg-server for me to try. Cheers -- R?mi Cardona LRI, Universit? Paris-Sud remi.cardona at lri.fr remi at gentoo.org From mrmazda at ij.net Wed Dec 12 23:10:31 2007 From: mrmazda at ij.net (Felix Miata) Date: Thu, 13 Dec 2007 02:10:31 -0500 Subject: Resolution problem with i810 In-Reply-To: <2f96467a0712121736y78c6fd08l82b860b7cefd682d@mail.gmail.com> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> <47606970.2020601@ij.net> <2f96467a0712121736y78c6fd08l82b860b7cefd682d@mail.gmail.com> Message-ID: <4760DAE7.1050701@ij.net> On 2007/12/13 21:06 (GMT+1930) Rafael Mej?as apparently typed: > Please help... :'''( Here's a suggestion I forgot, maybe because your xorg and/or driver version might not be new enough for it to be valid. In Section "Monitor" try adding: Option "PreferredMode" "1024x768" Asking on a Debian mailing list might provide more help. Looking in its bug tracker might be useful too. Another thing to try is the xorg.conf generated by an Edgy or Feisty live CD. -- " Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other." John Adams Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From thep at linux.thai.net Wed Dec 12 23:16:57 2007 From: thep at linux.thai.net (Theppitak Karoonboonyanan) Date: Thu, 13 Dec 2007 14:16:57 +0700 Subject: [PATCH] NumLock/CapsLock masks in Thai XIM In-Reply-To: <20071213061028.GA25121@cedar> References: <200712121642.lBCGg0d35004@xanth.austin.ibm.com> <20071213061028.GA25121@cedar> Message-ID: <75bffeb70712122316s638de826l19699e2315d89c23@mail.gmail.com> On Dec 13, 2007 1:10 PM, Theppitak Karoonboonyanan wrote: > Mod5 is mapped for AltGr on Linux. And it should also be passed to the XIM, > like NumLock. So, it should be OK to add Mod5Mask to the list as well. > > However, is this assumption reliable? In summary, the masks that should > be passed to the sequence checking routine are Shift, CapsLock, NumLock, > and AltGr. And the known mappings are: > > bin. Macro Linux AIX Operation > ---- ----------- --------- -------- --------- > 0x01 ShiftMask Shift Shift Pass > 0x02 LockMask CapsLock CapsLock Pass > 0x04 ControlMask Ctrl Ctrl Block > 0x08 Mod1Mask Alt Alt(?) Block > 0x10 Mod2Mask NumLock ? Pass(?) > 0x20 Mod3Mask ? ? ? > 0x40 Mod4Mask Win ? Block(?) > 0x80 Mod5Mask AltGr NumLock Pass Instead of listing what's to be excluded from the masks, I list what's to be included instead. So, we now specify that we need to block Control, Mod1/Alt, Mod4/Win modifiers from entering the sequence checking routine. -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 023_thai-im-filter.diff Type: text/x-patch Size: 662 bytes Desc: not available URL: From mailinglists at who-t.net Wed Dec 12 23:23:19 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Thu, 13 Dec 2007 17:53:19 +1030 Subject: Multi Pointer X MPX Build problem In-Reply-To: <001301c83cef$b4007bc0$15b2a8c0@fuckup> References: <001301c83cef$b4007bc0$15b2a8c0@fuckup> Message-ID: <4760DDE7.60006@who-t.net> Nikolas D?rfler wrote: > gcc -DHAVE_DIX_CONFIG_H -DNO_HW_ONLY_EXTS -DNO_MODULE_EXTS -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/tmp/modular//include -I/tmp/modular//include/pixman-1 -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -g -O2 -o Xvfb InitInput.o InitOutput.o dpmsstubs.o stubs.o miinitext.o ../../fb/.libs/libfb.a ../../xfixes/.libs/libxfixes.a ../../Xext/.libs/libXext.a ../../dbe/.libs/libdbe.a ../../XTrap/.libs/libxtrap.a ../../record/.libs/librecord.a ../../GL/glx/.libs/libglx.a ../../GL/mesa/.libs/libGLcore.a ../../render/.libs/librender.a ../../randr/.libs/librand r. > a ../../damageext/.libs/libdamageext.a ../../miext/damage/.libs/libdamage.a ../../miext/shadow/.libs/libshadow.a ../../Xi/.libs/libXi.a ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a ../../composite/.libs/libcomposite.a ../../dix/.libs/libxpstubs.a ../../os/.libs/libcwrapper.a libfbcmap.a ../../dix/.libs/libdix.a ../../config/libconfig.a ../../mi/.libs/libmi.a ../../os/.libs/libos.a -L/tmp/modular//lib -L/lib /tmp/modular//lib/libXfont.so /usr/lib/libfreetype.so /tmp/modular//lib/libXau.so /tmp/modular/lib/libfontenc.so -lz /tmp/modular/lib/libpixman-1.so /usr/lib/libhal.so /usr/lib/libusb.so -ldl -luuid -ldbus-1 /tmp/modular//lib/libXdmcp.so -lcrypto -lm -lrt -Wl,--rpath -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib -Wl,--rpath -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib > ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function `__glXDisp_ProgramParameter4fvNV': > /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5190: undefined reference to `CALL_ProgramParameter4fvNV' > ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function `__glXDisp_ProgramParameter4dvNV': > /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5181: undefined reference to `CALL_ProgramParameter4dvNV' > ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function `__glXDispSwap_ProgramParameter4fvNV': > /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5346: undefined reference to `CALL_ProgramParameter4fvNV' > ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function `__glXDispSwap_ProgramParameter4dvNV': > /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5337: undefined reference to `CALL_ProgramParameter4dvNV' tbh, I don't know if that is really an issue with MPX. I get the same error (I usually --disable-glx on configure). Not quite sure how to fix it, pulling master stuff now. If it happens there too, I'll have to defer to someone else :) Cheers, Peter From foss-ml at wm1.at Thu Dec 13 00:18:57 2007 From: foss-ml at wm1.at (Willi Mann) Date: Thu, 13 Dec 2007 09:18:57 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <475FB25B.8030709@wm1.at> References: <475F87D6.1040008@gentoo.org> <475FB25B.8030709@wm1.at> Message-ID: <4760EAF1.8070409@wm1.at> > https://bugs.freedesktop.org/show_bug.cgi?id=13108 > > Might actually be an xserver bug, that's fixed in xserver git. I haven't > tested yet. Testing today shows that it is not fixed, or at least upgrading to latest git of xserver and latest git of intel driver does not help. See the bug for more information. Willi From rglowery at exemail.com.au Thu Dec 13 00:33:46 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Thu, 13 Dec 2007 19:33:46 +1100 (EST) Subject: Intel driver problem with TV output Message-ID: <1693.220.233.174.242.1197534826.squirrel@webmail.exetel.com.au> > On Sun, 02 Dec 2007 10:15:45 -0500, Richard Goedeken wrote: > >> Hello, >> >> I am setting up an HTPC using an AOpen MiniPC (GM965 chipset, X3100 >> accelerator) loaded with Fedora 8 and I'm having >> numerous problems with the video drivers. The major problem is that I >> can't get the TV output working. I have tried >> with both the current software in the Fedora 8 repository (xorg server >> 1.3.0.0-33.fc8 and xorg-drv-i810 2.1.1-7.fc8) and >> the latest in the Fedora 9 (rawhide) repository (xorg server >> 1.4.99.1-0.10.fc9 and xorg-drv-i810 2.2.0-1.fc9). I have >> attached the config and log files from the Fedora 8 setup. >> >> As far as I can tell, everything in the log files look good. Compiz is >> disabled. I can even drag windows off the >> desktop to the right (where the TV screen should be) and can move them >> totally off the screen, but the TV display is >> always blank. I've tried both the composite and component outputs. I >> know the electrical path is good because the TV >> flashes when starting the X server (with the newer drivers). >> >> At one point when I was loading and bringing up the new drivers, I had >> booted in init level 3 (text only) and did a >> 'telinit 5' to bring up X, and I actually got a cursor on the TV. But >> there was only the cursor on the TV (with a small >> Fedora blue dot animation) and the main CRT monitor was blank, so I >> couldn't log in. I restarted the X server and then >> lost the cursor display on the TV. I was unable to replicate this >> condition. >> >> Has anyone been successful getting TV output to work on this >> chipset/hardware? >> >> There are other major bugs that I've found as well. Is there a Bugzilla >> server where I can log these? In particular: >> 1. With the F9 (rawhide) drivers, the monitor goes into power-save mode >> when switching to a text VT. Switching back to >> X gives a blank screen (monitor powers up though), and requires an X >> restart or reboot to bring the display back. >> 2. With the F8 drivers, switching to a text VT works fine, but sometimes >> when switching back to X the screen is blank. >> After switching back and forth several times the graphical display will >> appear correctly, without having to restart X. >> >> Thanks, >> Richard > > Hi, > > I'm having the exact same issue on Ubuntu gutsy and hardy with the same > AOpen Mini PC. Hardy uses the 2.2.0 tag. Which should include those fixes. > Video comes on during boot on TV if nothing else is connected, but as soon > as the x drivers init, screen turns of. > > According to log, everything seem to have gone allright, and X has been > started, but as said, there is no output on the SVIDEO/COMPOSITE or > COMPONENT outputs. > > Some friends of mines have been able to get the exact same type of Mini PC > to display with ubuntu gutsy. I've tried with exact same drivers/xorg.conf > with not luck. One potential issue could be that this system have been > booted with windows on it, so maybe it has changes something in the > display > driver. > > I've supplied xorg.conf, log and xrandr outuput. Hopefully this could give > somebody an idea > > The fix for ignoring the LVDS output on these mainboards doesn't seem to > be > working either. It's still listed by xrandr if you don't ignore it in > xorg.conf_______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg Your xorg.conf is much more complex than the one I am using with my AOpen MP965-DR (see attached) Note that TV output should be configured using xrandr, not xorg.conf. You will see in your xorg.log (WW) intel(0): Option "TV Format" is not used (WW) intel(0): Option "PreferredMode" is not used instead you should use a command such as xrandr --output TV --set TV_FORMAT=PAL --auto For the LVDS ignore issue, it would be worth checking with lspci that the relevant id's match the following quirk from i830_quirks.c { PCI_CHIP_I965_GM, 0x8086, 0x1999, quirk_ignore_lvds }, HTH -Rob From bve at gmx.de Thu Dec 13 02:52:31 2007 From: bve at gmx.de (Ben E. Hard) Date: Thu, 13 Dec 2007 11:52:31 +0100 Subject: Resolution problem with i810 In-Reply-To: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> Message-ID: <200712131152.31586.bve@gmx.de> Am Mittwoch, 12. Dezember 2007 schrieb Rafael Mej?as: > (II) I810(0): Not using mode "1024x768" (no mode of this name) Did you try with a default depth of 16? Greetings, Ben From daniel at fooishbar.org Thu Dec 13 02:58:16 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 13 Dec 2007 12:58:16 +0200 Subject: [PATCH] NumLock/CapsLock masks in Thai XIM In-Reply-To: <20071213061028.GA25121@cedar> References: <200712121642.lBCGg0d35004@xanth.austin.ibm.com> <20071213061028.GA25121@cedar> Message-ID: <20071213105816.GA28249@fooishbar.org> On Thu, Dec 13, 2007 at 01:10:28PM +0700, Theppitak Karoonboonyanan wrote: > On Wed, Dec 12, 2007 at 10:42:00AM -0600, mcnichol at austin.ibm.com wrote: > > The patch assumes that NumLock is always mapped to Mod2. > > That may not be true on all systems. I know AIX uses Mod5. > > Mod5 is mapped for AltGr on Linux. And it should also be passed to the XIM, > like NumLock. So, it should be OK to add Mod5Mask to the list as well. > > However, is this assumption reliable? In summary, the masks that should > be passed to the sequence checking routine are Shift, CapsLock, NumLock, > and AltGr. And the known mappings are: > > bin. Macro Linux AIX Operation > ---- ----------- --------- -------- --------- > 0x01 ShiftMask Shift Shift Pass > 0x02 LockMask CapsLock CapsLock Pass > 0x04 ControlMask Ctrl Ctrl Block > 0x08 Mod1Mask Alt Alt(?) Block > 0x10 Mod2Mask NumLock ? Pass(?) > 0x20 Mod3Mask ? ? ? > 0x40 Mod4Mask Win ? Block(?) > 0x80 Mod5Mask AltGr NumLock Pass > > Or is there more reliable way to handle this? The only way to really do this properly is to run XkbGetVirtualMods, IIRC. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From sameer at damagehead.com Thu Dec 13 03:06:47 2007 From: sameer at damagehead.com (Sameer Naik) Date: Thu, 13 Dec 2007 16:36:47 +0530 (IST) Subject: issue with display output Message-ID: <48657.208.97.187.133.1197544007.squirrel@mail.damagehead.com> hi, im using X Window System Version 7.2.0 Release Date: 22 January 2007 X Protocol Version 11, Revision 0, Release 7.2 the display im using is Samsung SyncMaster 940NW (flat panel), with the following specifications: pixel pitch : 0.285 horizontal freq : 30-81khz vertical freq : 56-75hz max. resolution : 1440x900 sync type : Separate H/V, Composite H/V, SOG from the max resolution i can tell that its a 16:10 screen aspect ratio display. i have the following modelines in my xorg.conf "720x480" 26.7 720 736 808 896 480 481 484 497 "720x576" 32.7 720 744 816 912 576 577 580 597 "800x480" 29.6 800 816 896 992 480 481 484 497 "848x480" 31.5 848 864 952 1056 480 481 484 497 "856x480" 31.7 856 872 960 1064 480 481 484 497 "1024x512" 41.3 1024 1056 1160 1296 512 513 516 531 "1280x720" 74.6 1280 1341 1474 1688 720 721 724 746 "1280x768" 87.04 1280 1376 1488 1800 768 771 777 806 -HSync +VSync "1280x800" 68.9 1280 1344 1368 1408 800 803 806 816 "1366x768" 85.86 1366 1440 1584 1800 768 769 772 795 -HSync +VSync "1400x1050" 122.61 1400 1488 1640 1880 1050 1051 1054 1087 of the above, the 1280x768 works great and everything appears on the screen just right. i want to open the xserver display at 1024x640 resolution, but i have no idea how to specify the Modeline for this resolution. i read the xorg.conf manual for the Modeline parameter, but i just did not get it. im going nuts trying to figure this out. please help. ::attached is my xorg.conf regards ~sameer -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 2654 bytes Desc: not available URL: From dparsons at debian.org Thu Dec 13 03:23:46 2007 From: dparsons at debian.org (Drew Parsons) Date: Thu, 13 Dec 2007 22:23:46 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712120924.00676.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> <475FC515.20701@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> Message-ID: <1197545026.17258.19.camel@localhost.localdomain> On Wed, 2007-12-12 at 09:24 -0800, Jesse Barnes wrote: > > I'm working on a 2.2.1 release now to address these types of problems. The > only Xv related change I can think of was to avoid crashes on some machines > where if you used Xv and exited the server you'd get a crash; I can't think > of anything else that would cause the problem you're seeing. Is there a bug > filed? Just commenting for the record, I've found that S3 suspend-to-ram is currently broken with intel 2.2.0, xserver 1.4.1, linux 2.6.23, mesa 7.0.2 on intel 82855 GME. Upon resume, the system freezes blank. It had reached successful operation recently with intel 2.1.0. I switched on the new kernel SUSPEND option which is supposed to help S3 suspend in kernel drivers. I think you've indicated this may be fixed in git, which I haven't had the chance to test yet, so I'm commenting just to mark the current status in the stable releases :) Drew From sroland at tungstengraphics.com Thu Dec 13 05:13:29 2007 From: sroland at tungstengraphics.com (Roland Scheidegger) Date: Thu, 13 Dec 2007 14:13:29 +0100 Subject: Multi Pointer X MPX Build problem In-Reply-To: <4760DDE7.60006@who-t.net> References: <001301c83cef$b4007bc0$15b2a8c0@fuckup> <4760DDE7.60006@who-t.net> Message-ID: <47612FF9.6030400@tungstengraphics.com> Peter Hutterer wrote: > Nikolas D?rfler wrote: >> gcc -DHAVE_DIX_CONFIG_H -DNO_HW_ONLY_EXTS -DNO_MODULE_EXTS >> -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes >> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs >> -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN >> -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE >> -I/tmp/modular//include -I/tmp/modular//include/pixman-1 >> -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 >> -I/usr/lib/dbus-1.0/include -I../../include -I../../include >> -I../../Xext -I../../composite -I../../damageext -I../../xfixes >> -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage >> -I../../render -I../../randr -I../../fb -g -O2 -o Xvfb InitInput.o >> InitOutput.o dpmsstubs.o stubs.o miinitext.o >> ../../fb/.libs/libfb.a ../../xfixes/.libs/libxfixes.a >> ../../Xext/.libs/libXext.a ../../dbe/.libs/libdbe.a >> ../../XTrap/.libs/libxtrap.a ../../record/.libs/librecord.a >> ../../GL/glx/.libs/libglx.a ../../GL/mesa/.libs/libGLcore.a >> ../../render/.libs/librender.a ../../randr/.libs/librand > r. >> a ../../damageext/.libs/libdamageext.a >> ../../miext/damage/.libs/libdamage.a >> ../../miext/shadow/.libs/libshadow.a ../../Xi/.libs/libXi.a >> ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a >> ../../composite/.libs/libcomposite.a ../../dix/.libs/libxpstubs.a >> ../../os/.libs/libcwrapper.a libfbcmap.a ../../dix/.libs/libdix.a >> ../../config/libconfig.a ../../mi/.libs/libmi.a >> ../../os/.libs/libos.a -L/tmp/modular//lib -L/lib >> /tmp/modular//lib/libXfont.so /usr/lib/libfreetype.so >> /tmp/modular//lib/libXau.so /tmp/modular/lib/libfontenc.so -lz >> /tmp/modular/lib/libpixman-1.so /usr/lib/libhal.so >> /usr/lib/libusb.so -ldl -luuid -ldbus-1 >> /tmp/modular//lib/libXdmcp.so -lcrypto -lm -lrt -Wl,--rpath >> -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib -Wl,--rpath >> -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib >> ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function >> `__glXDisp_ProgramParameter4fvNV': >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5190: >> undefined reference to `CALL_ProgramParameter4fvNV' >> ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function >> `__glXDisp_ProgramParameter4dvNV': >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5181: >> undefined reference to `CALL_ProgramParameter4dvNV' >> ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function >> `__glXDispSwap_ProgramParameter4fvNV': >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5346: >> undefined reference to `CALL_ProgramParameter4fvNV' >> ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function >> `__glXDispSwap_ProgramParameter4dvNV': >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5337: >> undefined reference to `CALL_ProgramParameter4dvNV' > > tbh, I don't know if that is really an issue with MPX. I get the same > error (I usually --disable-glx on configure). Not quite sure how to > fix it, pulling master stuff now. If it happens there too, I'll have > to defer to someone else :) > These CALL_ProgramParameter4xyNV functions no longer exist (due to changes which eliminated the corresponding gl functions, since they are identical to some ARB functions). Regenerating the server glx protocol (which was done for xserver master) from the mesa master branch (in the glapi directory) should probably fix this (or pull in the glx changes from xserver master). Roland From daniel.naughton at gmail.com Thu Dec 13 05:20:11 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Thu, 13 Dec 2007 07:20:11 -0600 Subject: intel driver for 945GM multihead question Message-ID: I can seem to find any documentation on this. I've tried the dualhead snippet on the intel website, but I keep getting TDMS-1 and TMDS-2 connecting to pipe A and the two displays cloned. The xrandr utility wouldn't work with the Xinerama on in the xorg.conf, but when I shut it off in the conf file, the xrandr utility doesn't seem to do much other than make the two displays flicker when you hit enter. My hardware spec says the output of the 945GM looks like this: ___________ | | | 945GM | |_________| | | | | | ____| | | | |___________ | _| | |___ | | | | | | | | | | | TV VGA LVDS TDMS-1 TDMS-2 (SDVO1?) (SDVO2?) The VGA works fine during bootup and for the console. I'm pretty sure I need to assign TDMS-1 to Pipe A and TDMS-2 to Pipe B, but I can't find anything in the documentation that seems to work. For example: *Option "MonitorLayout" "**anystr**"*Valid monitors are CRT, LFP, DFP, TV, CRT2, LFP2, DFP2, TV2 does nothing:( The log file always shows the following? (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TMDS-2 is connected to pipe A (II) intel(0): Output TV is connected to pipe none -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsun013 at gmail.com Thu Dec 13 05:23:42 2007 From: wsun013 at gmail.com (Wei-Tsun Sun) Date: Fri, 14 Dec 2007 02:23:42 +1300 Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today Message-ID: <20071214022342.0363050e@KNIGHT> Hi, I am not sure what could be the cause of the bug, therefore I would like to seek for some advice here first, then do a bug report once I understand why the bug would occur. I updated my xserver, xf86-video-ati today to the GIT HEAD, however, when I restarted my X seesion, besides programs written in GTK2 and QT4, the fonts are messed up. The following link is qtconfig for QT3 http://i215.photobucket.com/albums/cc312/wsun013/20071212-xorg/a.png Anyone have any idea what could be the cause of this bug so that I can do a correct bug report. Many thanks, Willie From SirRichard at fascinationsoftware.com Thu Dec 13 05:36:55 2007 From: SirRichard at fascinationsoftware.com (Richard Goedeken) Date: Thu, 13 Dec 2007 08:36:55 -0500 Subject: xorg Digest, Vol 29, Issue 62 In-Reply-To: References: Message-ID: <47613577.1050707@fascinationsoftware.com> > Hi, > > I'm having the exact same issue on Ubuntu gutsy and hardy with the same AOpen Mini PC. Hardy uses the 2.2.0 tag. > Which should include those fixes. Video comes on during boot on TV if nothing else is connected, but as soon as the > x drivers init, screen turns of. > > According to log, everything seem to have gone allright, and X has been started, but as said, there is no output on > the SVIDEO/COMPOSITE or COMPONENT outputs. > > Some friends of mines have been able to get the exact same type of Mini PC to display with ubuntu gutsy. I've tried > with exact same drivers/xorg.conf with not luck. One potential issue could be that this system have been booted > with windows on it, so maybe it has changes something in the display driver. > > I've supplied xorg.conf, log and xrandr outuput. Hopefully this could give somebody an idea > > The fix for ignoring the LVDS output on these mainboards doesn't seem to be working either. It's still listed by > xrandr if you don't ignore it in xorg.conf I have been able to make the TV output work on this device only by doing the following: 1. Use the attached xorg.conf 2. Connect only the component cables - no VGA, DVI, etc. (Composite also works but display quality is bad - there is some color pulsing effect) 3. Screen will go blank when X is starting. I must press Ctrl-alt-F1, wait a second, Ctrl-alt-F7, wait a second, repeat until display shows up. I have filed a bug (#13611) to track these issues. I have never been able to get VGA+TV to work even with all kinds of xrandr resolution and mode setting. Richard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf URL: From nicolas.mailhot at laposte.net Thu Dec 13 05:40:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Dec 2007 14:40:37 +0100 (CET) Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today Message-ID: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> A lot of people seem to be hitting this bug with recent Xorg, including with other video drivers (nv in my case) -- Nicolas Mailhot From florian.harmuth at googlemail.com Thu Dec 13 06:34:06 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Thu, 13 Dec 2007 15:34:06 +0100 Subject: Using XVideo extension? In-Reply-To: <475EAF70.8080803@hummingbird.com> References: <4756CD28.6070206@hummingbird.com> <475815AE.50703@hummingbird.com> <475D6619.8030106@hummingbird.com> <475EAF70.8080803@hummingbird.com> Message-ID: Hello again, if use the code i have attached all works fine, but without scaling. If i set the scale matrix to the following value my screen looks strange (without scaling factor: http://img136.imageshack.us/my.php?image=screenshotwithoutscalinfc9.png) (with scaling factor: http://img88.imageshack.us/my.php?image=screenshotwithscaling05cf7.png). XTransform scale = {{{ XDoubleToFixed (0.5), 0.0, 0.0 }, { 0.0, XDoubleToFixed (0.5), 0.0 }, { 0.0, 0.0, XDoubleToFixed (1.0) }}}; And where i have to set the new image height/width? PutImage or XRenderComposite? Best regards, flo Picture pixmap_pic; Picture window_pic; Pixmap pixmap; XRenderPictureAttributes pic_attr; XTransform scale = {{{ XDoubleToFixed (1.0), 0.0, 0.0 }, { 0.0, XDoubleToFixed (1.0), 0.0 }, { 0.0, 0.0, XDoubleToFixed (1.0) }}}; /* find the used format */ XRenderPictFormat *xformat = XRenderFindVisualFormat (dpy,vis); window_pic = XRenderCreatePicture(dpy, desktopWin, xformat, 0, &pic_attr); pixmap = XCreatePixmap(dpy, desktopWin, si.framebufferWidth, si.framebufferHeight,image->depth); pixmap_pic = XRenderCreatePicture (dpy, pixmap, xformat, 0, &pic_attr); XRenderSetPictureTransform (dpy, pixmap_pic, &scale); /* get the image from server...*/ ... /* put my image to the screen... */ XShmPutImage(dpy,pixmap, gc, image, x, y, x, y,width,height, False); XRenderComposite(dpy,PictOpSrc,pixmap_pic,None,window_pic,x,y,0,0,x,y,width,height); 2007/12/11, Peter Harris : > > Florian Harmuth wrote: > > Hello again, > > i hope that this will be my last post ;-). How can i connect the data of > > pixmap and my XImage struct? > > > 2007/12/10, Peter Harris < peter.harris at hummingbird.com > > >: > > > >> XPutImage(pixmap) # XImage struct used here > > > -- > Hummingbird Connectivity - A Division of Open Text > Peter Harris http://connectivity.hummingbird.com > Research and Development Phone: +1 905 762 6001 > peter.harris at hummingbird.com Toll Free: 1 877 359 4866 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elupus at ecce.se Thu Dec 13 06:47:48 2007 From: elupus at ecce.se (elupus) Date: Thu, 13 Dec 2007 15:47:48 +0100 Subject: Intel driver problem with TV output References: <4752CC21.8090701@fascinationsoftware.com> <17l19tc5mo24c.1c1ztfmhbwh9z$.dlg@40tude.net> Message-ID: <4l29uc346hl0$.gw4m97p859wa.dlg@40tude.net> Hi, > -----Original Message----- > From: Robert Lowery [mailto:rglowery at exemail.com.au] > Sent: den 13 december 2007 09:34 > To: elupus > Cc: xorg at freedesktop.org > Subject: Re: Intel driver problem with TV output > > Your xorg.conf is much more complex than the one I am using with my > AOpen > MP965-DR (see attached) > > Note that TV output should be configured using xrandr, not xorg.conf. > You > will see > in your xorg.log > (WW) intel(0): Option "TV Format" is not used > (WW) intel(0): Option "PreferredMode" is not used > > instead you should use a command such as > xrandr --output TV --set TV_FORMAT=PAL --auto True, but those two options actually do work, (they are checked in driver as initial mode). So with those in there, you don't have to do the xrandr command later. I have checked without those options too, still a no-go. Those options are verified to work on a friend of mines box, so they really should work. > > For the LVDS ignore issue, it would be worth checking with lspci that > the > relevant > id's match the following quirk from i830_quirks.c > { PCI_CHIP_I965_GM, 0x8086, 0x1999, quirk_ignore_lvds }, > 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03) Subsystem: AOPEN Inc. Unknown device [a0a0:062d] Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03) (prog-if 00 [VGA]) Subsystem: AOPEN Inc. Unknown device [a0a0:062d] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fdb00000 (64-bit, non-prefetchable) [size=1M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at ff00 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 3 So I guess, the 0x1999 is wrong, or this is a different revision of this device. > HTH > > -Rob > My guess is that I have a different revision of the graphic - card, and it behaves differently. Thanx for the ideas thou, will try your xorg.conf later Joakim From simon.farnsworth at onelan.co.uk Thu Dec 13 07:10:25 2007 From: simon.farnsworth at onelan.co.uk (Simon Farnsworth) Date: Thu, 13 Dec 2007 15:10:25 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver Message-ID: <47614B61.7060906@onelan.co.uk> Hello, We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an Intel 965Q and the xf86-video-intel driver, on Fedora 8. We've previously managed to make a 945 chip drive this display at 1080p, using the i810 driver (version 1.6.0). Switching one of these machines to the intel driver (either git HEAD, or 2.1.1 as shipped with Fedora), or using the 965, causes the display to be unable to lock to the image. I've attached a log from the 965 (doesn't work, but is using a newer X.org and the intel driver), and from the working 945 (using an old X.org and the i810 driver), together with the EDID data from the display. Any clues would be welcome; I'm obviously happy to try anything people can suggest that might solve this problem. -- Simon Farnsworth -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.log.faulty URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: edid URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.log.working URL: From SirRichard at fascinationsoftware.com Thu Dec 13 07:25:05 2007 From: SirRichard at fascinationsoftware.com (Richard Goedeken) Date: Thu, 13 Dec 2007 10:25:05 -0500 Subject: Intel TV output problems - color pulsing In-Reply-To: <476145F0.7080206@mythtvthemes.co.uk> References: <47613577.1050707@fascinationsoftware.com> <476145F0.7080206@mythtvthemes.co.uk> Message-ID: <47614ED1.20909@fascinationsoftware.com> Justin Hornsby wrote: > Regarding the pulsing effect on the colour of the composite output - at > least as far as the PAL video modes are concerned the driver needs > patched. I mean to raise a ticket in bugzilla for this but other stuff > keeps getting in the way. > > Anyway in i830_tv.c a value of 286 needs changing to 288 (somewhere in > the "PAL" section). that solved the problem for me. Yeah, I saw the posting about this on the list. I have an NTSC setup, though. Perhaps a similar bug affects both formats? Richard From kristof.ralovich at gmail.com Thu Dec 13 08:00:12 2007 From: kristof.ralovich at gmail.com (=?UTF-8?Q?Ralovich_Krist=C3=B3f?=) Date: Thu, 13 Dec 2007 17:00:12 +0100 Subject: savage inproper init In-Reply-To: References: <5712ce4f0712110849p4ce06088xc5652738547a2bbd@mail.gmail.com> <5712ce4f0712111109rd2e1ecfw1f4d1b81acf10c9a@mail.gmail.com> Message-ID: <5712ce4f0712130800m1c3fba28m97d7dfbbea1023ec@mail.gmail.com> On Dec 11, 2007 8:20 PM, Alex Deucher wrote: > > On Dec 11, 2007 2:09 PM, Ralovich Krist?f wrote: > > On Dec 11, 2007 6:04 PM, Alex Deucher wrote: > > > On Dec 11, 2007 11:49 AM, Ralovich Krist?f wrote: > > > > Hi, > > > > > > > > I would like to report about hard lockups (ping and ssh stops too) > > > > caused by the savage driver. I am getting the same results no matter > > > > if I use the savage fbdev or not. Neither EXA / XAA changes the > > > > situation. Additionally if I use EXA, it garbles the bitmaps and the X > > > > screen around the cursor. The machine is an IBM T22. I can not find > > > > any further details in the system logs or X log. > > > > > > > > The symptom is if boot up, X wont run, it hangs before switching to > > > > the desired resolution. But if I run windows first then reboot and > > > > start linux, everything is going fine. GL and Xv works too. > > > > > > > > The other way avoiding the lockup2 was putting the AGPMode "2" line to > > > > the Device section, it was a little bit slower, but it was stable at > > > > least. > > > > > > Savage IX/MX cards are only AGP 2x cards. Some savage agp 2x cards do > > > not like 1x mode (the driver default). I never had a chance to figure > > > out which cards this affected as it was hit or miss. We should > > > probably just default to whatever AGP mode the bios sets up. > > > > > > Alex > > > > > > > Alex, > > > > first of all, thanks for the fast reply. You were right, even win is > > using the card in agp 2x mode, so from now on I am using that too. > > With agp 2x the cold startup problem is vanished again. But now I have > > some messages in /var/log/kern.log. After X startup: > > > > Dec 11 18:26:55 t22 kernel: mtrr: base(0xf2000000) is not aligned on a > > size(0x5000000) boundary > > Dec 11 18:26:55 t22 last message repeated 2 times > > Dec 11 18:26:55 t22 kernel: agpgart: Found an AGP 1.0 compliant device > > at 0000:00:00.0. > > Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at > > 0000:00:00.0 into 2x mode > > Dec 11 18:26:55 t22 kernel: agpgart: Putting AGP V2 device at > > 0000:01:00.0 into 2x mode > > > > X is working properly, so is Xv! But if I start glxgears, there is a > > reproducible lockup again: > > > > Dec 11 18:28:01 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! > > > > OR > > > > Dec 11 19:27:15 t22 kernel: [drm:savage_bci_wait_event_shadow] *ERROR* failed! > > Dec 11 19:27:15 t22 kernel: [drm] status=0x00009631, e=0x9633 > > Dec 11 19:27:28 t22 kernel: [drm:savage_bci_wait_fifo_shadow] *ERROR* failed! > > Dec 11 19:27:28 t22 kernel: [drm] status=0x003c7620, threshold=0x00007620 > > > > with the above lines in kern.log. I am still able to restart the > > machine using keys, so the kernel keeps running. > > > > Putting ShadowStatus "off" into xorg.conf wont solve the problem, but > > the kernel message is different: > > > > Dec 11 19:36:53 t22 kernel: [drm:savage_bci_wait_event_reg] *ERROR* failed! > > Dec 11 19:36:53 t22 kernel: [drm] status=0x00000002, e=0x0004 > > > > and causing a hard lockup again! > > IIRC, you need one or more of the following options: > Option "DmaMode" "None" > Option "BusType" "PCI" > > see the savage man page for more info. > > > > > With BCIforXv "off" the result is always soft lockup: > > BCIforXv has no affect on old savage cards like the MX/IX. It only > affects savage4 and IGP cards. > > Alex > Thanks, with BusType PCI, it works reliably in both 2D and 3D. Bye, Kristof From adr3nald0s at gmail.com Thu Dec 13 08:13:18 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Thu, 13 Dec 2007 10:13:18 -0600 Subject: Improving rotated ATI performance Message-ID: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> Wow, I would really like to thank Alex Deucher for his quick response to my problems with using my external display with the ATI driver and fixing the mouse cursor problem I was having when one of my displays was rotated. The responsiveness has been great and my configuration is now functional. As far as I can tell all of the actual bugs that were affecting me have been corrected. Thank you. Does anyone have tips on improving the performance of my display when it is rotated? For example, page down in emacs or gvim takes 1-2 seconds with 100% CPU usage and you can watch screen paint happening. It almost makes me nostalgic. But... I realize this may be because ATI has not released the information on or does not support accelerated rotation in 2D, but I thought I would ask any way. Thanks again and here is my xrandr settings and xorg.conf in case it is pertinent. xrandr --output VGA-0 --auto --left-of LVDS --rotate left Section "ServerLayout" Identifier "Simple Layout" Screen "Screen[0]" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/share/X11/rgb" FontPath "/usr/share/fonts/local/" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/OTF/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/CID/" FontPath "/usr/share/fonts/Speedo/" FontPath "/usr/share/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/100dpi/:unscaled" FontPath "/usr/share/fonts/75dpi/" FontPath "/usr/share/fonts/100dpi/" FontPath "/usr/share/fonts/cyrillic/" EndSection Section "Module" Load "dbe" # Double buffer extension SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection Load "type1" Load "freetype" #Load "speedo" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/mouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" Identifier "Internal Panel" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" Option "RightOf" "External VGA Monitor" EndSection Section "Monitor" Identifier "S-Video" Option "Enable" "FALSE" EndSection Section "Monitor" Identifier "DVI-O" Option "Enable" "FALSE" EndSection Section "Monitor" Identifier "External VGA Monitor" Option "DPMS" "true" EndSection Section "Device" Identifier "X600" Driver "ati" Option "Monitor-LVDS" "Internal Panel" Option "Monitor-VGA-0" "External VGA Monitor" EndSection Section "Screen" Identifier "Screen[0]" Device "X600" Monitor "Internal Panel" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Virtual 3520 1920 EndSubSection EndSection -- Adr3nal D0S From alexdeucher at gmail.com Thu Dec 13 09:37:09 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 13 Dec 2007 12:37:09 -0500 Subject: Improving rotated ATI performance In-Reply-To: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> Message-ID: On Dec 13, 2007 11:13 AM, Adr3nal D0S wrote: > Wow, I would really like to thank Alex Deucher for his quick response > to my problems with using my external display with the ATI driver and > fixing the mouse cursor problem I was having when one of my displays > was rotated. The responsiveness has been great and my configuration > is now functional. As far as I can tell all of the actual bugs that > were affecting me have been corrected. > > Thank you. > glad to help. > Does anyone have tips on improving the performance of my display when > it is rotated? For example, page down in emacs or gvim takes 1-2 > seconds with 100% CPU usage and you can watch screen paint happening. > It almost makes me nostalgic. But... > > I realize this may be because ATI has not released the information on > or does not support accelerated rotation in 2D, but I thought I would > ask any way. rotation can use EXA composite to accelerate transforms, so you'll have to use EXA. For r1xx-r2xx the composite code is written, but there are some bug when doing transforms, so it doesn't work properly for rotation. for r3xx and newer, the code needs to be written. there should be enough info available for r3xx-r4xx in the 3D driver to add composite support, but no one has done the work yet. Alex From adr3nald0s at gmail.com Thu Dec 13 10:19:52 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Thu, 13 Dec 2007 12:19:52 -0600 Subject: Improving rotated ATI performance In-Reply-To: References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> Message-ID: <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> On Dec 13, 2007 11:37 AM, Alex Deucher wrote: > rotation can use EXA composite to accelerate transforms, so you'll > have to use EXA. For r1xx-r2xx the composite code is written, but > there are some bug when doing transforms, so it doesn't work properly > for rotation. for r3xx and newer, the code needs to be written. > there should be enough info available for r3xx-r4xx in the 3D driver > to add composite support, but no one has done the work yet. I've done a fair amount of OpenGL over the years, but haven't dealt with 3D much at the hardware level. Am I correct that 3D acceleration only works up to a maximum virtual size of 2048x2048? If so, does this mean it would be impossible to have accelerated compositing under EXA for larger virtuals? Not that I am actually capable of pulling this off or have the time to do so. But, if it might work for my configuration, I might consider looking at it sometime. From alexdeucher at gmail.com Thu Dec 13 10:24:22 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 13 Dec 2007 13:24:22 -0500 Subject: Improving rotated ATI performance In-Reply-To: <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> Message-ID: On Dec 13, 2007 1:19 PM, Adr3nal D0S wrote: > On Dec 13, 2007 11:37 AM, Alex Deucher wrote: > > > rotation can use EXA composite to accelerate transforms, so you'll > > have to use EXA. For r1xx-r2xx the composite code is written, but > > there are some bug when doing transforms, so it doesn't work properly > > for rotation. for r3xx and newer, the code needs to be written. > > there should be enough info available for r3xx-r4xx in the 3D driver > > to add composite support, but no one has done the work yet. > > I've done a fair amount of OpenGL over the years, but haven't dealt > with 3D much at the hardware level. Am I correct that 3D acceleration > only works up to a maximum virtual size of 2048x2048? If so, does this > mean it would be impossible to have accelerated compositing under EXA > for larger virtuals? It depends on the hardware. r1xx and r2xx had 2048 3d coordinate limits and tiling surface limits. r3xx/r4xx are 4096. textures are limited to 2048 on r1xx-r4xx. > > Not that I am actually capable of pulling this off or have the time to > do so. But, if it might work for my configuration, I might consider > looking at it sometime. > sure. patches welcome :) Alex From jbarnes at virtuousgeek.org Thu Dec 13 11:09:47 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 13 Dec 2007 11:09:47 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <4760D4E1.3060900@gentoo.org> References: <475F87D6.1040008@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> <4760D4E1.3060900@gentoo.org> Message-ID: <200712131109.47407.jbarnes@virtuousgeek.org> On Wednesday, December 12, 2007 10:44 R?mi Cardona wrote: > Jesse Barnes wrote: > > I'm working on a 2.2.1 release now to address these types of > > problems. The only Xv related change I can think of was to avoid > > crashes on some machines where if you used Xv and exited the server > > you'd get a crash; I can't think of anything else that would cause > > the problem you're seeing. Is there a bug filed? > > Willi Mann pointed out bug #13108, and it looks very similar. > Unfortunately, it's not marked as fixed and there's no reference to a > patch either in xf86-video-intel nor xorg-server for me to try. I just added it to the 2.2.1 blocker list. This seems like a major regression to me, and I hate regressions (we have one other that's driving me crazy right now, 13196). I'll try to get both fixed for the 2.2.1 release... Thanks, Jesse From jbarnes at virtuousgeek.org Thu Dec 13 11:11:42 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 13 Dec 2007 11:11:42 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197545026.17258.19.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> <1197545026.17258.19.camel@localhost.localdomain> Message-ID: <200712131111.42297.jbarnes@virtuousgeek.org> On Thursday, December 13, 2007 3:23 Drew Parsons wrote: > On Wed, 2007-12-12 at 09:24 -0800, Jesse Barnes wrote: > > I'm working on a 2.2.1 release now to address these types of > > problems. The only Xv related change I can think of was to avoid > > crashes on some machines where if you used Xv and exited the server > > you'd get a crash; I can't think of anything else that would cause > > the problem you're seeing. Is there a bug filed? > > Just commenting for the record, I've found that S3 suspend-to-ram is > currently broken with intel 2.2.0, xserver 1.4.1, linux 2.6.23, mesa > 7.0.2 on intel 82855 GME. Upon resume, the system freezes blank. It > had reached successful operation recently with intel 2.1.0. I > switched on the new kernel SUSPEND option which is supposed to help > S3 suspend in kernel drivers. Are you saying that it broke when you switched to the kernel based suspend? Or only broke when you upgraded to 2.2? There are still a few open suspend/resume bugs, maybe you're hitting one of those? > I think you've indicated this may be fixed in git, which I haven't > had the chance to test yet, so I'm commenting just to mark the > current status in the stable releases :) I hope it's fixed, but it's very possible that it's not... Getting the timing and register restore ordering right so that it works on both 8xx and 9xx chips is turning out to be pretty tricky. Jesse From jbarnes at virtuousgeek.org Thu Dec 13 11:18:33 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 13 Dec 2007 11:18:33 -0800 Subject: intel driver for 945GM multihead question In-Reply-To: References: Message-ID: <200712131118.33758.jbarnes@virtuousgeek.org> On Thursday, December 13, 2007 5:20 Dan Naughton wrote: > I can seem to find any documentation on this. I've tried the > dualhead snippet on the intel website, but I keep getting TDMS-1 and > TMDS-2 connecting to pipe A and the two displays cloned. The xrandr > utility wouldn't work with the Xinerama on in the xorg.conf, but when > I shut it off in the conf file, the xrandr utility doesn't seem to do > much other than make the two displays flicker when you hit enter. My > hardware spec says the output of the 945GM looks like this: > ___________ > > | 945GM | > |_________| > > ____| | | | |___________ > > | _| | |___ | > > TV VGA LVDS TDMS-1 TDMS-2 > (SDVO1?) (SDVO2?) > > The VGA works fine during bootup and for the console. I'm pretty > sure I need to assign TDMS-1 to Pipe A and TDMS-2 to Pipe B, but I > can't find anything in the documentation that seems to work. For > example: *Option "MonitorLayout" "**anystr**"*Valid monitors are CRT, > LFP, DFP, TV, CRT2, LFP2, DFP2, TV2 does nothing:( The log file > always shows the following? > > (II) intel(0): Output configuration: > (II) intel(0): Pipe A is on > (II) intel(0): Display plane A is now enabled and connected to pipe > A. (II) intel(0): Pipe B is off > (II) intel(0): Display plane B is now disabled and connected to > pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A > (II) intel(0): Output TMDS-2 is connected to pipe A > (II) intel(0): Output TV is connected to pipe none The MonitorLayout option isn't available in recent drivers. If you followed the instructions at http://www.intellinuxgraphics.org/dualhead.html I'm not sure how you ended up using that option... How are you trying to configure your system? The Intel chip only has two pipes, so if you want to use three outputs, you'll need to clone two of them (i.e. you can't have an extended desktop across VGA, TMDS-1 and TMDS-2), maybe that's your problem? Since the VGA output has a lower quality than the TMDS (probably DVI) outputs, you should probably clone it and have the TMDS outputs span your desktop. Jesse From jbarnes at virtuousgeek.org Thu Dec 13 11:27:40 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 13 Dec 2007 11:27:40 -0800 Subject: Intel 2.2.1 release planning Message-ID: <200712131127.40293.jbarnes@virtuousgeek.org> I'm trying to put together a 2.2.1 Intel driver release (was hoping for this week but that might not happen) given that we had at least a couple of major regressions in 2.2 relative to 2.1.1. The blocker bug is 13493, and I'm interested in hearing if there are any other major regressions that should be on the list, so please reply to this message or to me personally and I'll see that they're added. The main problems so far seem to be the Xv crasher (13108) and the pipe enable bug (13196) I introduced while fixing a crash on 8xx chips for the 2.2 release. We already know about the EXA performance problems people have been seeing, but unfortunately those fixes won't be ready for this release. However, XAA is still available, so you can use "AccelMethod" "XAA" in your xorg.conf if needed. Thanks, Jess From ajax at nwnk.net Thu Dec 13 12:27:17 2007 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 13 Dec 2007 15:27:17 -0500 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <47614B61.7060906@onelan.co.uk> References: <47614B61.7060906@onelan.co.uk> Message-ID: <1197577637.30771.113.camel@localhost.localdomain> On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: > Hello, > > We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an > Intel 965Q and the xf86-video-intel driver, on Fedora 8. > > We've previously managed to make a 945 chip drive this display at 1080p, > using the i810 driver (version 1.6.0). Switching one of these machines > to the intel driver (either git HEAD, or 2.1.1 as shipped with Fedora), > or using the 965, causes the display to be unable to lock to the image. It's not clear from your description whether you're trying to drive this monitor with DVI or VGA. I suspect DVI, in which case, the 965 log shows something going wildly wrong in mode selection: > (II) intel(0): SDVO device VID/DID: 04:AA.03, clock range 25.0MHz - 165.0MHz, input 1: Y, input 2: N, output 1: Y, output 2: N > <...> > (II) intel(0): EDID for output VGA > <...> > (II) intel(0): Modeline "1920x1080"x60.0 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync (67.2 kHz) I can't think of a situation where that mode is ever valid. I suspect it's inherited from the extra modes list in Fedora; I'll check and patch it out if so. But if this is a DVI connection, then the 965 driver is also getting confused, because the single-link-DVI bandwidth limit should have clipped this mode away anyway. - ajax -------------- 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 rafaelmejiasc at gmail.com Thu Dec 13 12:27:55 2007 From: rafaelmejiasc at gmail.com (=?ISO-8859-1?Q?Rafael_Mej=EDas?=) Date: Fri, 14 Dec 2007 15:57:55 +1930 Subject: Resolution problem with i810 In-Reply-To: <200712131152.31586.bve@gmx.de> References: <2f96467a0712121418l3a02688fiac2522b9795838b@mail.gmail.com> <200712131152.31586.bve@gmx.de> Message-ID: <2f96467a0712131227n12a0902apce07affea8b4e3c5@mail.gmail.com> Felix Miata said: > Here's a suggestion I forgot, maybe because your xorg and/or driver version > might not be new enough for it to be valid. In Section "Monitor" try adding: > Option "PreferredMode" "1024x768" I just tried that and gdm did not work. The log said that "PreferredMode" is not a valid keyword in this section. Old driver I guess... And Ben Hard said: > Did you try with a default depth of 16? That didn't do much except for the lower color depth, of course. Still at 800x600. What else? :-( I really need to improve my resolution since I work with graphics design and this screen is too small... even for Inkscape... From elupus at ecce.se Thu Dec 13 13:19:16 2007 From: elupus at ecce.se (elupus) Date: Thu, 13 Dec 2007 22:19:16 +0100 Subject: [PATCH] LVDS quirk for AOPEN MINIPC with 965GM Message-ID: Hi, Current quirk fix for the aopen device doesn't get all. I'm wondering if the second quirk is really correct, as it seem to be PCI bus information not the subsystem information. 0x8086 is atleast that for me, but i may be totally of. In either case, here is a duplication of the previous quirk for the 945, but for the 965 instead. Not that this fixes anything at all for my non working tv out, but hey :). Maybe i could dump the tv output registers somehow since everything works while bios boots. Regards Joakim -------------- next part -------------- A non-text attachment was scrubbed... Name: intel.patch Type: text/x-patch Size: 522 bytes Desc: Attached file: intel.patch URL: From Magnus.Vigerlof at home.se Thu Dec 13 13:53:42 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-15?q?Vigerl=F6f?=) Date: Thu, 13 Dec 2007 22:53:42 +0100 Subject: New input hotness not happening for 1.5 In-Reply-To: <20071205192424.GA3614@fooishbar.org> References: <20071205192424.GA3614@fooishbar.org> Message-ID: <200712132253.43153.Magnus.Vigerlof@home.se> On onsdag 05 december 2007, Daniel Stone wrote: > Hi, > Despite putting in the XDS2007 notes that input transformation, XKB 2 > and Xi 2 would happen for 1.5, they just aren't going to, to be honest. > Doing these sensibly requires some fairly sweeping changes to the way we > _process_ events (input-hotplug was all about how we generate them) that > also requires sorting out the interactions with MPX, particularly the > grab bits, which are going to be tough. That and I badly need a break. > > I'll try to get them done for 1.6; if 1.5 branches off in Feb, then that > means I'll just always be working off master from when I start anyway. > Sorry about this. > > Cheers, > Daniel Hi Daniel, I'm really sorry to hear that the input transformation issue will not be resolved in the nearest future. That's a real bummer for us wanting to have the same behaviour for our extended InputDevices in 1.4 as in 1.3. As this would be our situation for both 1.4 and 1.5 now, I'm thinking if it's possible to do something (without an interface change) that would get back at least part of the behaviour that we had before. So.. If I can make a patch that don't have an effect on any interface (smallest change possible), would that be acceptable as an interim solution? The current reporting limits are severly limiting the usabillity of extended input devices with absolute axis at the moment, and I can't see it would break anything if we did something about this (I consider the current situation broken to be honest) Cheers Magnus From william88 at gmail.com Thu Dec 13 13:56:07 2007 From: william88 at gmail.com (William) Date: Thu, 13 Dec 2007 19:56:07 -0200 Subject: Intel tv output in gray-scale In-Reply-To: <632825b40712131349k775750fcwfa907e034e99ea62@mail.gmail.com> References: <632825b40712131349k775750fcwfa907e034e99ea62@mail.gmail.com> Message-ID: <632825b40712131356i455b3a19g60b3248831213db2@mail.gmail.com> Hi, Since I bought my first laptop (about 3 months ago) I am trying to get the TV output working with colors (it works just fine but in gray-scale). I was looking for threads in xorg archive mailing list about this issue and I found some people with the same problem but without a conclusive answer. I already tried to adjust the format on TV and set the TV_FORMAT using xrandr (i.e. xrandr --output TV --set TV_FORMAT PAL-M) without success, the screen still in gray-scale. (I can get it wor king on Windows) My video card: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) I am running Debian Unstable (sid) and I already tried to use the lastest intel driver from svn repository. Is this a known issue? Am I doing something wrong? Is there any information which i can give? Thanks for your help :) Please, CC replies to me because i am not a subscriber. Regards, William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From madman2003 at gmail.com Thu Dec 13 15:07:10 2007 From: madman2003 at gmail.com (Maarten Maathuis) Date: Fri, 14 Dec 2007 00:07:10 +0100 Subject: randr-1.2 rotation doesn't use composite hook with a transform Message-ID: <6d4bc9fc0712131507i3104d2aai7daba0431197dccb@mail.gmail.com> I've been trying to implement rotation support into the nouveau driver, by filling the shadow hooks and setting the crtc base correctly. This works but it is slow, suggesting software rendering. My understanding is that it should use the composite hook to rotate and transfer the image to the shadow area. It does seem to call composite very frequently, but not with a transform. I'm using xserver git. Any idea what could be wrong? Sincerely, Maarten Maathuis. From rglowery at exemail.com.au Thu Dec 13 15:15:40 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Fri, 14 Dec 2007 10:15:40 +1100 (EST) Subject: Intel driver problem with TV output In-Reply-To: <005701c83d93$a66df510$f349df30$@se> References: <1693.220.233.174.242.1197534826.squirrel@webmail.exetel.com.au> <005701c83d93$a66df510$f349df30$@se> Message-ID: <54532.64.213.30.2.1197587740.squirrel@webmail.exetel.com.au> > Hi, > >> Your xorg.conf is much more complex than the one I am using with my >> AOpen >> MP965-DR (see attached) >> >> Note that TV output should be configured using xrandr, not xorg.conf. >> You >> will see >> in your xorg.log >> (WW) intel(0): Option "TV Format" is not used >> (WW) intel(0): Option "PreferredMode" is not used >> >> instead you should use a command such as >> xrandr --output TV --set TV_FORMAT=PAL --auto > > > True, but those two options actually do work, (they are checked in driver > as > initial mode). So with those in there, you don't have to do the xrandr > command later. > > I have checked without those options too, still a no-go. Those options are > verified to work on a friend of mines box, so they really should work. > >> >> For the LVDS ignore issue, it would be worth checking with lspci that >> the >> relevant >> id's match the following quirk from i830_quirks.c >> { PCI_CHIP_I965_GM, 0x8086, 0x1999, quirk_ignore_lvds }, >> > > 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 > Memory Controller Hub [8086:2a00] (rev 03) > Subsystem: AOPEN Inc. Unknown device [a0a0:062d] > Flags: bus master, fast devsel, latency 0 > Capabilities: [e0] Vendor Specific Information > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile > GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03) (prog-if > 00 > [VGA]) > Subsystem: AOPEN Inc. Unknown device [a0a0:062d] > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at fdb00000 (64-bit, non-prefetchable) [size=1M] > Memory at d0000000 (64-bit, prefetchable) [size=256M] > I/O ports at ff00 [size=8] > Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- > Queue=0/0 Enable- > Capabilities: [d0] Power Management version 3 > > So I guess, the 0x1999 is wrong, or this is a different revision of this > device. Are you using the AOpen miniPC MP965-DR found at http://minipc.aopen.com/Global/spec.htm I have two of these and they both have the following id's { PCI_CHIP_I965_GM, 0x8086, 0x1999, quirk_ignore_lvds }, As you say, perhaps they have revised them (or you have a different device). I always thought it strange they were using the intel id (0x8086) rather than the AOpen one (0xa0a0). > > >> HTH >> >> -Rob >> > > My guess is that I have a different revision of the graphic - card, and it > behaves differently. > > Thanx for the ideas thou, will try your xorg.conf later > > Joakim > From rglowery at exemail.com.au Thu Dec 13 15:23:41 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Fri, 14 Dec 2007 10:23:41 +1100 (EST) Subject: Intel TV output problems - color pulsing In-Reply-To: <47614ED1.20909@fascinationsoftware.com> References: <47613577.1050707@fascinationsoftware.com> <476145F0.7080206@mythtvthemes.co.uk> <47614ED1.20909@fascinationsoftware.com> Message-ID: <55746.64.213.30.2.1197588221.squirrel@webmail.exetel.com.au> > > Justin Hornsby wrote: >> Regarding the pulsing effect on the colour of the composite output - at >> least as far as the PAL video modes are concerned the driver needs >> patched. I mean to raise a ticket in bugzilla for this but other stuff >> keeps getting in the way. >> >> Anyway in i830_tv.c a value of 286 needs changing to 288 (somewhere in >> the "PAL" section). that solved the problem for me. Looking at the code, I'm not sure this fix is enough. Later code has 1209 if (tv_mode->progressive) 1210 ysize = tv_mode->nbr_end + 1; 1211 else 1212 ysize = 2*tv_mode->nbr_end + 1; So using 286 would result in a ysize = 573 288 would result in a ysize = 577 ie neither are right (576). Hopefully someone with doco can comment. > > > Yeah, I saw the posting about this on the list. I have an NTSC setup, > though. Perhaps a similar bug affects both formats? > > Richard > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From dparsons at debian.org Thu Dec 13 15:28:21 2007 From: dparsons at debian.org (Drew Parsons) Date: Fri, 14 Dec 2007 10:28:21 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712131111.42297.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> <1197545026.17258.19.camel@localhost.localdomain> <200712131111.42297.jbarnes@virtuousgeek.org> Message-ID: <1197588501.17258.31.camel@localhost.localdomain> On Thu, 2007-12-13 at 11:11 -0800, Jesse Barnes wrote: > On Thursday, December 13, 2007 3:23 Drew Parsons wrote: > > On Wed, 2007-12-12 at 09:24 -0800, Jesse Barnes wrote: > > > I'm working on a 2.2.1 release now to address these types of > > > problems. The only Xv related change I can think of was to avoid > > > crashes on some machines where if you used Xv and exited the server > > > you'd get a crash; I can't think of anything else that would cause > > > the problem you're seeing. Is there a bug filed? > > > > Just commenting for the record, I've found that S3 suspend-to-ram is > > currently broken with intel 2.2.0, xserver 1.4.1, linux 2.6.23, mesa > > 7.0.2 on intel 82855 GME. Upon resume, the system freezes blank. It > > had reached successful operation recently with intel 2.1.0. I > > switched on the new kernel SUSPEND option which is supposed to help > > S3 suspend in kernel drivers. > > Are you saying that it broke when you switched to the kernel based > suspend? Or only broke when you upgraded to 2.2? There are still a > few open suspend/resume bugs, maybe you're hitting one of those? > I think it broke in intel 2.2. That is, I had been using linux 2.6.22 + intel 2.1.1 at the point where S3 suspend worked [1], but after the upgrade to intel 2.2 last month, still with linux 2.6.22, resume no longer worked. I only got to try linux 2.6.23 last week and turned on SUSPEND hoping it might have fixed the problem. I haven't yet tried 2.6.23 with SUSPEND switched off, is there any point doing so? Drew [1] https://bugs.freedesktop.org/show_bug.cgi?id=7834#c17 From jbarnes at virtuousgeek.org Thu Dec 13 17:01:10 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 13 Dec 2007 17:01:10 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197588501.17258.31.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712131111.42297.jbarnes@virtuousgeek.org> <1197588501.17258.31.camel@localhost.localdomain> Message-ID: <200712131701.10250.jbarnes@virtuousgeek.org> On Thursday, December 13, 2007 3:28 pm Drew Parsons wrote: > On Thu, 2007-12-13 at 11:11 -0800, Jesse Barnes wrote: > > On Thursday, December 13, 2007 3:23 Drew Parsons wrote: > > > On Wed, 2007-12-12 at 09:24 -0800, Jesse Barnes wrote: > > > > I'm working on a 2.2.1 release now to address these types of > > > > problems. The only Xv related change I can think of was to avoid > > > > crashes on some machines where if you used Xv and exited the server > > > > you'd get a crash; I can't think of anything else that would cause > > > > the problem you're seeing. Is there a bug filed? > > > > > > Just commenting for the record, I've found that S3 suspend-to-ram is > > > currently broken with intel 2.2.0, xserver 1.4.1, linux 2.6.23, mesa > > > 7.0.2 on intel 82855 GME. Upon resume, the system freezes blank. It > > > had reached successful operation recently with intel 2.1.0. I > > > switched on the new kernel SUSPEND option which is supposed to help > > > S3 suspend in kernel drivers. > > > > Are you saying that it broke when you switched to the kernel based > > suspend? Or only broke when you upgraded to 2.2? There are still a > > few open suspend/resume bugs, maybe you're hitting one of those? > > I think it broke in intel 2.2. That is, I had been using linux 2.6.22 + > intel 2.1.1 at the point where S3 suspend worked [1], but after the > upgrade to intel 2.2 last month, still with linux 2.6.22, resume no > longer worked. Does it hang or crash now? Or just not restore the display? These 855GM chips are starting to drive me crazy... > I only got to try linux 2.6.23 last week and turned on SUSPEND hoping it > might have fixed the problem. I haven't yet tried 2.6.23 with SUSPEND > switched off, is there any point doing so? Well, I'm mainly worried that the kernel based suspend/resume support hasn't seen much action yet, and so is probably buggy on some machines... I still recommend giving it a try, because if it works your suspend/resume should be solid, but if not, you can always turn it off and hope that the X driver will do the right thing. Thanks, Jesse From hong.liu at intel.com Thu Dec 13 17:19:38 2007 From: hong.liu at intel.com (Hong Liu) Date: Fri, 14 Dec 2007 09:19:38 +0800 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <47614B61.7060906@onelan.co.uk> References: <47614B61.7060906@onelan.co.uk> Message-ID: <1197595178.4805.49.camel@devlinux-hong.sh.intel.com> On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: > Hello, > > We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an > Intel 965Q and the xf86-video-intel driver, on Fedora 8. > > We've previously managed to make a 945 chip drive this display at 1080p, > using the i810 driver (version 1.6.0). Switching one of these machines > to the intel driver (either git HEAD, or 2.1.1 as shipped with Fedora), > or using the 965, causes the display to be unable to lock to the image. > > I've attached a log from the 965 (doesn't work, but is using a newer > X.org and the intel driver), and from the working 945 (using an old > X.org and the i810 driver), together with the EDID data from the > display. Any clues would be welcome; I'm obviously happy to try anything > people can suggest that might solve this problem. It seems you have added a preferred mode in your xorg.conf and let intel driver to choose this mode instead of the detailed timing from the EDID data. (II) intel(0): Modeline "1920x1080"x60.0 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync (67.2 kHz) (II) intel(0): Modeline "1920x1080"x59.9 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync (66.6 kHz) And also from your working log, the detailed timing from EDID is working. (EE) I810(0): Modeline "1920x1080"x59.9 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync (66.6 kHz) So would you please remove the preferredmode option in your xorg.conf and have a retry? Thanks, Hong From charles_hibbits at yahoo.com Thu Dec 13 19:17:16 2007 From: charles_hibbits at yahoo.com (Charles Hibbits) Date: Thu, 13 Dec 2007 19:17:16 -0800 (PST) Subject: radeon 9000 (rv250) tV-out troubles Message-ID: <748141.40308.qm@web51801.mail.re2.yahoo.com> I realize this has been discussed to some degree, but I may not be understanding the instructions correctly so I apologize for another thread. I have an Sapphire Radeon 9000 64MB with TV out. Everything was running fine with the patched opensource driver on Ubuntu Feisty (xorg 7.2 I believe). Saturday I upgraded to Gutsy (xorg 7.3) and I lost the tv out. At first the gnome X configuration tool set it to a VESA driver which produced black and white TV out. When I use the XORG ATI driver the TV out goes away. After searching around I found the following commands can be issued to make it work sorta: # xrandr --addmode S-video 800x600 # xrandr --output S-video --mode 800x600 # xrandr --output S-video --set tv_standard ntsc # xrandr --output S-video --off # xrandr --output S-video --mode 800x600 http://lists.freedesktop.org/archive...er/029292.html The problem is this is not static, after reboot I loose the TV out again. Also My main usage of this computer is to run mythtv, but the video will not play on the TV, only the monitor. I assume this has something to do with it not being treated as a primary display or something to that effect. I assume there is something wrong with my xorg.conf, but I have not been able to find the right options. Here is my xorg.conf: # Section "Files" # EndSection # # Section "InputDevice" # Identifier "Generic Keyboard" # Driver "kbd" # Option "CoreKeyboard" # Option "XkbRules" "xorg" # Option "XkbModel" "pc105" # Option "XkbLayout" "us" # EndSection # # Section "InputDevice" # Identifier "Configured Mouse" # Driver "mouse" # Option "CorePointer" # Option "Device" "/dev/input/mice" # Option "Protocol" "ImPS/2" # Option "ZAxisMapping" "4 5" # EndSection # # Section "InputDevice" # Driver "wacom" # Identifier "stylus" # Option "Device" "/dev/input/wacom" # Option "Type" "stylus" # Option "ForceDevice" "ISDV4" # Tablet PC ONLY # EndSection # # Section "InputDevice" # Driver "wacom" # Identifier "eraser" # Option "Device" "/dev/input/wacom" # Option "Type" "eraser" # Option "ForceDevice" "ISDV4" # Tablet PC ONLY # EndSection # # Section "InputDevice" # Driver "wacom" # Identifier "cursor" # Option "Device" "/dev/input/wacom" # Option "Type" "cursor" # Option "ForceDevice" "ISDV4" # Tablet PC ONLY # EndSection # # Section "Device" # Identifier "Radeon 9000" # Driver "ati" # BusID "PCI:1:0:0" # Option "MonitorLayout" "AUTO, NONE" # Option "TVOutput" "NTSC" # EndSection # # Section "Monitor" # Identifier "Generic Monitor" # Option "DPMS" # HorizSync 30-70 # VertRefresh 50-160 # EndSection # # Section "Screen" # Identifier "Default Screen" # Device "Radeon 9000" # Monitor "Generic Monitor" # DefaultDepth 24 # SubSection "Display" # Modes "800x600" "640x480" # EndSubSection # EndSection # # Section "ServerLayout" # Identifier "Default Layout" # Screen "Default Screen" # InputDevice "Generic Keyboard" # InputDevice "Configured Mouse" # # Uncomment if you have a wacom tablet # # InputDevice "stylus" "SendCoreEvents" # # InputDevice "cursor" "SendCoreEvents" # # InputDevice "eraser" "SendCoreEvents" # EndSection # # Section "extensions" # Option "Composite" "Enable" # EndSection _____________ ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From alexdeucher at gmail.com Thu Dec 13 19:58:02 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 13 Dec 2007 22:58:02 -0500 Subject: radeon 9000 (rv250) tV-out troubles In-Reply-To: <748141.40308.qm@web51801.mail.re2.yahoo.com> References: <748141.40308.qm@web51801.mail.re2.yahoo.com> Message-ID: On Dec 13, 2007 10:17 PM, Charles Hibbits wrote: > I realize this has been discussed to some degree, but I may not be understanding the instructions correctly so I apologize for another thread. I have an Sapphire Radeon 9000 64MB with TV out. Everything was running fine with the patched opensource driver on Ubuntu Feisty (xorg 7.2 I believe). Saturday I upgraded to Gutsy (xorg 7.3) and I lost the tv out. At first the gnome X configuration tool set it to a VESA driver which produced black and white TV out. When I use the XORG ATI driver the TV out goes away. > > After searching around I found the following commands can be issued to make it work sorta: > > # xrandr --addmode S-video 800x600 > # xrandr --output S-video --mode 800x600 > # xrandr --output S-video --set tv_standard ntsc > # xrandr --output S-video --off > # xrandr --output S-video --mode 800x600 > > http://lists.freedesktop.org/archive...er/029292.html > > The problem is this is not static, after reboot I loose the TV out again. Also My main usage of this computer is to run mythtv, but the video will not play on the TV, only the monitor. I assume this has something to do with it not being treated as a primary display or something to that effect. I assume there is something wrong with my xorg.conf, but I have not been able to find the right options. Here is my xorg.conf: You can force the TV on with the following options (add to the device section of your config): Option "ForceTVOut" "true" Option "TVStandard" "ntsc" As for the overlay, it can only be sourced to one crtc at a time. In dualhead mode it follows the video window. In clone mode you have to explicitly tell it which crtc to source to. Use an application like xvattr to select the crtc for the overlay: xvattr -a XV_CRTC -v 1 possible values: -1 auto 0 crtc0 1 crtc1 Alex From ewalsh at tycho.nsa.gov Thu Dec 13 19:06:15 2007 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 13 Dec 2007 22:06:15 -0500 Subject: XACE-SELINUX branch ready for merge In-Reply-To: <474F40CE.4090601@tycho.nsa.gov> References: <474F40CE.4090601@tycho.nsa.gov> Message-ID: <4761F327.9080704@tycho.nsa.gov> Eamon Walsh wrote: > The XACE-SELINUX branch contains a rework of the devPrivates system used > to store private data, a new version of the XACE (X Access Control > Extension) security hook framework, a protocol name registry, a reworked > XC-SECURITY extension (disabled by default), and an under-development > SELinux extension (also disabled by default). > > I've been running GNOME on it without any issues, all the major drivers > compile against it and I've tested with vesa and intel (and continue to > rebuild and test). I've put up the complete patchset with some basic > annotations at > http://people.freedesktop.org/~ewalsh/xace_selinux_merge_patch/ > > The total damage from the patch is 398 files changed, 7785 > insertions(+), 7604 deletions(-). I think it's about ready to land on > master; I have been working on the branch for 18 months and will > continue working in master. > > Comments? > I merged it. Time to recompile everything! Please notify me of any issues right away. Peter (and other branch developers): if you need help resolving conflicts when syncing up with master, point me to your branch head and I will help out. -- Eamon Walsh National Security Agency From alexdeucher at gmail.com Thu Dec 13 22:44:59 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 14 Dec 2007 01:44:59 -0500 Subject: XACE-SELINUX branch ready for merge In-Reply-To: <4761F327.9080704@tycho.nsa.gov> References: <474F40CE.4090601@tycho.nsa.gov> <4761F327.9080704@tycho.nsa.gov> Message-ID: On Dec 13, 2007 10:06 PM, Eamon Walsh wrote: > Eamon Walsh wrote: > > The XACE-SELINUX branch contains a rework of the devPrivates system used > > to store private data, a new version of the XACE (X Access Control > > Extension) security hook framework, a protocol name registry, a reworked > > XC-SECURITY extension (disabled by default), and an under-development > > SELinux extension (also disabled by default). > > > > I've been running GNOME on it without any issues, all the major drivers > > compile against it and I've tested with vesa and intel (and continue to > > rebuild and test). I've put up the complete patchset with some basic > > annotations at > > http://people.freedesktop.org/~ewalsh/xace_selinux_merge_patch/ > > > > The total damage from the patch is 398 files changed, 7785 > > insertions(+), 7604 deletions(-). I think it's about ready to land on > > master; I have been working on the branch for 18 months and will > > continue working in master. > > > > Comments? > > > > I merged it. Time to recompile everything! Please notify me of any > issues right away. Congrats Eamon! nice to see this finally merged. Alex From justin at mythtvthemes.co.uk Fri Dec 14 01:05:31 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Fri, 14 Dec 2007 09:05:31 +0000 Subject: Intel TV output problems - color pulsing In-Reply-To: <55746.64.213.30.2.1197588221.squirrel@webmail.exetel.com.au> References: <47613577.1050707@fascinationsoftware.com> <476145F0.7080206@mythtvthemes.co.uk> <47614ED1.20909@fascinationsoftware.com> <55746.64.213.30.2.1197588221.squirrel@webmail.exetel.com.au> Message-ID: <4762475B.9030806@mythtvthemes.co.uk> Robert Lowery wrote: >> Justin Hornsby wrote: >> >>> Regarding the pulsing effect on the colour of the composite output - at >>> least as far as the PAL video modes are concerned the driver needs >>> patched. I mean to raise a ticket in bugzilla for this but other stuff >>> keeps getting in the way. >>> >>> Anyway in i830_tv.c a value of 286 needs changing to 288 (somewhere in >>> the "PAL" section). that solved the problem for me. >>> > > Looking at the code, I'm not sure this fix is enough. > > Later code has > 1209 if (tv_mode->progressive) > 1210 ysize = tv_mode->nbr_end + 1; > 1211 else > 1212 ysize = 2*tv_mode->nbr_end + 1; > > So using > 286 would result in a ysize = 573 > 288 would result in a ysize = 577 > > ie neither are right (576). Hopefully someone with doco can comment. > > >> Yeah, I saw the posting about this on the list. I have an NTSC setup, >> though. Perhaps a similar bug affects both formats? >> >> Richard >> _______________________________________________ >> xorg mailing list >> xorg at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg >> >> It was certainly enough to fix the issue on my setup and from everything I could measure it was still a perfectly legal PAL video signal. As things are now, it isn't, or some TV PLLs wouldn't have problems locking onto the colour burst signal. From simon.farnsworth at onelan.co.uk Fri Dec 14 01:16:34 2007 From: simon.farnsworth at onelan.co.uk (Simon Farnsworth) Date: Fri, 14 Dec 2007 09:16:34 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <1197577637.30771.113.camel@localhost.localdomain> References: <47614B61.7060906@onelan.co.uk> <1197577637.30771.113.camel@localhost.localdomain> Message-ID: <476249F2.7010007@onelan.co.uk> Adam Jackson wrote: > On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: >> We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an >> Intel 965Q and the xf86-video-intel driver, on Fedora 8. >> > It's not clear from your description whether you're trying to drive this > monitor with DVI or VGA. I suspect DVI, in which case, the 965 log > shows something going wildly wrong in mode selection: > Sorry; should have made that clear. It's an analogue VGA connection, same as we use for the 945. -- Simon Farnsworth From alanh at fairlite.demon.co.uk Fri Dec 14 01:36:47 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 14 Dec 2007 09:36:47 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <47614B61.7060906@onelan.co.uk> References: <47614B61.7060906@onelan.co.uk> Message-ID: <1197625007.16934.33.camel@localhost> On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: > Hello, > > We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an > Intel 965Q and the xf86-video-intel driver, on Fedora 8. > > We've previously managed to make a 945 chip drive this display at 1080p, > using the i810 driver (version 1.6.0). Switching one of these machines > to the intel driver (either git HEAD, or 2.1.1 as shipped with Fedora), > or using the 965, causes the display to be unable to lock to the image. > > I've attached a log from the 965 (doesn't work, but is using a newer > X.org and the intel driver), and from the working 945 (using an old > X.org and the i810 driver), together with the EDID data from the > display. Any clues would be welcome; I'm obviously happy to try anything > people can suggest that might solve this problem. Hi Simon, It's probably the the driver is trying to drive your TV with that 173Mhz pixel clocked 1920x1080 at 60Hz mode instead of the 1920x180 at 59.9 with a 138.5MHz clock. I'm pretty sure most TV's will want the "Reduced blank" version. So if you force the Xserver to use that alternative mode, you should be o.k. Alan. From simon.farnsworth at onelan.co.uk Fri Dec 14 02:07:11 2007 From: simon.farnsworth at onelan.co.uk (Simon Farnsworth) Date: Fri, 14 Dec 2007 10:07:11 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <1197625007.16934.33.camel@localhost> References: <47614B61.7060906@onelan.co.uk> <1197625007.16934.33.camel@localhost> Message-ID: <476255CF.5040302@onelan.co.uk> Alan Hourihane wrote: > On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: >> We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an >> Intel 965Q and the xf86-video-intel driver, on Fedora 8. >> > It's probably the the driver is trying to drive your TV with that 173Mhz > pixel clocked 1920x1080 at 60Hz mode instead of the 1920x180 at 59.9 with a > 138.5MHz clock. > > I'm pretty sure most TV's will want the "Reduced blank" version. > > So if you force the Xserver to use that alternative mode, you should be > o.k. > > Alan. Allowing the driver to use DDC makes it work, so I suspect your "reduced blank" hunch is right. How do I generate a modeline with "reduced blank"? The reason we have to do this with a modeline is that we connect our displays using VGA extenders and splitters that don't pass DDC to connect multiple identical displays to one box. -- Simon Farnsworth From alanh at fairlite.demon.co.uk Fri Dec 14 02:15:17 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 14 Dec 2007 10:15:17 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <476255CF.5040302@onelan.co.uk> References: <47614B61.7060906@onelan.co.uk> <1197625007.16934.33.camel@localhost> <476255CF.5040302@onelan.co.uk> Message-ID: <1197627317.16934.42.camel@localhost> On Fri, 2007-12-14 at 10:07 +0000, Simon Farnsworth wrote: > Alan Hourihane wrote: > > On Thu, 2007-12-13 at 15:10 +0000, Simon Farnsworth wrote: > >> We're trying to drive a Samsung LE40M87BDX/XEU 1080p LCD TV with an > >> Intel 965Q and the xf86-video-intel driver, on Fedora 8. > >> > > It's probably the the driver is trying to drive your TV with that 173Mhz > > pixel clocked 1920x1080 at 60Hz mode instead of the 1920x180 at 59.9 with a > > 138.5MHz clock. > > > > I'm pretty sure most TV's will want the "Reduced blank" version. > > > > So if you force the Xserver to use that alternative mode, you should be > > o.k. > > > > Alan. > > Allowing the driver to use DDC makes it work, so I suspect your "reduced > blank" hunch is right. How do I generate a modeline with "reduced blank"? > > The reason we have to do this with a modeline is that we connect our > displays using VGA extenders and splitters that don't pass DDC to > connect multiple identical displays to one box. The 1920x1080 mode you already have with the 138.5MHz pixel clock is already the "reduced blank" mode. You just have to make sure that the 173MHz pixel clock mode is removed, or you change the name of the 138.5MHz clock to something like 1920x1080R and force that in your selection. Alan. From simon.farnsworth at onelan.co.uk Fri Dec 14 02:38:05 2007 From: simon.farnsworth at onelan.co.uk (Simon Farnsworth) Date: Fri, 14 Dec 2007 10:38:05 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <1197627317.16934.42.camel@localhost> References: <47614B61.7060906@onelan.co.uk> <1197625007.16934.33.camel@localhost> <476255CF.5040302@onelan.co.uk> <1197627317.16934.42.camel@localhost> Message-ID: <47625D0D.80703@onelan.co.uk> Alan Hourihane wrote: > On Fri, 2007-12-14 at 10:07 +0000, Simon Farnsworth wrote: >> Allowing the driver to use DDC makes it work, so I suspect your "reduced >> blank" hunch is right. How do I generate a modeline with "reduced blank"? >> > The 1920x1080 mode you already have with the 138.5MHz pixel clock is > already the "reduced blank" mode. You just have to make sure that the > 173MHz pixel clock mode is removed, or you change the name of the > 138.5MHz clock to something like 1920x1080R and force that in your > selection. This works. We've added some extra text to our custom modelines, to ensure that they'll never have the same name as a built-in modeline. -- Thanks for the help, Simon Farnsworth From justin at mythtvthemes.co.uk Fri Dec 14 03:39:23 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Fri, 14 Dec 2007 11:39:23 +0000 Subject: Intel TV output problems - color pulsing In-Reply-To: <55746.64.213.30.2.1197588221.squirrel@webmail.exetel.com.au> References: <47613577.1050707@fascinationsoftware.com> <476145F0.7080206@mythtvthemes.co.uk> <47614ED1.20909@fascinationsoftware.com> <55746.64.213.30.2.1197588221.squirrel@webmail.exetel.com.au> Message-ID: <47626B6B.3090700@mythtvthemes.co.uk> Robert Lowery wrote: >> Justin Hornsby wrote: >> >>> Regarding the pulsing effect on the colour of the composite output - at >>> least as far as the PAL video modes are concerned the driver needs >>> patched. I mean to raise a ticket in bugzilla for this but other stuff >>> keeps getting in the way. >>> >>> Anyway in i830_tv.c a value of 286 needs changing to 288 (somewhere in >>> the "PAL" section). that solved the problem for me. >>> > > Looking at the code, I'm not sure this fix is enough. > > Later code has > 1209 if (tv_mode->progressive) > 1210 ysize = tv_mode->nbr_end + 1; > 1211 else > 1212 ysize = 2*tv_mode->nbr_end + 1; > > So using > 286 would result in a ysize = 573 > 288 would result in a ysize = 577 > > ie neither are right (576). Hopefully someone with doco can comment. > > >> Yeah, I saw the posting about this on the list. I have an NTSC setup, >> though. Perhaps a similar bug affects both formats? >> >> Richard >> _______________________________________________ >> xorg mailing list >> xorg at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg >> >> I have to admit I'm not all that good at understanding the source - but as far as video signal specs are concerned I can recommend reading 'Video Demystified' by Keith Jack, ISBN-10 0750683953 regards, Justin From dr-xorg at bcsoft.de Fri Dec 14 04:35:41 2007 From: dr-xorg at bcsoft.de (Jens Stroebel) Date: Fri, 14 Dec 2007 13:35:41 +0100 Subject: build.sh run fails with current xserver git "configure.ac:60: ...`SED' previously defined here" Message-ID: <4762789D.6030807@bcsoft.de> Hi all. When trying to build xserver via build.sh, the autoconf run initiated by autogen.sh fails here because of commit cb0d7e2c2692a332e2bd5495478ebf9a6cd601d0 , because hw/xquartz/bundle/Makefile.am now includes ### snip ### include $(top_srcdir)/cpprules.in ### snip ### which results in a re-definition of SED (?) error. Exact error is: ################################################# cpprules.in:5: SED was already defined in condition TRUE, which includes condition LAUNCHD ... hw/xquartz/bundle/Makefile.am:19: `cpprules.in' included from here configure.ac:60: ... `SED' previously defined here autoreconf: automake failed with exit status: 1 ################################################# greets, drifter -- dr-xorg at bcsoft.de 23.....56.......drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion From matteo.brusa at kaasa.com Fri Dec 14 05:49:44 2007 From: matteo.brusa at kaasa.com (Matteo Brusa) Date: Fri, 14 Dec 2007 14:49:44 +0100 Subject: Output problems with 945GM In-Reply-To: <200712101738.19906.jbarnes@virtuousgeek.org> References: <4757FF1F.4060500@kaasa.com> <200712061041.27890.jbarnes@virtuousgeek.org> <4759752C.9000205@kaasa.com> <200712101738.19906.jbarnes@virtuousgeek.org> Message-ID: <476289F8.40608@kaasa.com> Jesse Barnes wrote: > On Friday, December 07, 2007 8:30 am Matteo Brusa wrote: >> Hi Jesse, thanks for the answer. >> See my inline comments. >> >> Jesse Barnes wrote: >>> On Thursday, December 06, 2007 5:54 am Matteo Brusa wrote: >>>> Hi, >>>> i have some HDTV configuration issues with my 945GM based pc, i hope i'm >>>> in the right place to ask. I'm running Ubuntu 7.10 and therefore the >>>> intel driver version 2:2.1.1-0ubuntu9. >>>> >>>> VGA output >>>> The VGA output works great, it uses the 1360x768 resolution when plugged >>>> to an HDTV. Unfortunately, my actual TV has no VGA input, so i'm trying >>>> to get either HDMI (with DVI adapter cable) or component running. >>>> LDVS >>>> In X, LVDS is always enabled although i have no LCD screen. I tried >>>> "xrandr --ouput LDVS --off" without success, and the intel module does >>>> not support any xorg.conf option to shut it off. Could this be the >>>> reason why xvidtune always shows 1024x768 and not the actual screen >>>> value? Component I always get 1024x768, no matter which Modeline i >>>> specify. Any suggestion? >>> You actually can disable it: >>> >>> Section "Monitor" >>> Identifier "Bogus LCD" >>> Option "ignore" "true" >>> EndSection >>> >>> Section "Driver" >>> Identifier "Card0" >>> Driver "intel" >>> VendorName "Intel Corporation" >>> BoardName "Unknown Board" >>> Option "Monitor-LVDS" "Bogus LCD" >>> EndSection >>> >>> And since we've been getting so many reports about this stuff and always >>> end up pointing people at >>> http://www.intellinuxgraphics.org/dualhead.html, I think I'll update the >>> man page with some more detail... >> Great, this works. >> That would be really helpful to have this mentioned in the man page. > > I added some more detail to the git tree, hopefully it'll help head off future > FAQs. :) > >>>> TDMS-1 >>>> I got 1280x768 working, with noticeable overscan. How can i use the same >>>> 1360x768 with DVI, or get rid of the overscan? >>> What's the output of 'xrandr'? >> Here's the snippet relative to this output: >> TMDS-1 connected 1280x720+0+0 (0x62) normal (normal left inverted right) >> 160mm x 90mm Identifier: 0x4e >> Timestamp: -1361725529 >> Subpixel: horizontal rgb >> Clones: >> CRTC: 0 >> CRTCs: 0 1 >> EDID_DATA: >> 00ffffffffffff004c2d000200000000 >> 2a0f01038010098c0ae2bda15b4a9824 >> 15474a20000001010101010101010101 >> 010101010101011d007251d01e206e28 >> 5500a05a0000001e011d00bc52d01e20 >> b8285540a05a0000001e000000fd0032 >> 3d0f2e08000a202020202020000000fc >> 0053414d53554e470a202020202001af >> 1280x720 (0x62) 74.2MHz +HSync +VSync >> h: width 1280 start 1390 end 1430 total 1650 skew 0 clock >> 45.0KHz v: height 720 start 725 end 730 total 750 clock >> 60.0Hz 1280x720 (0x63) 74.2MHz +HSync +VSync >> h: width 1280 start 1720 end 1760 total 1980 skew 0 clock >> 37.5KHz v: height 720 start 725 end 730 total 750 clock >> 50.0Hz 640x480 (0x64) 25.2MHz -HSync -VSync >> h: width 640 start 656 end 752 total 800 skew 0 clock >> 31.5KHz v: height 480 start 490 end 492 total 525 clock >> 60.0Hz > > Hm, I think using DVI is your best bet (it'll probably give you the best > picture quality) but your TV doesn't seem to provide a 1360x768 resolution in > its EDID data? Or are you overriding it somehow? > > Can you post your xorg.conf and Xorg.0.log files? I auto reconfigured X with the VGA cable plugged, see attached file. Interesting note, when connected via the DVI-HDMI cable, the monitor offers no EDID info whatsoever. I also attach the Xorg.0.log files for both VGA and TDMI-1. The VGA output clearly runs at 1360x768 without overscan, while the TDMI-1 runs at 1280x720 with overscan. Still i couldn't reach digital 1360x768. Is it true, that in order to accept my custom modelines, i have to specify 'Option "DDC" "off"' in the device section? Last but not least, is there an 'official' Modeline for 1920x1080p? As always, any help will be mostly appreciated. Matteo -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.VGA URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log.VGA URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log.TDMI-1 URL: From rafaelmejiasc at gmail.com Fri Dec 14 06:11:45 2007 From: rafaelmejiasc at gmail.com (=?ISO-8859-1?Q?Rafael_Mej=EDas?=) Date: Sat, 15 Dec 2007 09:41:45 +1930 Subject: Resolution problem with i810 (FIXED) Message-ID: <2f96467a0712140611l433d29wdd032b2360ab1378@mail.gmail.com> 2007/12/13, Jesse Barnes : > So you could either try using something like i915resolution to reprogram > your 1024x768 mode into something that might work on your LCD or you I've already done that with no effect. Don't worry. I finally fixed it using an extreme measure: changed the repositories to Lenny, updated apt, and installed the new intel driver (xserver-xorg-video-intel). It changed a lot of stuff into my system but it now works. Of course I changed sources.list back to Etch... Lets hope it doesn't break. Now my laptop is officially a hybrid :-D Thanks everybody. From puneet.maillist at gmail.com Fri Dec 14 06:15:14 2007 From: puneet.maillist at gmail.com (Puneet Goel) Date: Fri, 14 Dec 2007 19:45:14 +0530 Subject: Desktop screen corruption (AMD LX driver) Message-ID: <4b08f1290712140615g2a19b159l9f6f3e2d88e7ccf5@mail.gmail.com> Dear all I am having a customised linux distribution installed on a thin client with the following configuration. AMD LX800 128MB RAM Xorg version 7.2 The display driver that I am using is from xorg git http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary I am facing the problem that when I am using a Citrix published application, while dragging the application window over the desktop, the desktop is being corrupted. I am attaching a screenshot for the same. However a dragging a local desktop window is working fine. My xorg.conf file is also attached . Any pointers to the solution of the above problem ? With best regards Puneet Goel -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.JPG Type: image/jpeg Size: 71110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 3213 bytes Desc: not available URL: From glisse at freedesktop.org Fri Dec 14 06:25:06 2007 From: glisse at freedesktop.org (Jerome Glisse) Date: Fri, 14 Dec 2007 15:25:06 +0100 Subject: Improving rotated ATI performance In-Reply-To: References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> Message-ID: <20071214152506.11f1bdde.glisse@freedesktop.org> On Thu, 13 Dec 2007 13:24:22 -0500 "Alex Deucher" wrote: > On Dec 13, 2007 1:19 PM, Adr3nal D0S wrote: > > On Dec 13, 2007 11:37 AM, Alex Deucher wrote: > > > > > rotation can use EXA composite to accelerate transforms, so you'll > > > have to use EXA. For r1xx-r2xx the composite code is written, but > > > there are some bug when doing transforms, so it doesn't work properly > > > for rotation. for r3xx and newer, the code needs to be written. > > > there should be enough info available for r3xx-r4xx in the 3D driver > > > to add composite support, but no one has done the work yet. > > > > I've done a fair amount of OpenGL over the years, but haven't dealt > > with 3D much at the hardware level. Am I correct that 3D acceleration > > only works up to a maximum virtual size of 2048x2048? If so, does this > > mean it would be impossible to have accelerated compositing under EXA > > for larger virtuals? > > It depends on the hardware. r1xx and r2xx had 2048 3d coordinate > limits and tiling surface limits. r3xx/r4xx are 4096. textures are > limited to 2048 on r1xx-r4xx. Alex would be good if you can double check but r300 hw i got can't properly render 3d above 2650x2650 (offset things you can see in the drm). As side note fglrx doesn't render properly above this limit. So i think we should change advertized viewport size to 2650, i will do that soon if no one object with valid arguments. We still can work around this but doing it with current mesa infrastructure is likely too much pain to be worth it. Likely a lot easier to work around this in exa. Cheers, Jerome Glisse From ajax at nwnk.net Fri Dec 14 07:11:29 2007 From: ajax at nwnk.net (Adam Jackson) Date: Fri, 14 Dec 2007 10:11:29 -0500 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <1197577637.30771.113.camel@localhost.localdomain> References: <47614B61.7060906@onelan.co.uk> <1197577637.30771.113.camel@localhost.localdomain> Message-ID: <1197645089.30771.135.camel@localhost.localdomain> On Thu, 2007-12-13 at 15:27 -0500, Adam Jackson wrote: > > (II) intel(0): SDVO device VID/DID: 04:AA.03, clock range 25.0MHz - 165.0MHz, input 1: Y, input 2: N, output 1: Y, output 2: N > > <...> > > (II) intel(0): EDID for output VGA > > <...> > > (II) intel(0): Modeline "1920x1080"x60.0 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync (67.2 kHz) > > I can't think of a situation where that mode is ever valid. I suspect > it's inherited from the extra modes list in Fedora; I'll check and patch > it out if so. I was right, there was a 1920x1080 non-RB mode in the extramodes list. I've ripped that out in xorg-x11-server 1.3.0.0-37.fc8, which should be on its way to testing now. - ajax -------------- 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 alexdeucher at gmail.com Fri Dec 14 07:45:30 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 14 Dec 2007 10:45:30 -0500 Subject: Improving rotated ATI performance In-Reply-To: <20071214152506.11f1bdde.glisse@freedesktop.org> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> Message-ID: On Dec 14, 2007 9:25 AM, Jerome Glisse wrote: > On Thu, 13 Dec 2007 13:24:22 -0500 > "Alex Deucher" wrote: > > > On Dec 13, 2007 1:19 PM, Adr3nal D0S wrote: > > > On Dec 13, 2007 11:37 AM, Alex Deucher wrote: > > > > > > > rotation can use EXA composite to accelerate transforms, so you'll > > > > have to use EXA. For r1xx-r2xx the composite code is written, but > > > > there are some bug when doing transforms, so it doesn't work properly > > > > for rotation. for r3xx and newer, the code needs to be written. > > > > there should be enough info available for r3xx-r4xx in the 3D driver > > > > to add composite support, but no one has done the work yet. > > > > > > I've done a fair amount of OpenGL over the years, but haven't dealt > > > with 3D much at the hardware level. Am I correct that 3D acceleration > > > only works up to a maximum virtual size of 2048x2048? If so, does this > > > mean it would be impossible to have accelerated compositing under EXA > > > for larger virtuals? > > > > It depends on the hardware. r1xx and r2xx had 2048 3d coordinate > > limits and tiling surface limits. r3xx/r4xx are 4096. textures are > > limited to 2048 on r1xx-r4xx. > > Alex would be good if you can double check but r300 hw i got can't > properly render 3d above 2650x2650 (offset things you can see in the > drm). As side note fglrx doesn't render properly above this limit. > So i think we should change advertized viewport size to 2650, i > will do that soon if no one object with valid arguments. > you are right the r3xx r4xx car limited to 2560. I forgot about that. Go ahead and fix that up. Alex From sroland at tungstengraphics.com Fri Dec 14 07:57:46 2007 From: sroland at tungstengraphics.com (Roland Scheidegger) Date: Fri, 14 Dec 2007 16:57:46 +0100 Subject: Improving rotated ATI performance In-Reply-To: References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> Message-ID: <4762A7FA.2080906@tungstengraphics.com> Alex Deucher wrote: > On Dec 14, 2007 9:25 AM, Jerome Glisse wrote: >> On Thu, 13 Dec 2007 13:24:22 -0500 >> "Alex Deucher" wrote: >> >>> On Dec 13, 2007 1:19 PM, Adr3nal D0S wrote: >>>> On Dec 13, 2007 11:37 AM, Alex Deucher wrote: >>>> >>>>> rotation can use EXA composite to accelerate transforms, so you'll >>>>> have to use EXA. For r1xx-r2xx the composite code is written, but >>>>> there are some bug when doing transforms, so it doesn't work properly >>>>> for rotation. for r3xx and newer, the code needs to be written. >>>>> there should be enough info available for r3xx-r4xx in the 3D driver >>>>> to add composite support, but no one has done the work yet. >>>> I've done a fair amount of OpenGL over the years, but haven't dealt >>>> with 3D much at the hardware level. Am I correct that 3D acceleration >>>> only works up to a maximum virtual size of 2048x2048? If so, does this >>>> mean it would be impossible to have accelerated compositing under EXA >>>> for larger virtuals? >>> It depends on the hardware. r1xx and r2xx had 2048 3d coordinate >>> limits and tiling surface limits. r3xx/r4xx are 4096. textures are >>> limited to 2048 on r1xx-r4xx. >> Alex would be good if you can double check but r300 hw i got can't >> properly render 3d above 2650x2650 (offset things you can see in the >> drm). As side note fglrx doesn't render properly above this limit. >> So i think we should change advertized viewport size to 2650, i >> will do that soon if no one object with valid arguments. >> > > you are right the r3xx r4xx car limited to 2560. I forgot about that. > Go ahead and fix that up. Is this really true for all r3xx and r4xx cards? I thought at least some r4xx cards could do more. Roland From adr3nald0s at gmail.com Fri Dec 14 07:58:39 2007 From: adr3nald0s at gmail.com (Adr3nal D0S) Date: Fri, 14 Dec 2007 09:58:39 -0600 Subject: Improving rotated ATI performance In-Reply-To: References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> Message-ID: <308083c30712140758q4f8f4faeme430d1c64ad4a550@mail.gmail.com> On Dec 14, 2007 9:45 AM, Alex Deucher wrote: > On Dec 14, 2007 9:25 AM, Jerome Glisse wrote: > > > > Alex would be good if you can double check but r300 hw i got can't > > properly render 3d above 2650x2650 (offset things you can see in the > > drm). As side note fglrx doesn't render properly above this limit. > > So i think we should change advertized viewport size to 2650, i > > will do that soon if no one object with valid arguments. > > you are right the r3xx r4xx car limited to 2560. I forgot about that. > Go ahead and fix that up. I don't completely understand this part of the discussion. But, will it prevent me from having a Virtual of 3520 1920 with GLX loaded. Granted it seems to be falling back to software-based GL, but that's fine for my usage. From John.Yoder at amd.com Fri Dec 14 07:58:17 2007 From: John.Yoder at amd.com (Yoder, John) Date: Fri, 14 Dec 2007 09:58:17 -0600 Subject: FW: Desktop screen corruption (AMD LX driver) Message-ID: <9E1304B144EBEB4C97F4162BFAC47886DDCEED@SAUSEXMB2.amd.com> Punett, >From the attachment it appears that it is happening from the 4 corners of the box. I wasn't able to determine whether you are pulling the desktop or a single application (Note pad) from the Citrix server. Also, it would help to know which versions of Citrix Server and Citrix Client Application you are using. Another item would be how you are invoking the client. Sorry that I'm resending the attachments again but we there is a new list on xorg [xorg-driver-geode at lists.x.org] which I'm adding to distribution. That list will give you more direct access to the Maintainers of this driver. Regards, John Yoder -----Original Message----- From: xorg-bounces at lists.freedesktop.org [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of Puneet Goel Sent: Friday, December 14, 2007 7:15 AM To: xorg at lists.freedesktop.org Subject: Desktop screen corruption (AMD LX driver) Dear all I am having a customised linux distribution installed on a thin client with the following configuration. AMD LX800 128MB RAM Xorg version 7.2 The display driver that I am using is from xorg git http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summar y I am facing the problem that when I am using a Citrix published application, while dragging the application window over the desktop, the desktop is being corrupted. I am attaching a screenshot for the same. However a dragging a local desktop window is working fine. My xorg.conf file is also attached . Any pointers to the solution of the above problem ? With best regards Puneet Goel -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.JPG Type: image/jpeg Size: 71110 bytes Desc: screenshot.JPG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 3214 bytes Desc: xorg.conf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT46634425.txt URL: From glisse at freedesktop.org Fri Dec 14 08:17:31 2007 From: glisse at freedesktop.org (Jerome Glisse) Date: Fri, 14 Dec 2007 17:17:31 +0100 Subject: Improving rotated ATI performance In-Reply-To: <308083c30712140758q4f8f4faeme430d1c64ad4a550@mail.gmail.com> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> <308083c30712140758q4f8f4faeme430d1c64ad4a550@mail.gmail.com> Message-ID: <20071214171731.27f3522e.glisse@freedesktop.org> On Fri, 14 Dec 2007 09:58:39 -0600 "Adr3nal D0S" wrote: > On Dec 14, 2007 9:45 AM, Alex Deucher wrote: > > On Dec 14, 2007 9:25 AM, Jerome Glisse wrote: > > > > > > Alex would be good if you can double check but r300 hw i got can't > > > properly render 3d above 2650x2650 (offset things you can see in the > > > drm). As side note fglrx doesn't render properly above this limit. > > > So i think we should change advertized viewport size to 2650, i > > > will do that soon if no one object with valid arguments. > > > > you are right the r3xx r4xx car limited to 2560. I forgot about that. > > Go ahead and fix that up. > > I don't completely understand this part of the discussion. But, will > it prevent me from having a Virtual of 3520 1920 with GLX loaded. > Granted it seems to be falling back to software-based GL, but that's > fine for my usage. Well it will prevent you to render to any viewport bigger than 2560 ie you won't be able to have glx app with screen size bigger than 2560 in either x or y direction. So for instance no compiz at such resolution. There is two work around for this: - in the application split rendering into several tile which followh the 2560 constraint. - hack the driver to split rendering into several tile this need that you resumit cmd as many times as there is tiles and adjust viewport to render to a given tile each time. I think the second solution is painfull to implement with current mesa infrastructure, it might be a lot easier in gallium with a proper memory management. Cheers, Jerome Glisse From glisse at freedesktop.org Fri Dec 14 08:22:50 2007 From: glisse at freedesktop.org (Jerome Glisse) Date: Fri, 14 Dec 2007 17:22:50 +0100 Subject: Improving rotated ATI performance In-Reply-To: <4762A7FA.2080906@tungstengraphics.com> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> <4762A7FA.2080906@tungstengraphics.com> Message-ID: <20071214172250.55f7738c.glisse@freedesktop.org> On Fri, 14 Dec 2007 16:57:46 +0100 Roland Scheidegger wrote: > Alex Deucher wrote: > > On Dec 14, 2007 9:25 AM, Jerome Glisse wrote: > >> On Thu, 13 Dec 2007 13:24:22 -0500 > >> "Alex Deucher" wrote: > >> > >>> On Dec 13, 2007 1:19 PM, Adr3nal D0S wrote: > >>>> On Dec 13, 2007 11:37 AM, Alex Deucher wrote: > >>>> > >>>>> rotation can use EXA composite to accelerate transforms, so you'll > >>>>> have to use EXA. For r1xx-r2xx the composite code is written, but > >>>>> there are some bug when doing transforms, so it doesn't work properly > >>>>> for rotation. for r3xx and newer, the code needs to be written. > >>>>> there should be enough info available for r3xx-r4xx in the 3D driver > >>>>> to add composite support, but no one has done the work yet. > >>>> I've done a fair amount of OpenGL over the years, but haven't dealt > >>>> with 3D much at the hardware level. Am I correct that 3D acceleration > >>>> only works up to a maximum virtual size of 2048x2048? If so, does this > >>>> mean it would be impossible to have accelerated compositing under EXA > >>>> for larger virtuals? > >>> It depends on the hardware. r1xx and r2xx had 2048 3d coordinate > >>> limits and tiling surface limits. r3xx/r4xx are 4096. textures are > >>> limited to 2048 on r1xx-r4xx. > >> Alex would be good if you can double check but r300 hw i got can't > >> properly render 3d above 2650x2650 (offset things you can see in the > >> drm). As side note fglrx doesn't render properly above this limit. > >> So i think we should change advertized viewport size to 2650, i > >> will do that soon if no one object with valid arguments. > >> > > > > you are right the r3xx r4xx car limited to 2560. I forgot about that. > > Go ahead and fix that up. > Is this really true for all r3xx and r4xx cards? I thought at least some > r4xx cards could do more. > > Roland I don't have r4xx hw anymore :( but as this restriction looks like a hw bug this might effectively mean that r4xx can do more and reach 4096. I know that r5xx can do 4096 (maybe even more but i can remember up to what). Cheers, Jerome Glisse From puneet.maillist at gmail.com Fri Dec 14 08:49:43 2007 From: puneet.maillist at gmail.com (Puneet Goel) Date: Fri, 14 Dec 2007 22:19:43 +0530 Subject: FW: Desktop screen corruption (AMD LX driver) In-Reply-To: <9E1304B144EBEB4C97F4162BFAC47886DDCEED@SAUSEXMB2.amd.com> References: <9E1304B144EBEB4C97F4162BFAC47886DDCEED@SAUSEXMB2.amd.com> Message-ID: <4b08f1290712140849y65856709gbcaca10911c34e60@mail.gmail.com> Hello John, Thanks for the quick reply. You are right. It is happening at the 4 corners of the app. I was dragging Notepad application on my desktop when i saw this behavior. All the 4 corners of the notepad window were leaving trail behind on desktop. If i refresh desktop everything becomes normal but dragging notepad application again corrupted desktop. However if the drag any of the native linux application which are installed on my system, it works perfectly fine. I shall try to do more testing on this by publishing some other apps as well. My host linux system is having Citrix ICA client 9.0. and server is citrix presentation (metaframe) 4.5. There is a standard way of publishing application via citrix server and that is what i am also following. Is there any other info i need to provide ? Regards, Puneet On 12/14/07, Yoder, John wrote: > Punett, > > From the attachment it appears that it is happening from the 4 corners > of the box. I wasn't able to determine whether you are pulling the > desktop or a single application (Note pad) from the Citrix server. Also, > it would help to know which versions of Citrix Server and Citrix Client > Application you are using. Another item would be how you are invoking > the client. > > Sorry that I'm resending the attachments again but we there is a new > list on xorg [xorg-driver-geode at lists.x.org] which I'm adding to > distribution. That list will give you more direct access to the > Maintainers of this driver. > > Regards, > > John Yoder > > -----Original Message----- > From: xorg-bounces at lists.freedesktop.org > [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of Puneet Goel > Sent: Friday, December 14, 2007 7:15 AM > To: xorg at lists.freedesktop.org > Subject: Desktop screen corruption (AMD LX driver) > > Dear all > > I am having a customised linux distribution installed on a thin client > with the following configuration. > > AMD LX800 > 128MB RAM > Xorg version 7.2 > > The display driver that I am using is from xorg git > http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summar > y > > I am facing the problem that when I am using a Citrix published > application, while dragging the application window over the desktop, > the desktop is being corrupted. I am attaching a screenshot for the > same. However a dragging a local desktop window is working fine. > > My xorg.conf file is also attached . > > Any pointers to the solution of the above problem ? > > With best regards > Puneet Goel > > From aarg at shaw.ca Fri Dec 14 08:51:07 2007 From: aarg at shaw.ca (David Csercsics) Date: Fri, 14 Dec 2007 08:51:07 -0800 Subject: Intel 945g not sure how to configure this Message-ID: <20071214165107.5497A37003@really.isa-geek.net> I have a bit of an odd setup here which broke with xorg 7.3. I have an Intel 945g chip and Xorg -configure recommended that I use the intel driver. However I get the following when I test the configuration it creates: X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.23-gentoo-r3 x86_64 Current Operating System: Linux really 2.6.23-gentoo-r3 #1 SMP PREEMPT Thu Dec 13 14:11:40 PST 2007 x86_64 Build Date: 13 December 2007 04:08:03PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Fri Dec 14 06:59:13 2007 (++) Using config file: "/root/xorg.conf.new" (WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found (II) Module "ddc" already built-in (II) Module "i2c" already built-in (EE) intel(0): No valid modes. (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I know that part of the problem is that I don't have a monitor attached to the box. In the past I could just put in a frequency and refresh rate and such for a monitor that it could use and it found the modes just fine. All I am really needing X for is to run the gnome desktop for a few things. Mostly typical desktop stuff but I usually do almost everything from gnome-terminal because I like higher resolution text terminals so lots of stuff fits on my console. I don't really care what it looks like because I'm just using the screenreader. I just want a nicely performing X so that gnome is happy. I could use vesa or something but I am not sure which driver and configuration is the best for performance in this situation. I know that the problem is monitor-related because I can plug one in and X nicely detects all the modes and things and it works. But I don't have enough room on my desk for a monitor that's just going to waste power and get in the way of my braille display so it would be convenient if I could work something out. I don't know anything about graphics hardware either. I only have a video card because the PC won't boot if you don't have one. If somebody could help me configure this correctly this would be good. I'm not even sure what to read at this point. Thanks for reading this and if there is anything else you need let me know. It should be fairly simple to sort out I just don't know what I'm looking for and I didn't want to post a bunch of logs that wouldn't be useful though I have them if you really want them. From daniel.naughton at gmail.com Fri Dec 14 09:25:21 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Fri, 14 Dec 2007 11:25:21 -0600 Subject: intel driver for 945GM multihead question - some progress Message-ID: Still haven't gotten the dual independent displays working, although I think I'm close. I redid the xorg.conf file like the dualhead.html docs stated, and I seem to have gotten most of the errors out the Xorg.0.log file. Defining a monitor for each of the five outputs and Ignoring them seems have mostly worked. But I still have three cloned displays (VGA, TMDS-1, TMDS-2) even though I thought I shut the VGA off, and setup TDMS-2 RightOf TMDS-1 in the ServerLayout. So the trouble seems to be: - The RightOf statement in the ServerLayout doesn't seem to do anything - The Ignore True for the VGA Monitor seems to be accepted (per the log file) then ignored (the monitor comes up). I'm still getting this in the log file (whole log file and xorg.conf are attached): $ cat /var/log/Xorg.0.log | grep Pipe (II) intel(0): Pipe A is on (II) intel(0): Pipe B is off $ cat /var/log/Xorg.0.log | grep pipe (II) intel(0): 2 display pipes available. (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TMDS-2 is connected to pipe A <======= I think that if they are independent, this should be "B" There are still a few errors, but I'm not sure what these errors mean? $ cat /var/log/Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (II) Loading extension MIT-SCREEN-SAVER (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOC Slave 0x72. (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOC Slave 0x72. I'm going to try playing around with the Xinerama options, but so far all that's done is break xrandr. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 87514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 1368 bytes Desc: not available URL: From creder at digitalcpt.com Fri Dec 14 09:10:19 2007 From: creder at digitalcpt.com (christopher reder) Date: Fri, 14 Dec 2007 11:10:19 -0600 Subject: FW: Desktop screen corruption (AMD LX driver) In-Reply-To: <4b08f1290712140849y65856709gbcaca10911c34e60@mail.gmail.com> References: <9E1304B144EBEB4C97F4162BFAC47886DDCEED@SAUSEXMB2.amd.com> <4b08f1290712140849y65856709gbcaca10911c34e60@mail.gmail.com> Message-ID: <1197652219.26978.83.camel@linuxserver.digital> On Fri, 2007-12-14 at 22:19 +0530, Puneet Goel wrote: > Hello John, > > Thanks for the quick reply. > > You are right. It is happening at the 4 corners of the app. I was > dragging Notepad application on my desktop when i saw this behavior. > All the 4 corners of the notepad window were leaving trail behind on > desktop. If i refresh desktop everything becomes normal but dragging > notepad application again corrupted desktop. However if the drag any > of the native linux application which are installed on my system, it > works perfectly fine. I shall try to do more testing on this by > publishing some other apps as well. > > My host linux system is having Citrix ICA client 9.0. and server is > citrix presentation (metaframe) 4.5. There is a standard way of > publishing application via citrix server and that is what i am also > following. > > Is there any other info i need to provide ? > What happens with other backgrounds? From the picture you showed, it was a black image changing over to white, correct? So, that's 0xFF to 0x00 I believe so perhaps changing to a pure green color on your background would be a good experiment to see how the buffer could be getting overwritten. From glisse at freedesktop.org Fri Dec 14 09:35:09 2007 From: glisse at freedesktop.org (Jerome Glisse) Date: Fri, 14 Dec 2007 18:35:09 +0100 Subject: Improving rotated ATI performance In-Reply-To: <20071214171731.27f3522e.glisse@freedesktop.org> References: <308083c30712130813n4d06cbc3qe9b799a47d860a9b@mail.gmail.com> <308083c30712131019r72a81bbcj8b09356ee7e3e89d@mail.gmail.com> <20071214152506.11f1bdde.glisse@freedesktop.org> <308083c30712140758q4f8f4faeme430d1c64ad4a550@mail.gmail.com> <20071214171731.27f3522e.glisse@freedesktop.org> Message-ID: <20071214183509.634ad04b.glisse@freedesktop.org> On Fri, 14 Dec 2007 17:17:31 +0100 Jerome Glisse wrote: > > There is two work around for this: > - in the application split rendering into several tile which followh > the 2560 constraint. Well i am wrong you can't work around from application, only way is to work around from driver. Cheers, Jerome Glisse From jbarnes at virtuousgeek.org Fri Dec 14 10:41:47 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 14 Dec 2007 10:41:47 -0800 Subject: Resolution problem with i810 (FIXED) In-Reply-To: <2f96467a0712140611l433d29wdd032b2360ab1378@mail.gmail.com> References: <2f96467a0712140611l433d29wdd032b2360ab1378@mail.gmail.com> Message-ID: <200712141041.47661.jbarnes@virtuousgeek.org> On Friday, December 14, 2007 6:11 Rafael Mej?as wrote: > 2007/12/13, Jesse Barnes : > > So you could either try using something like i915resolution to > > reprogram your 1024x768 mode into something that might work on your > > LCD or you > > I've already done that with no effect. > > Don't worry. I finally fixed it using an extreme measure: changed the > repositories to Lenny, updated apt, and installed the new intel > driver (xserver-xorg-video-intel). > > It changed a lot of stuff into my system but it now works. Of course > I changed sources.list back to Etch... > > Lets hope it doesn't break. Now my laptop is officially a hybrid :-D Good to hear! Especially since the 1.7 branch of the driver doesn't see much action these days. :) Jesse From caglar at pardus.org.tr Fri Dec 14 10:31:01 2007 From: caglar at pardus.org.tr (=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur) Date: Fri, 14 Dec 2007 20:31:01 +0200 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <20071212204621.GA26358@fooishbar.org> References: <20071212204621.GA26358@fooishbar.org> Message-ID: <200712142031.05204.caglar@pardus.org.tr> Hi, 12 Ara 2007 ?ar tarihinde, Daniel Stone ?unlar? yazm??t?: > A quick pre-release so distros can start shipping something before 1.4.1 > comes out, whenever that is. I have been trying to get Xorg input hotplugging to work on my laptop with this release and also trying to understand concepts :). I removed all input releated sections from xorg.conf and start to use following fdi file for getting "trq" layout instead of "us" one. # cat /etc/hal/fdi/policy/10-input.fdi xorg pc104 trq # lshal | grep xk input.xkb.layout = 'trq' (string) input.xkb.model = 'pc104' (string) input.xkb.rules = 'xorg' (string) But i found some of my key mappings are wrong (xev reports Home maps Pause, Alt GR behaves like KP_Enter, Up Arrow maps Print etc.) with or without that fdi file. Could anybody tell me what may wrong, how can i find what causes this problem or how can i solve that issue (if needed Xorg.log can be found at http://cekirdek.pardus.org.tr/~caglar/Xorg.0.log) ? Cheers -- S.?a?lar Onur http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -------------- 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 dbn.lists at gmail.com Fri Dec 14 11:06:19 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Fri, 14 Dec 2007 11:06:19 -0800 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <200712142031.05204.caglar@pardus.org.tr> References: <20071212204621.GA26358@fooishbar.org> <200712142031.05204.caglar@pardus.org.tr> Message-ID: <91705d080712141106w7520e87cs8ee971095c77a2f0@mail.gmail.com> On Dec 14, 2007 10:31 AM, S.?a?lar Onur wrote: > Hi, > > 12 Ara 2007 ?ar tarihinde, Daniel Stone ?unlar? yazm??t?: > > A quick pre-release so distros can start shipping something before 1.4.1 > > comes out, whenever that is. > > I have been trying to get Xorg input hotplugging to work on my laptop with > this release and also trying to understand concepts :). > > I removed all input releated sections from xorg.conf and start to use > following fdi file for getting "trq" layout instead of "us" one. > > # cat /etc/hal/fdi/policy/10-input.fdi > > > > > > xorg > pc104 > trq > > > > > # lshal | grep xk > input.xkb.layout = 'trq' (string) > input.xkb.model = 'pc104' (string) > input.xkb.rules = 'xorg' (string) > > But i found some of my key mappings are wrong (xev reports Home maps Pause, > Alt GR behaves like KP_Enter, Up Arrow maps Print etc.) with or without that > fdi file. I believe you also need to set the driver and model to evdev since keyboard won't work: evdev evdev -- Dan From caglar at pardus.org.tr Fri Dec 14 11:34:41 2007 From: caglar at pardus.org.tr (=?iso-8859-9?q?S=2E=C7a=F0lar?= Onur) Date: Fri, 14 Dec 2007 21:34:41 +0200 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <91705d080712141106w7520e87cs8ee971095c77a2f0@mail.gmail.com> References: <20071212204621.GA26358@fooishbar.org> <200712142031.05204.caglar@pardus.org.tr> <91705d080712141106w7520e87cs8ee971095c77a2f0@mail.gmail.com> Message-ID: <200712142134.44830.caglar@pardus.org.tr> Hi; 14 Ara 2007 Cum tarihinde, Dan Nicholson ?unlar? yazm??t?: > I believe you also need to set the driver and model to evdev since > keyboard won't work: > > evdev > evdev Nope :(, nothing changes with following evdev evdev xorg trq $ lshal | grep xkb input.xkb.layout = 'trq' (string) input.xkb.model = 'evdev' (string) input.xkb.rules = 'xorg' (string) Cheers -- S.?a?lar Onur http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -------------- 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 John.Yoder at amd.com Fri Dec 14 11:33:26 2007 From: John.Yoder at amd.com (Yoder, John) Date: Fri, 14 Dec 2007 13:33:26 -0600 Subject: FW: Desktop screen corruption (AMD LX driver) In-Reply-To: <1197652219.26978.83.camel@linuxserver.digital> References: <9E1304B144EBEB4C97F4162BFAC47886DDCEED@SAUSEXMB2.amd.com> <4b08f1290712140849y65856709gbcaca10911c34e60@mail.gmail.com> <1197652219.26978.83.camel@linuxserver.digital> Message-ID: <9E1304B144EBEB4C97F4162BFAC47886E6371D@SAUSEXMB2.amd.com> Have you seen it happen with other local applications? Have you tried Remote X applications? I'm curious whether this is a Citrix only issue. Regards, John Yoder -----Original Message----- From: christopher reder [mailto:creder at digitalcpt.com] Sent: Friday, December 14, 2007 10:10 AM To: Puneet Goel Cc: Yoder, John; xorg-driver-geode at lists.x.org; xorg at lists.freedesktop.org Subject: Re: FW: Desktop screen corruption (AMD LX driver) On Fri, 2007-12-14 at 22:19 +0530, Puneet Goel wrote: > Hello John, > > Thanks for the quick reply. > > You are right. It is happening at the 4 corners of the app. I was > dragging Notepad application on my desktop when i saw this behavior. > All the 4 corners of the notepad window were leaving trail behind on > desktop. If i refresh desktop everything becomes normal but dragging > notepad application again corrupted desktop. However if the drag any > of the native linux application which are installed on my system, it > works perfectly fine. I shall try to do more testing on this by > publishing some other apps as well. > > My host linux system is having Citrix ICA client 9.0. and server is > citrix presentation (metaframe) 4.5. There is a standard way of > publishing application via citrix server and that is what i am also > following. > > Is there any other info i need to provide ? > What happens with other backgrounds? From the picture you showed, it was a black image changing over to white, correct? So, that's 0xFF to 0x00 I believe so perhaps changing to a pure green color on your background would be a good experiment to see how the buffer could be getting overwritten. From daniel.naughton at gmail.com Fri Dec 14 12:03:45 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Fri, 14 Dec 2007 14:03:45 -0600 Subject: intel driver for 945GM multihead question - Got It! Message-ID: It took a while, but it's working. A few things that jump out in various howtos and docs that screwed me up. The position of the second screen in the Server Layout and the Xinerama and Clone options. The position Option needs to go in the "Monitor" section. And the virtual display needs to be set at least to Width of Screen 1 + Width of Screen 2 in the Screen/Display Subsection. For a test, there's two full screen movies running, one on each monitor. I've gone through this exercise with XP. While it was easier to setup, this ones is ALOT smoother on playback (VLC was the movie player in both cases). Nice work on the 945GM driver. Thanks All! (I put up the xorg.conf file that worked for me (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is on (II) intel(0): Display plane B is now enabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TMDS-2 is connected to pipe B Section "ServerLayout" Identifier "Hand Built Configuration" Screen "Screen1" Screen "Screen2" Right Of "Screen1" <== position part does nothing? #Option "Xinerama" "on" <=== also does nothing? #Option "Clone" "off" <== also does nothing? InputDevice "KeyboardUSB" "CoreKeyboard" EndSection -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: From jcristau at debian.org Fri Dec 14 12:01:24 2007 From: jcristau at debian.org (Julien Cristau) Date: Fri, 14 Dec 2007 21:01:24 +0100 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <200712142031.05204.caglar@pardus.org.tr> References: <20071212204621.GA26358@fooishbar.org> <200712142031.05204.caglar@pardus.org.tr> Message-ID: <20071214200115.GA6857@patate.is-a-geek.org> On Fri, Dec 14, 2007 at 20:31:01 +0200, S.?a?lar Onur wrote: > Could anybody tell me what may wrong, how can i find what causes this problem > or how can i solve that issue (if needed Xorg.log can be found at > http://cekirdek.pardus.org.tr/~caglar/Xorg.0.log) ? > (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap this might be a problem... what does "xprop -root _XKB_RULES_NAMES" output? Cheers, Julien From caglar at pardus.org.tr Fri Dec 14 12:08:47 2007 From: caglar at pardus.org.tr (=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur) Date: Fri, 14 Dec 2007 22:08:47 +0200 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <20071214200115.GA6857@patate.is-a-geek.org> References: <20071212204621.GA26358@fooishbar.org> <200712142031.05204.caglar@pardus.org.tr> <20071214200115.GA6857@patate.is-a-geek.org> Message-ID: <200712142208.52209.caglar@pardus.org.tr> Hi; 14 Ara 2007 Cum tarihinde, Julien Cristau ?unlar? yazm??t?: > On Fri, Dec 14, 2007 at 20:31:01 +0200, S.?a?lar Onur wrote: > > > Could anybody tell me what may wrong, how can i find what causes this problem > > or how can i solve that issue (if needed Xorg.log can be found at > > http://cekirdek.pardus.org.tr/~caglar/Xorg.0.log) ? > > > (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap > > this might be a problem... what does "xprop -root _XKB_RULES_NAMES" > output? caglar at zangetsu ~ $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "xorg", "evdev", "trq", "", "" > Cheers, > Julien Cheers -- S.?a?lar Onur http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -------------- 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 rafaelmejiasc at gmail.com Fri Dec 14 12:21:54 2007 From: rafaelmejiasc at gmail.com (=?ISO-8859-1?Q?Rafael_Mej=EDas?=) Date: Sat, 15 Dec 2007 15:51:54 +1930 Subject: Resolution problem with i810 (FIXED) In-Reply-To: <4762A2E3.9030309@sun.com> References: <2f96467a0712140611l433d29wdd032b2360ab1378@mail.gmail.com> <4762A2E3.9030309@sun.com> Message-ID: <2f96467a0712141221i74e9210jdd21c7b05faf4718@mail.gmail.com> 2007/12/15, Stuart Kreitman : > Please fix the time on your machine. Why? Am I a half an hour late? That's normal in Venezuela since last sunday... :-D From Stuart.Kreitman at Sun.COM Fri Dec 14 12:42:52 2007 From: Stuart.Kreitman at Sun.COM (Stuart Kreitman) Date: Fri, 14 Dec 2007 12:42:52 -0800 Subject: Resolution problem with i810 (FIXED) In-Reply-To: <2f96467a0712141221i74e9210jdd21c7b05faf4718@mail.gmail.com> References: <2f96467a0712140611l433d29wdd032b2360ab1378@mail.gmail.com> <4762A2E3.9030309@sun.com> <2f96467a0712141221i74e9210jdd21c7b05faf4718@mail.gmail.com> Message-ID: <4762EACC.8000107@sun.com> maybe your machine's time zone is off. Its translating to 22 hours ahead of here. Rafael Mej?as wrote: > 2007/12/15, Stuart Kreitman : > >> Please fix the time on your machine. >> > > Why? Am I a half an hour late? That's normal in Venezuela since last > sunday... :-D > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From kr992 at interia.pl Fri Dec 14 15:05:21 2007 From: kr992 at interia.pl (kr992) Date: Sat, 15 Dec 2007 00:05:21 +0100 Subject: question Message-ID: <00db01c83ea5$cf423dd0$b100a8c0@lvy2ry3tz2> Hello I was try build xorg from git , with xserver i had problem : Building xserver module component ... autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /usr/share/aclocal autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force hw/dmx/examples/Makefile.am:1: DMX_BUILD_USB does not appear in AM_CONDITIONAL hw/dmx/input/Makefile.am:3: DMX_BUILD_LNX does not appear in AM_CONDITIONAL hw/dmx/input/Makefile.am:12: DMX_BUILD_USB does not appear in AM_CONDITIONAL cpprules.in:5: SED was already defined in condition TRUE, which includes condition LAUNCHD ... hw/xquartz/bundle/Makefile.am:19: `cpprules.in' included from here configure.ac:60: ... `SED' previously defined here autoreconf: automake failed with exit status: 1 Have someone problems with compiling too? Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From madman2003 at gmail.com Fri Dec 14 15:26:13 2007 From: madman2003 at gmail.com (Maarten Maathuis) Date: Sat, 15 Dec 2007 00:26:13 +0100 Subject: randr-1.2 rotation doesn't use composite hook with a transform In-Reply-To: <6d4bc9fc0712131507i3104d2aai7daba0431197dccb@mail.gmail.com> References: <6d4bc9fc0712131507i3104d2aai7daba0431197dccb@mail.gmail.com> Message-ID: <6d4bc9fc0712141526u7f5387d6sfa03a1e3302ea278@mail.gmail.com> The problem turned out to be a pixmap that was not detected/accepted as offscreen, thus causing a fallback path. Sincerly, Maarten Maathuis. On 12/14/07, Maarten Maathuis wrote: > I've been trying to implement rotation support into the nouveau > driver, by filling the shadow hooks and setting the crtc base > correctly. This works but it is slow, suggesting software rendering. > > My understanding is that it should use the composite hook to rotate > and transfer the image to the shadow area. > > It does seem to call composite very frequently, but not with a transform. > > I'm using xserver git. > > Any idea what could be wrong? > > Sincerely, > > Maarten Maathuis. > From madman2003 at gmail.com Fri Dec 14 15:27:53 2007 From: madman2003 at gmail.com (Maarten Maathuis) Date: Sat, 15 Dec 2007 00:27:53 +0100 Subject: xserver build broken (automake related) Message-ID: <6d4bc9fc0712141527u3abdabe8hd2196679fa6ee309@mail.gmail.com> I've included a hack patch, the if statements in dmx that were commented out need to handled in a correct way by someone who knows were that should be done. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_build.patch Type: application/octet-stream Size: 1399 bytes Desc: not available URL: From bryce at bryceharrington.org Fri Dec 14 15:40:31 2007 From: bryce at bryceharrington.org (Bryce Harrington) Date: Fri, 14 Dec 2007 15:40:31 -0800 Subject: question In-Reply-To: <00db01c83ea5$cf423dd0$b100a8c0@lvy2ry3tz2> References: <00db01c83ea5$cf423dd0$b100a8c0@lvy2ry3tz2> Message-ID: <20071214234031.GA30590@bryceharrington.org> On Sat, Dec 15, 2007 at 12:05:21AM +0100, kr992 wrote: > Hello > > I was try build xorg from git , with xserver i had problem : > > Building xserver module component ... > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal -I /usr/share/aclocal > autoreconf: configure.ac: tracing > autoreconf: running: libtoolize --copy > libtoolize: `config.guess' exists: use `--force' to overwrite > libtoolize: `config.sub' exists: use `--force' to overwrite > libtoolize: `ltmain.sh' exists: use `--force' to overwrite > autoreconf: running: /usr/bin/autoconf > autoreconf: running: /usr/bin/autoheader > autoreconf: running: automake --add-missing --copy --no-force > hw/dmx/examples/Makefile.am:1: DMX_BUILD_USB does not appear in AM_CONDITIONAL > hw/dmx/input/Makefile.am:3: DMX_BUILD_LNX does not appear in AM_CONDITIONAL > hw/dmx/input/Makefile.am:12: DMX_BUILD_USB does not appear in AM_CONDITIONAL > cpprules.in:5: SED was already defined in condition TRUE, which includes condition LAUNCHD ... > hw/xquartz/bundle/Makefile.am:19: `cpprules.in' included from here > configure.ac:60: ... `SED' previously defined here > autoreconf: automake failed with exit status: 1 > > Have someone problems with compiling too? I noticed these same warnings when I built from git-head yesterday. However, it produced a configure that appeared to be viable, and it configured and built the xserver successfully. (I didn't try running it). Bryce From kr992 at interia.pl Fri Dec 14 15:56:49 2007 From: kr992 at interia.pl (kr992) Date: Sat, 15 Dec 2007 00:56:49 +0100 Subject: question References: <00db01c83ea5$cf423dd0$b100a8c0@lvy2ry3tz2> <20071214234031.GA30590@bryceharrington.org> Message-ID: <001401c83ead$04b89890$b100a8c0@lvy2ry3tz2> Oh i didnt try make compile i was thinking that failure what stops script is definitive ill try manually do after mike ----- Original Message ----- From: "Bryce Harrington" To: "kr992" Cc: Sent: Saturday, December 15, 2007 12:40 AM Subject: Re: question > On Sat, Dec 15, 2007 at 12:05:21AM +0100, kr992 wrote: >> Hello >> >> I was try build xorg from git , with xserver i had problem : >> >> Building xserver module component ... >> autoreconf: Entering directory `.' >> autoreconf: configure.ac: not using Gettext >> autoreconf: running: aclocal -I /usr/share/aclocal >> autoreconf: configure.ac: tracing >> autoreconf: running: libtoolize --copy >> libtoolize: `config.guess' exists: use `--force' to overwrite >> libtoolize: `config.sub' exists: use `--force' to overwrite >> libtoolize: `ltmain.sh' exists: use `--force' to overwrite >> autoreconf: running: /usr/bin/autoconf >> autoreconf: running: /usr/bin/autoheader >> autoreconf: running: automake --add-missing --copy --no-force >> hw/dmx/examples/Makefile.am:1: DMX_BUILD_USB does not appear in >> AM_CONDITIONAL >> hw/dmx/input/Makefile.am:3: DMX_BUILD_LNX does not appear in >> AM_CONDITIONAL >> hw/dmx/input/Makefile.am:12: DMX_BUILD_USB does not appear in >> AM_CONDITIONAL >> cpprules.in:5: SED was already defined in condition TRUE, which includes >> condition LAUNCHD ... >> hw/xquartz/bundle/Makefile.am:19: `cpprules.in' included from here >> configure.ac:60: ... `SED' previously defined here >> autoreconf: automake failed with exit status: 1 >> >> Have someone problems with compiling too? > > I noticed these same warnings when I built from git-head yesterday. > However, it produced a configure that appeared to be viable, and it > configured and built the xserver successfully. (I didn't try running > it). > > Bryce > > ---------------------------------------------------------------------- Szybkie, smaczne danie z "tego co pod reka"? Wejdz na >>> http://link.interia.pl/f1cae From madman2003 at gmail.com Fri Dec 14 15:59:28 2007 From: madman2003 at gmail.com (Maarten Maathuis) Date: Sat, 15 Dec 2007 00:59:28 +0100 Subject: question In-Reply-To: <001401c83ead$04b89890$b100a8c0@lvy2ry3tz2> References: <00db01c83ea5$cf423dd0$b100a8c0@lvy2ry3tz2> <20071214234031.GA30590@bryceharrington.org> <001401c83ead$04b89890$b100a8c0@lvy2ry3tz2> Message-ID: <6d4bc9fc0712141559g51a03d35s53e6c39649a4478@mail.gmail.com> The errors are relevant, i posted a "hack" patch to work around it to the list. That was about 30 minutes ago. Maarten. On 12/15/07, kr992 wrote: > Oh > > i didnt try make compile i was thinking that failure what stops script is > definitive ill try manually do after > > mike > > ----- Original Message ----- > From: "Bryce Harrington" > To: "kr992" > Cc: > Sent: Saturday, December 15, 2007 12:40 AM > Subject: Re: question > > > > On Sat, Dec 15, 2007 at 12:05:21AM +0100, kr992 wrote: > >> Hello > >> > >> I was try build xorg from git , with xserver i had problem : > >> > >> Building xserver module component ... > >> autoreconf: Entering directory `.' > >> autoreconf: configure.ac: not using Gettext > >> autoreconf: running: aclocal -I /usr/share/aclocal > >> autoreconf: configure.ac: tracing > >> autoreconf: running: libtoolize --copy > >> libtoolize: `config.guess' exists: use `--force' to overwrite > >> libtoolize: `config.sub' exists: use `--force' to overwrite > >> libtoolize: `ltmain.sh' exists: use `--force' to overwrite > >> autoreconf: running: /usr/bin/autoconf > >> autoreconf: running: /usr/bin/autoheader > >> autoreconf: running: automake --add-missing --copy --no-force > >> hw/dmx/examples/Makefile.am:1: DMX_BUILD_USB does not appear in > >> AM_CONDITIONAL > >> hw/dmx/input/Makefile.am:3: DMX_BUILD_LNX does not appear in > >> AM_CONDITIONAL > >> hw/dmx/input/Makefile.am:12: DMX_BUILD_USB does not appear in > >> AM_CONDITIONAL > >> cpprules.in:5: SED was already defined in condition TRUE, which includes > >> condition LAUNCHD ... > >> hw/xquartz/bundle/Makefile.am:19: `cpprules.in' included from here > >> configure.ac:60: ... `SED' previously defined here > >> autoreconf: automake failed with exit status: 1 > >> > >> Have someone problems with compiling too? > > > > I noticed these same warnings when I built from git-head yesterday. > > However, it produced a configure that appeared to be viable, and it > > configured and built the xserver successfully. (I didn't try running > > it). > > > > Bryce > > > > > > > > ---------------------------------------------------------------------- > Szybkie, smaczne danie z "tego co pod reka"? > Wejdz na >>> http://link.interia.pl/f1cae > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From sergio at sergiomb.no-ip.org Fri Dec 14 18:08:34 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 15 Dec 2007 02:08:34 +0000 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <20071212204621.GA26358@fooishbar.org> References: <20071212204621.GA26358@fooishbar.org> Message-ID: <1197684514.3060.29.camel@monteirov> On Wed, 2007-12-12 at 22:46 +0200, Daniel Stone wrote: > A quick pre-release so distros can start shipping something before > 1.4.1 > comes out, whenever that is. IHMO, since fedora and Redhat don't ship Xorg 7.3 with Xorg-server 1.4.0 , nobody does like Ubumtu , Debian , Gentoo, Mandriva, Suse, Slackware and Arch Linux (I think) . Upcoming Fedora 9 already have xorg-server 1.4.99 (1.5), I don't know if this make sense, but I don't see a solution. But in mean time, for who honors stability have Xorg 7.3.1, I think that could be good, because improves stability in some drives like Intel ... But this release (Xorg 7.3.1) should also bump a numbers of others componentes , like pciaccess-0.10.0, libXcomposite-0.4.0, Mesa-7.0.3 etc That my Humble Opinion. Thanks, -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From avilella at gmail.com Sat Dec 15 02:23:47 2007 From: avilella at gmail.com (Albert Vilella) Date: Sat, 15 Dec 2007 10:23:47 +0000 Subject: 945GM xrandr and DRI configuration Message-ID: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> Hi, I've got a sony sz1xp laptop with an intel 945GM. Is it possible to have a configuration that would allow me to configure the external screens / projectors with xrandr and yet to have DRI enabled when not plugged? Right now, my xrandr configuration works, but I don't have acceleration when using only the laptop's screen. xorg.conf attached. Thanks in advance, Cheers, Albert. -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 6710 bytes Desc: not available URL: From svh at dds.nl Sat Dec 15 02:42:52 2007 From: svh at dds.nl (S. J. van Harmelen) Date: Sat, 15 Dec 2007 11:42:52 +0100 Subject: Error compiling input devices Message-ID: <1197715372.5915.3.camel@localhost> Hello everyone... I'm trying to compile Xorg7.3 from source using the build-from-tarballs.sh script. I seem to get quit far, but when it reaches the input devices I get these errors for (as far as I looked at it) all input devices: ============================================================================== make[1]: Entering directory `/tmp/tarballs/xf86-input-evdev-1.1.2' Making all in src make[2]: Entering directory `/tmp/tarballs/xf86-input-evdev-1.1.2/src' if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -O2 -I/tmp/modular/include/xorg -I/usr/local/include/pixman-1 -I/tmp/modular/include -I../src -MT evdev_drv_la-evdev.lo -MD -MP -MF ".deps/evdev_drv_la-evdev.Tpo" -c -o evdev_drv_la-evdev.lo `test -f 'evdev.c' || echo './'`evdev.c; \ then mv -f ".deps/evdev_drv_la-evdev.Tpo" ".deps/evdev_drv_la-evdev.Plo"; else rm -f ".deps/evdev_drv_la-evdev.Tpo"; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -O2 -I/tmp/modular/include/xorg -I/usr/local/include/pixman-1 -I/tmp/modular/include -I../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c evdev.c -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o In file included from evdev.h:66, from evdev.c:66: /usr/include/linux/input.h:801: error: parse error before "kernel_ulong_t" /usr/include/linux/input.h:805: error: parse error before "evbit" /usr/include/linux/input.h:805: error: `BITS_PER_LONG' undeclared here (not in a function) /usr/include/linux/input.h:806: error: parse error before "keybit" /usr/include/linux/input.h:807: error: parse error before "relbit" /usr/include/linux/input.h:808: error: parse error before "absbit" /usr/include/linux/input.h:809: error: parse error before "mscbit" /usr/include/linux/input.h:810: error: parse error before "ledbit" /usr/include/linux/input.h:811: error: parse error before "sndbit" /usr/include/linux/input.h:812: error: parse error before "ffbit" /usr/include/linux/input.h:813: error: parse error before "swbit" /usr/include/linux/input.h:815: error: parse error before "driver_info" evdev.c: In function `EvdevReadInput': evdev.c:95: warning: long int format, unsigned int arg (arg 6) evdev.c: In function `EvdevSwitchMode': evdev.c:239: warning: implicit declaration of function `xf86XInputSetSendCoreEvents' evdev.c: In function `EvdevNew': evdev.c:267: error: structure has no member named `motion_history_proc' evdev.c: In function `EvdevParseBits': evdev.c:348: warning: implicit declaration of function `set_bit' evdev.c: At top level: /usr/include/linux/input.h:805: error: storage size of `evbit' isn't known /usr/include/linux/input.h:806: error: storage size of `keybit' isn't known /usr/include/linux/input.h:807: error: storage size of `relbit' isn't known /usr/include/linux/input.h:808: error: storage size of `absbit' isn't known /usr/include/linux/input.h:809: error: storage size of `mscbit' isn't known /usr/include/linux/input.h:810: error: storage size of `ledbit' isn't known /usr/include/linux/input.h:811: error: storage size of `sndbit' isn't known /usr/include/linux/input.h:812: error: storage size of `ffbit' isn't known /usr/include/linux/input.h:813: error: storage size of `swbit' isn't known make[2]: *** [evdev_drv_la-evdev.lo] Error 1 make[2]: Leaving directory `/tmp/tarballs/xf86-input-evdev-1.1.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/tarballs/xf86-input-evdev-1.1.2' make: *** [all] Error 2 ============================================================================== What to do about these? Do I need to update the input.h file? Hope someone can point me in the right direction. Thanks, Sander From caglar at pardus.org.tr Sat Dec 15 04:29:34 2007 From: caglar at pardus.org.tr (=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur) Date: Sat, 15 Dec 2007 14:29:34 +0200 Subject: [ANNOUNCE] xorg-server 1.4.0.90 In-Reply-To: <200712142208.52209.caglar@pardus.org.tr> References: <20071212204621.GA26358@fooishbar.org> <20071214200115.GA6857@patate.is-a-geek.org> <200712142208.52209.caglar@pardus.org.tr> Message-ID: <200712151429.38011.caglar@pardus.org.tr> Hi; 14 Ara 2007 Cum tarihinde, S.?a?lar Onur ?unlar? yazm??t?: > > (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap > > > > this might be a problem... what does "xprop -root _XKB_RULES_NAMES" > > output? > > caglar at zangetsu ~ $ xprop -root _XKB_RULES_NAMES > _XKB_RULES_NAMES(STRING) = "xorg", "evdev", "trq", "", "" I found the problem, somehow i forgot to update xkeyboard-config from 0.9 to 1.1 :(. Upgrading to that version solves that issue. Thanks for your time -- S.?a?lar Onur http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -------------- 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 colin.harrison at virgin.net Sat Dec 15 10:57:43 2007 From: colin.harrison at virgin.net (Colin Harrison) Date: Sat, 15 Dec 2007 18:57:43 -0000 Subject: [PATCH] xserver file rlAccel.c lvalue error after recent changes Message-ID: <200712151857.lBFIvgFe003828@StraightRunning.com> Hi, The file rlAccel.c in xserver/miext/rootless/accel gives an lvalue error after recent changes. Patch to fix... --- ./xserver/miext/rootless/accel/save_rlAccel.c 2007-12-14 19:29:17.000000000 +0000 +++ ./xserver/miext/rootless/accel/rlAccel.c 2007-12-14 19:47:07.000000000 +0000 @@ -51,6 +51,9 @@ #define RLACCELREC(pScreen) ((rlAccelScreenRec *) \ dixLookupPrivate(&(pScreen)->devPrivates, rlAccelScreenPrivateKey)) +#define SETRLACCELREC(pScreen, v) \ + dixSetPrivate(&(pScreen)->devPrivates, rlAccelScreenPrivateKey, v) + /* This is mostly identical to fbGCOps. */ static GCOps rlAccelOps = { rlFillSpans, @@ -132,7 +135,7 @@ s = xalloc(sizeof(rlAccelScreenRec)); if (!s) return FALSE; - RLACCELREC(pScreen) = s; + SETRLACCELREC(pScreen, s); // Wrap the screen functions we need s->CreateGC = pScreen->CreateGC; Thanks, Colin Harrison From fhimpe at telenet.be Sat Dec 15 11:19:46 2007 From: fhimpe at telenet.be (Frederik Himpe) Date: Sat, 15 Dec 2007 19:19:46 +0000 (UTC) Subject: Synaptics touchpad input hotplugging Message-ID: I am using X server 1.4 (actually some 1.4.1 git snapshot) on Mandriva 2008.0 Cooker and hal 0.5.10. I removed all mouse and touchpad entries in xorg.conf (only inputdevice left is keyboard), and restarted X. The touchpad is basically working, but the scroll buttons up/down which are under the touchpad do not work correctly (e.g. the up button is interpreted as right click, down as a left click and left button works in the browser as back) udi = '/org/freedesktop/Hal/devices/ platform_i8042_i8042_AUX_port_logicaldev_input' info.capabilities = {'input', 'input.touchpad'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/ platform_i8042_i8042_AUX_port' (string) info.product = 'SynPS/2 Synaptics TouchPad' (string) info.udi = '/org/freedesktop/Hal/devices/ platform_i8042_i8042_AUX_port_logicaldev_input' (string) input.device = '/dev/input/event1' (string) input.originating_device = '/org/freedesktop/Hal/devices/ platform_i8042_i8042_AUX_port' (string) input.physical_device = '/org/freedesktop/Hal/devices/ platform_i8042_i8042_AUX_port' (string) input.product = 'SynPS/2 Synaptics TouchPad' (string) linux.device_file = '/dev/input/event1' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/class/input/input1/event1' (string) Xorg.0.log says this: (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/input/mice" (--) : Device: "/dev/input/mice" (==) : Protocol: "Auto" (**) Option "CorePointer" (**) : always reports core events (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (**) : Sensitivity: 1 (II) evaluating device () (II) XINPUT: Adding extended input device "" (type: MOUSE) (II) evaluating device (Keyboard1) (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) (--) : PnP-detected protocol: "ExplorerPS/2" (II) : ps2EnableDataReporting: succeeded Should not it have detected automatically that this is a Synaptics device and loaded the right driver and settings so that everything is working? -- Frederik Himpe From jgrosshart at gmail.com Sat Dec 15 12:06:08 2007 From: jgrosshart at gmail.com (Jon Grosshart) Date: Sat, 15 Dec 2007 15:06:08 -0500 Subject: Error compiling input devices In-Reply-To: <1197715372.5915.3.camel@localhost> References: <1197715372.5915.3.camel@localhost> Message-ID: <9cf823c60712151206w5932bdf7hb69958bca4b08c4@mail.gmail.com> On Dec 15, 2007 5:42 AM, S. J. van Harmelen wrote: > Hello everyone... > > I'm trying to compile Xorg7.3 from source using the > build-from-tarballs.sh script. I seem to get quit far, but when it > reaches the input devices I get these errors for (as far as I looked at > it) all input devices: > > > ============================================================================== > > make[1]: Entering directory `/tmp/tarballs/xf86-input-evdev-1.1.2' > Making all in src > make[2]: Entering directory `/tmp/tarballs/xf86-input-evdev-1.1.2/src' > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I. -I.. -Wall -g -O2 -I/tmp/modular/include/xorg > -I/usr/local/include/pixman-1 -I/tmp/modular/include -I../src -MT > evdev_drv_la-evdev.lo -MD -MP -MF ".deps/evdev_drv_la-evdev.Tpo" -c -o > evdev_drv_la-evdev.lo `test -f 'evdev.c' || echo './'`evdev.c; \ > then mv -f ".deps/evdev_drv_la-evdev.Tpo" > ".deps/evdev_drv_la-evdev.Plo"; else rm -f > ".deps/evdev_drv_la-evdev.Tpo"; exit 1; fi > mkdir .libs > gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -O2 > -I/tmp/modular/include/xorg -I/usr/local/include/pixman-1 > -I/tmp/modular/include -I../src -MT evdev_drv_la-evdev.lo -MD -MP > -MF .deps/evdev_drv_la-evdev.Tpo -c evdev.c -fPIC -DPIC > -o .libs/evdev_drv_la-evdev.o > In file included from evdev.h:66, > from evdev.c:66: > /usr/include/linux/input.h:801: error: parse error before > "kernel_ulong_t" > /usr/include/linux/input.h:805: error: parse error before "evbit" > /usr/include/linux/input.h:805: error: `BITS_PER_LONG' undeclared here > (not in a function) > /usr/include/linux/input.h:806: error: parse error before "keybit" > /usr/include/linux/input.h:807: error: parse error before "relbit" > /usr/include/linux/input.h:808: error: parse error before "absbit" > /usr/include/linux/input.h:809: error: parse error before "mscbit" > /usr/include/linux/input.h:810: error: parse error before "ledbit" > /usr/include/linux/input.h:811: error: parse error before "sndbit" > /usr/include/linux/input.h:812: error: parse error before "ffbit" > /usr/include/linux/input.h:813: error: parse error before "swbit" > /usr/include/linux/input.h:815: error: parse error before "driver_info" > evdev.c: In function `EvdevReadInput': > evdev.c:95: warning: long int format, unsigned int arg (arg 6) > evdev.c: In function `EvdevSwitchMode': > evdev.c:239: warning: implicit declaration of function > `xf86XInputSetSendCoreEvents' > evdev.c: In function `EvdevNew': > evdev.c:267: error: structure has no member named `motion_history_proc' > evdev.c: In function `EvdevParseBits': > evdev.c:348: warning: implicit declaration of function `set_bit' > evdev.c: At top level: > /usr/include/linux/input.h:805: error: storage size of `evbit' isn't > known > /usr/include/linux/input.h:806: error: storage size of `keybit' isn't > known > /usr/include/linux/input.h:807: error: storage size of `relbit' isn't > known > /usr/include/linux/input.h:808: error: storage size of `absbit' isn't > known > /usr/include/linux/input.h:809: error: storage size of `mscbit' isn't > known > /usr/include/linux/input.h:810: error: storage size of `ledbit' isn't > known > /usr/include/linux/input.h:811: error: storage size of `sndbit' isn't > known > /usr/include/linux/input.h:812: error: storage size of `ffbit' isn't > known > /usr/include/linux/input.h:813: error: storage size of `swbit' isn't > known > make[2]: *** [evdev_drv_la-evdev.lo] Error 1 > make[2]: Leaving directory `/tmp/tarballs/xf86-input-evdev-1.1.2/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/tarballs/xf86-input-evdev-1.1.2' > make: *** [all] Error 2 > > > ============================================================================== > > What to do about these? Do I need to update the input.h file? > > Hope someone can point me in the right direction. > > Thanks, > > Sander > > Yea... Most of the input drivers bomb in the 7.3 release directory... I've been pushing for "correct" release directories, hopefully 7.4 is a little more complete. ;-) Grab updated drivers from the individual/ directory. http://xorg.freedesktop.org/releases/individual/driver/ Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dm at chello.nl Sat Dec 15 12:50:51 2007 From: dm at chello.nl (Dick) Date: Sat, 15 Dec 2007 20:50:51 +0000 (UTC) Subject: G35/33 X3500/3100 HDMI References: <4752EB4E.9000002@trypill.org> Message-ID: sim0n trypill.org> writes: > I would be interested in buying a "Asus P5E-VM HDMI" motherboard, which > has the G35 chipset and a X3500 graphics chip on-board including an HDMI > connector. I own a Shuttle Barebone SG33G5M iG33 which has indeed a HDMI connector, that sadly doesn't work yet. VGA does work if I use the GIT tip sources. I've reported a bug at: https://bugs.freedesktop.org/show_bug.cgi?id=13625 Could someone give me some hints for debugging to find out why it doesn't work? Thanks a lot, Dick From nigel at nigel.suspend2.net Sat Dec 15 13:51:33 2007 From: nigel at nigel.suspend2.net (Nigel Cunningham) Date: Sun, 16 Dec 2007 08:51:33 +1100 Subject: Another compile failure (xserver)? Message-ID: <47644C65.1020401@nigel.suspend2.net> Hi all. Is anyone else getting this? I got the previous error with autoconf (DMX_BUILD_USB does not appear in AM_CONDITIONAL etc), but having progressed beyond that, I'm now getting: gcc -DHAVE_CONFIG_H -I. -I../../include -DHAVE_DIX_CONFIG_H -DNO_HW_ONLY_EXTS -DNO_MODULE_EXTS -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/xorg/usr/include -I/xorg/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -g -O2 -MT dpmsstubs.o -MD -MP -MF .deps/dpmsstubs.Tpo -c -o dpmsstubs.o `test -f '../../Xext/dpmsstubs.c' || echo './'`../../Xext/dpmsstubs.c In file included from ../../include/gc.h:53, from ../../include/dix.h:52, from ../../include/dixstruct.h:28, from ../../Xext/dpmsproc.h:12, from ../../Xext/dpmsstubs.c:36: /xorg/usr/include/X11/Xdefs.h:49: error: redefinition of typedef 'Bool' ../../Xext/dpmsstubs.c:29: error: previous declaration of 'Bool' was here make[3]: *** [dpmsstubs.o] Error 1 make[3]: Leaving directory `/home/nigel/Programming/xorg/xserver/hw/vfb' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/nigel/Programming/xorg/xserver/hw/vfb' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/nigel/Programming/xorg/xserver/hw' make: *** [all-recursive] Error 1 Xdefs.h: #ifndef Bool # ifndef _XTYPEDEF_BOOL # define _XTYPEDEF_BOOL typedef int Bool; # endif #endif dpmsstubs.c: (Unconditional) typedef int Bool; Commenting out this last declaration makes it compile. Nigel From solca at guug.org Sat Dec 15 18:38:22 2007 From: solca at guug.org (Otto Solares) Date: Sat, 15 Dec 2007 20:38:22 -0600 Subject: radeon: incorrect crtc for external LCD on VGA-0 In-Reply-To: References: <20071207071823.GA16163@guug.org> <20071207081343.GB16163@guug.org> Message-ID: <20071216023822.GB8113@guug.org> On Wed, Dec 12, 2007 at 11:23:31AM -0500, Alex Deucher wrote: > On Dec 7, 2007 3:13 AM, Otto Solares wrote: > > > > On Fri, Dec 07, 2007 at 02:37:05AM -0500, Alex Deucher wrote: > > > On Dec 7, 2007 2:18 AM, Otto Solares wrote: > > > > Hi! > > > > > > > > Video card on x86 laptop: > > > > > > > > ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) > > > > > > > > I used to have an old external CRT monitor attached to the VGA-0 > > > > connector and the command `xrand --output LVDS --off` would > > > > correctly turn off the laptop's LCD so I can work in the external > > > > without having both monitors powered-on. > > > > > > > > Problem now is that I buy a new external LCD monitor and the > > > > above command would turn off both the new LCD and the laptop's > > > > LCD. > > > > > > > > But when `xrandr --output VGA-0 --crtc 0` everything works as > > > > expected so I pressume is a bug in the crtc detection when a > > > > LCD is attached in the VGA-0 connector both monitors are driven > > > > by the same crtc. As I said, plugging the CRT monitor doesn't > > > > exhibit this problem. > > > > > > > > Running latest Debian Sid (X Server 1.4.0) and git radeon driver. > > > > > > Please file a bug (https://bugs.freedesktop.org) and attach your xorg > > > log and config. > > > > Done: Bug # 13557 > > As per the bug report, can you try again with ati git master? Sorry for the looong delay, I try with latest git xrandr tool and latest git driver and the problem persist, I presume now the CRTC is correct for the VGA-0 port but `xrandr --output \ LVDS --off` still power off both ports. I update the bug report with the requested info, thanks. -otto From Magnus.Vigerlof at home.se Sun Dec 16 05:25:10 2007 From: Magnus.Vigerlof at home.se (Magnus =?utf-8?q?Vigerl=C3=B6f?=) Date: Sun, 16 Dec 2007 14:25:10 +0100 Subject: [PATCH] dix: Always add valuator information if present Message-ID: <200712161425.10522.Magnus.Vigerlof@home.se> Send valuator information with all event types, not only for MotionEvents and absolute button events. Relative button events will have the coordinate set to 0,0 for the extended event unless this information is included. --- dix/getevents.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index 40fc7f2..6e840d4 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -525,9 +525,6 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, int num_events = 0, final_valuator = 0; CARD32 ms = 0; deviceKeyButtonPointer *kbp = NULL; - /* Thanks to a broken lib, we _always_ have to chase DeviceMotionNotifies - * with DeviceValuators. */ - Bool sendValuators = (type == MotionNotify || flags & POINTER_ABSOLUTE); DeviceIntPtr cp = inputInfo.pointer; int x = 0, y = 0; Bool coreOnly = (pDev == inputInfo.pointer); @@ -553,7 +550,7 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, return 0; /* Do we need to send a DeviceValuator event? */ - if (!coreOnly && sendValuators) { + if (!coreOnly && num_valuators) { if ((((num_valuators - 1) / 6) + 1) > MAX_VALUATOR_EVENTS) num_valuators = MAX_VALUATOR_EVENTS * 6; num_events += ((num_valuators - 1) / 6) + 1; @@ -684,7 +681,7 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, kbp->root_y = y; events++; - if (sendValuators) { + if (num_valuators) { kbp->deviceid |= MORE_EVENTS; clipValuators(pDev, first_valuator, num_valuators, valuators); events = getValuatorEvents(events, pDev, first_valuator, -- 1.5.2.5 From daniel at fooishbar.org Sun Dec 16 07:51:42 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 16 Dec 2007 17:51:42 +0200 Subject: [PATCH] dix: Always add valuator information if present In-Reply-To: <200712161425.10522.Magnus.Vigerlof@home.se> References: <200712161425.10522.Magnus.Vigerlof@home.se> Message-ID: <20071216155142.GA11394@fooishbar.org> On Sun, Dec 16, 2007 at 02:25:10PM +0100, Magnus Vigerl?f wrote: > Send valuator information with all event types, not only for > MotionEvents and absolute button events. Relative button events > will have the coordinate set to 0,0 for the extended event > unless this information is included. Er, except they won't, because DeviceKeyButtonPointer includes both event_{x,y} and root_{x,y}, so you always have the first two axes (as I just verified with people.fd.o/~daniels/xiread.c and my trackpoint). If you want to get extended axes, hmm. Okay, turns out I misread the spec, and it said that relative devices _may_ report all zeros in the valuator fields, not must, as I thought. I'll merge a slightly modified version; only send separate valuators if there are more than two, or it's a motion notify. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Magnus.Vigerlof at home.se Sun Dec 16 09:12:41 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-15?q?Vigerl=F6f?=) Date: Sun, 16 Dec 2007 18:12:41 +0100 Subject: [PATCH] dix: Always add valuator information if present In-Reply-To: <20071216155142.GA11394@fooishbar.org> References: <200712161425.10522.Magnus.Vigerlof@home.se> <20071216155142.GA11394@fooishbar.org> Message-ID: <200712161812.41747.Magnus.Vigerlof@home.se> On s?ndag 16 december 2007, Daniel Stone wrote: > On Sun, Dec 16, 2007 at 02:25:10PM +0100, Magnus Vigerl?f wrote: > > Send valuator information with all event types, not only for > > MotionEvents and absolute button events. Relative button events > > will have the coordinate set to 0,0 for the extended event > > unless this information is included. > > Er, except they won't, because DeviceKeyButtonPointer includes both > event_{x,y} and root_{x,y}, so you always have the first two axes (as I > just verified with people.fd.o/~daniels/xiread.c and my trackpoint). If > you want to get extended axes, hmm. Okay, turns out I misread the spec, > and it said that relative devices _may_ report all zeros in the valuator > fields, not must, as I thought. I'll merge a slightly modified version; > only send separate valuators if there are more than two, or it's a > motion notify. Hmmm... Ok, I'm not so familiar with the spec, of the thoughts behind how events should be generated. I only saw a difference in behaviour and checked what was different.. As long as the net result will be that the coordinates in the InputDevice coordinate space will be included in the event that reaches the XClient (for example Gimp that doesn't look at the screen-scaled x&y, but will use the high-resolution axis that a Wacom tablet will provide). The linuxwacom driver always send 6 axis so it shouldn't be a problem for us. But if we have a slightly more simple device which only have two axis and a few buttons (I'm not sure if acecad falls into this category), won't the above restrictions ensure that the extended axes will get '0' again? Cheers Magnus From daniel at fooishbar.org Sun Dec 16 09:45:49 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 16 Dec 2007 19:45:49 +0200 Subject: [PATCH] dix: Always add valuator information if present In-Reply-To: <200712161812.41747.Magnus.Vigerlof@home.se> References: <200712161425.10522.Magnus.Vigerlof@home.se> <20071216155142.GA11394@fooishbar.org> <200712161812.41747.Magnus.Vigerlof@home.se> Message-ID: <20071216174549.GA18414@fooishbar.org> On Sun, Dec 16, 2007 at 06:12:41PM +0100, Magnus Vigerl?f wrote: > On s?ndag 16 december 2007, Daniel Stone wrote: > > Er, except they won't, because DeviceKeyButtonPointer includes both > > event_{x,y} and root_{x,y}, so you always have the first two axes (as I > > just verified with people.fd.o/~daniels/xiread.c and my trackpoint). If > > you want to get extended axes, hmm. Okay, turns out I misread the spec, > > and it said that relative devices _may_ report all zeros in the valuator > > fields, not must, as I thought. I'll merge a slightly modified version; > > only send separate valuators if there are more than two, or it's a > > motion notify. > > Hmmm... Ok, I'm not so familiar with the spec, of the thoughts behind how > events should be generated. I only saw a difference in behaviour and checked > what was different.. > > As long as the net result will be that the coordinates in the InputDevice > coordinate space will be included in the event that reaches the XClient (for > example Gimp that doesn't look at the screen-scaled x&y, but will use the > high-resolution axis that a Wacom tablet will provide). Ah! Good point. Yes, we always want to send valuators if they're at all scaled. But given that we need to send all valuators on motion events anyway, it doesn't make sense overoptimising the button case. > The linuxwacom driver always send 6 axis so it shouldn't be a problem for us. > But if we have a slightly more simple device which only have two axis and a > few buttons (I'm not sure if acecad falls into this category), won't the > above restrictions ensure that the extended axes will get '0' again? Well, not zero, just not sent. :) Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Magnus.Vigerlof at home.se Sun Dec 16 09:53:46 2007 From: Magnus.Vigerlof at home.se (Magnus =?utf-8?q?Vigerl=C3=B6f?=) Date: Sun, 16 Dec 2007 18:53:46 +0100 Subject: [RFC] dix: Re-introduce rescaling on motion events for extended event reporting Message-ID: <200712161853.46380.Magnus.Vigerlof@home.se> Hello, As xserver 1.4 removed the scaling callbacks for X&Y on extended InputDevices [1], we've been forced to scale down the reported values to the screen size. This means that we looses all the fine-grained movement that we previously could report and for some applications this means a loss of quality in the result for the end-user as the applications now must work on more coarse-grained data. Since the work to correct this is postponed for some time I propose an interim solution where we get back the scaling so devices can register any values on X&Y and not be tied to the changing values of the screen size. The patch below is tested with a Wacom tablet and works well with my Volito 2 both as a pointer on the desktop and as a pressure-sensitive, high-resolution pen in Gimp. At the same time my synaptic touchpad and USB mouse worked as before. This time I haven't introduced any interface changes. The values that should be reported for the device are the same as in xserver 1.3, including the max-values on X&Y. The drivers that has been adapted to cope with the current situation will continue to work as the max-value registered by the driver is used in the scaling. The only worry I have with this patch is the check for if we should scale or not. The devices I have in my system that shouldn't scale all have '-1' as max and this is what's used to detect this situation. Is that safe? Comments are appreciated. Cheers Magnus [1] https://bugs.freedesktop.org/show_bug.cgi?id=10324 --- dix/getevents.c | 54 +++++++++++++++++++++++++++++++++++++++++------------- 1 files changed, 41 insertions(+), 13 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index 6e840d4..d562e18 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -528,6 +528,7 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, DeviceIntPtr cp = inputInfo.pointer; int x = 0, y = 0; Bool coreOnly = (pDev == inputInfo.pointer); + ScreenPtr scr = miPointerGetScreen(pDev); /* Sanity checks. */ if (type != MotionNotify && type != ButtonPress && type != ButtonRelease) @@ -593,15 +594,33 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, valuators); if (pDev->coreEvents) { - if (first_valuator == 0 && num_valuators >= 1) - x = cp->valuator->lastx + valuators[0]; + /* Get and convert the core pointer coordinate space into + * device coordinates. Use the device coords if it translates + * into the same position as the core to preserve relative sub- + * pixel movements from the device. */ + int max = pDev->valuator->axes[0].max_value; + if(max > 0) { + x = pDev->valuator->lastx; + if((int)((float)(x)*scr->width/(max+1)) != cp->valuator->lastx) + x = (int)((float)(cp->valuator->lastx)*(max+1)/scr->width); + } else x = cp->valuator->lastx; - if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) - y = cp->valuator->lasty + valuators[1 - first_valuator]; + max = pDev->valuator->axes[1].max_value; + if(max > 0) { + y = pDev->valuator->lasty; + if((int)((float)(y)*scr->height/(max+1)) != cp->valuator->lasty) + y = (int)((float)(cp->valuator->lasty)*(max+1)/scr->height); + } else y = cp->valuator->lasty; + + /* Add relative movement */ + if (first_valuator == 0 && num_valuators >= 1) + x += valuators[0]; + if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) + y += valuators[1 - first_valuator]; } else { if (first_valuator == 0 && num_valuators >= 1) @@ -620,11 +639,6 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, clipAxis(pDev, 0, &x); clipAxis(pDev, 1, &y); - /* This takes care of crossing screens for us, as well as clipping - * to the current screen. Right now, we only have one history buffer, - * so we don't set this for both the device and core.*/ - miPointerSetPosition(pDev, &x, &y, ms); - /* Drop x and y back into the valuators list, if they were originally * present. */ if (first_valuator == 0 && num_valuators >= 1) @@ -634,12 +648,26 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, updateMotionHistory(pDev, ms, first_valuator, num_valuators, valuators); + pDev->valuator->lastx = x; + pDev->valuator->lasty = y; + /* Convert the dev coord back to screen coord if we're + * sending core events */ + if (pDev->coreEvents) { + if(pDev->valuator->axes[0].max_value > 0) + x = (int)((float)(x)*scr->width/(pDev->valuator->axes[0].max_value+1)); + if(pDev->valuator->axes[1].max_value > 0) + y = (int)((float)(y)*scr->height/(pDev->valuator->axes[1].max_value+1)); + } + + /* This takes care of crossing screens for us, as well as clipping + * to the current screen. Right now, we only have one history buffer, + * so we don't set this for both the device and core.*/ + miPointerSetPosition(pDev, &x, &y, ms); + if (pDev->coreEvents) { cp->valuator->lastx = x; cp->valuator->lasty = y; } - pDev->valuator->lastx = x; - pDev->valuator->lasty = y; /* for some reason inputInfo.pointer does not have coreEvents set */ if (coreOnly || pDev->coreEvents) { @@ -677,8 +705,8 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, kbp->detail = pDev->button->map[buttons]; } - kbp->root_x = x; - kbp->root_y = y; + kbp->root_x = pDev->valuator->lastx; + kbp->root_y = pDev->valuator->lasty; events++; if (num_valuators) { -- 1.5.2.5 From matthieu.herrb at laas.fr Sun Dec 16 12:05:01 2007 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sun, 16 Dec 2007 21:05:01 +0100 Subject: xcalloc called from signal handler Message-ID: <476584ED.9060502@laas.fr> Hi, As far as I know the malloc() family of function is not async-signal safe on most of the systems that X.Org supports (including Linux, Solaris and *BSD). Unfortunalty the xserver 1.4 new Xinput code calls xcalloc() in functions that are called by the SIGIO handler. This has been identified as the cause of many X server segfaults on OpenBSD, and will probably also cause random problems on other systems. Unfortunatly I don't really know enough about Xinput to provide a proper fix. The patch I'm attaching here is just a ugly hack to fix the issue for the short term. -- Matthieu Herrb -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xf86Xinput.diff URL: From eric at anholt.net Sun Dec 16 12:42:56 2007 From: eric at anholt.net (Eric Anholt) Date: Sun, 16 Dec 2007 12:42:56 -0800 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> Message-ID: <1197837776.4462.17.camel@localhost> On Wed, 2007-12-12 at 19:51 +0100, Clemens Eisserer wrote: > Hi Jesse, > > I am also quite interested in EXA on the GMA950/945GM. > Does the current driver still wait after each command sent to the GPU > (i830WaitSynnc), and if so, will this also fixed for GMA900/GMA950 > chips or only on 965 based GPUs? No, non-965 doesn't wait for rendering like that. -- Eric Anholt anholt at FreeBSD.org eric at anholt.net eric.anholt at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part URL: From beat.kneubuehl at rega-sense.ch Sun Dec 16 13:11:39 2007 From: beat.kneubuehl at rega-sense.ch (Beat Kneubuehl) Date: Sun, 16 Dec 2007 22:11:39 +0100 Subject: G35/33 X3500/3100 HDMI In-Reply-To: References: <4752EB4E.9000002@trypill.org> Message-ID: <4765948B.1090705@rega-sense.ch> Hi Dick I have a Gigabyte GA-G33M-S2H mainboard with G33 chipset and HDMI and DVI port on board. To make the HDMI/DVI Port work i had to add a dummy "Monitor" section to xorg.conf, otherwise the driver tried always to connect Pipe A to the VGA Port and ignored the HDMI/DVI port. You can try to add the following to your xorg.conf: Section "Monitor" Identifier "dummy" Option "Ignore" "True" EndSection Section "Monitor" Identifier "standard-dvi" Option "DPMS" "enable" Option "enable" "True" EndSection Then search the Device section and add the following to lines: Option "monitor-VGA" "dummy" Option "monitor-TMDS-1" "standard-dvi" Here is my device section: -------------------------------------------- Section "Device" Identifier "intel G33" Driver "intel" Option "DRI" "true" Option "XAANoOffscreenPixmaps" "true" Option "FramebufferCompression" "true" Option "Tiling" "true" Option "monitor-VGA" "dummy" Option "monitor-TMDS-1" "standard-dvi" Option "ModeDebug" "false" EndSection Beat Dick schrieb: > sim0n trypill.org> writes: > >> I would be interested in buying a "Asus P5E-VM HDMI" motherboard, which >> has the G35 chipset and a X3500 graphics chip on-board including an HDMI >> connector. >> > > I own a Shuttle Barebone SG33G5M iG33 which has indeed a HDMI connector, that > sadly doesn't work yet. VGA does work if I use the GIT tip sources. > > I've reported a bug at: https://bugs.freedesktop.org/show_bug.cgi?id=13625 > > Could someone give me some hints for debugging to find out why it doesn't work? > > Thanks a lot, > Dick > > > From dm at chello.nl Sun Dec 16 13:38:07 2007 From: dm at chello.nl (Dick) Date: Sun, 16 Dec 2007 21:38:07 +0000 (UTC) Subject: G35/33 X3500/3100 HDMI References: <4752EB4E.9000002@trypill.org> <4765948B.1090705@rega-sense.ch> Message-ID: Beat, Thanks for your reply! Your trick doesn't work for me: (II) intel(0): Output VGA using monitor section dummy (**) intel(0): Option "Ignore" "True" (II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" initialized. (II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" registered at address 0x70. (II) intel(0): No SDVO device found on SDVOB (II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" removed. (II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" removed. (II) intel(0): I2C bus "SDVOCTRL_E for SDVOC" initialized. (II) intel(0): I2C device "SDVOCTRL_E for SDVOC:SDVO Controller C" registered at address 0x72. (II) intel(0): No SDVO device found on SDVOC (II) intel(0): I2C device "SDVOCTRL_E for SDVOC:SDVO Controller C" removed. (II) intel(0): I2C bus "SDVOCTRL_E for SDVOC" removed. (EE) intel(0): No valid modes. No TMDS-1 for me :-( Could you maybe post your Xorg.0.log? Thanks! Dick From beat.kneubuehl at rega-sense.ch Sun Dec 16 13:46:02 2007 From: beat.kneubuehl at rega-sense.ch (Beat Kneubuehl) Date: Sun, 16 Dec 2007 22:46:02 +0100 Subject: interlace modes support for intel driver Message-ID: <47659C9A.9020307@rega-sense.ch> Hi I own a Philips 37PF9731 TV, with HDMI input, which can do 1080i or 720p HDTV modes. When i connect this TV to the HDMI output from my GA-G33M-S2H Gigabyte mainboard, i don't get a picture on the TV, because he prefers 1080i mode in his EDID information. He does not even include the 720p mode in the EDID information, here is the output from Xorg0.log: ------------------------------------------------------------- (II) intel(0): EDID for output TMDS-1 (II) intel(0): Manufacturer: PHL Model: 0 Serial#: 16843009 (II) intel(0): Year: 1990 Week: 0 (II) intel(0): EDID Version: 1.3 (II) intel(0): Digital Display Input (II) intel(0): Max H-Image Size [cm]: horiz.: 64 vert.: 36 (II) intel(0): Gamma: 2.20 (II) intel(0): No DPMS capabilities specified; RGB/Color Display (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.640 redY: 0.330 greenX: 0.290 greenY: 0.600 (II) intel(0): blueX: 0.150 blueY: 0.060 whiteX: 0.289 whiteY: 0.299 (II) intel(0): Supported VESA Video Modes: (II) intel(0): 640x480 at 60Hz (II) intel(0): 800x600 at 60Hz (II) intel(0): 1024x768 at 60Hz (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported additional Video Mode: (II) intel(0): clock: 74.2 MHz Image Size: 640 x 360 mm (II) intel(0): h_active: 1920 h_sync: 2448 h_sync_end 2492 h_blank_end 2640 h_border: 0 (II) intel(0): v_active: 540 v_sync: 542 v_sync_end 547 v_blanking: 562 v_border: 0 (II) intel(0): Supported additional Video Mode: (II) intel(0): clock: 65.0 MHz Image Size: 400 x 300 mm (II) intel(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0 (II) intel(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0 (II) intel(0): Monitor name: Philips FTV (II) intel(0): Ranges: V min: 48 V max: 62 Hz, H min: 15 H max: 50 kHz, PixClock max 90 MHz (II) intel(0): Number of EDID sections to follow: 1 (II) intel(0): EDID (in hex): (II) intel(0): 00ffffffffffff00410c000001010101 (II) intel(0): 00000103804024780ae692a3544a9926 (II) intel(0): 0f4a4c21080001010101010101010101 (II) intel(0): 010101010101011d80d0721c1620102c (II) intel(0): 258080682100009e6419004041002630 (II) intel(0): 18883600902c11000018000000fc0050 (II) intel(0): 68696c697073204654560a20000000fd (II) intel(0): 00303e0f3209000a202020202020019d (II) intel(0): Using EDID range info for horizontal sync (II) intel(0): Using EDID range info for vertical refresh (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) intel(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) intel(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) intel(0): Modeline "1920x540" 74.25 1920 2448 2492 2640 540 542 547 562 interlace +hsync +vsync (II) intel(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) intel(0): EDID vendor "PHL", prod id 0 ------------------------------------------------------------- So i added the following modeline for 720p, which gives me a pretty good HDTV quality: Modeline "1280x720" 74.25 1280 1388 1468 1648 720 725 730 750 -hsync -vsync But almost all German HDTV channels are broadcasting in 1080i mode and thus almost all my DVB-C recordings are in 1080i mode, and it might be better to connect in 1080i mode to the TV and let the TV do all the nasty deinterlacing work! According to the README from the 2.2.0 Intel driver, interlace modes are currently not supported by the Linux Intel driver. I know that the hardware (G33) is perfectly able to do 1080i with my TV, because it works with the Windows driver, thus i'd like to know if there are any plans to support interlace modes with the Intel driver? My programming skills are not good enough to send you a patch, how can i help you otherwise in implementing? I think it might be a valuable feature to support interlace modes, because lot's of TV screens are floating around which are not 1080p capable, and even when they support 1080p, it might be easier to let the TV screen to the deinterlacing work and send him a 1080i signal. A lot of HTPC mainboards are using Intel onboard graphic chips and might be also very thankfully. Regards, Beat From beat.kneubuehl at rega-sense.ch Sun Dec 16 13:58:03 2007 From: beat.kneubuehl at rega-sense.ch (Beat Kneubuehl) Date: Sun, 16 Dec 2007 22:58:03 +0100 Subject: G35/33 X3500/3100 HDMI In-Reply-To: References: <4752EB4E.9000002@trypill.org> <4765948B.1090705@rega-sense.ch> Message-ID: <47659F6B.3030602@rega-sense.ch> Hi Dick, Here is my Xorg.0.log and my xorg.conf: Xorg.0.log ----------------------------------------------------------------------------------------------- X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: UNKNOWN Current Operating System: Linux cube 2.6.23-gentoo-r3 #1 SMP PREEMPT Thu Dec 13 23:20:40 CET 2007 x86_64 Build Date: 03 December 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 16 21:41:58 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "standard-dvi" (**) | |-->Device "intel G33" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (WW) The directory "/usr/share/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/Type1/" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/CID/" 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: /usr/share/fonts/misc/, /usr/share/fonts/ttf-bitstream-vera/, /usr/share/fonts/corefonts/, /usr/share/fonts/75dpi/ (==) RgbPath set to "/usr/share/X11/rgb" (==) ModulePath set to "/usr/lib64/xorg/modules" (**) Extension "Composite" is enabled (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x7b17a0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.2 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib64/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,29c0 card 1458,5000 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,29c2 card 1458,d000 rev 02 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,29c3 card 1458,d000 rev 02 class 03,80,00 hdr 80 (II) PCI: 00:1a:0: chip 8086,2937 card 1458,5004 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2938 card 1458,5004 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1a:2: chip 8086,2939 card 1458,5004 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,293c card 1458,5006 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,293e card 1458,a022 rev 02 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,2940 card 0000,0000 rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1c:4: chip 8086,2948 card 0000,0000 rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2934 card 1458,5004 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2935 card 1458,5004 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2936 card 1458,5004 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,293a card 1458,5006 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 92 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2918 card 1458,5001 rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:2: chip 8086,2923 card 1458,b005 rev 02 class 01,06,01 hdr 00 (II) PCI: 00:1f:3: chip 8086,2930 card 1458,5001 rev 02 class 0c,05,00 hdr 00 (II) PCI: 02:00:0: chip 197b,2368 card 1458,b000 rev 00 class 01,01,85 hdr 00 (II) PCI: 03:00:0: chip 1131,7146 card 153b,1156 rev 01 class 04,80,00 hdr 00 (II) PCI: 03:01:0: chip 1113,1211 card 1113,9211 rev 10 class 02,00,00 hdr 00 (II) PCI: 03:05:0: chip 10ec,8167 card 1458,e000 rev 10 class 02,00,00 hdr 00 (II) PCI: 03:07:0: chip 104c,8024 card 1458,1000 rev 00 class 0c,00,10 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,3), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:28:0), (0,1,1), BCTRL: 0x0000 (VGA_EN is cleared) (II) Bus 1 I/O range: [0] -1 0 0x0000b000 - 0x0000bfff (0x1000) IX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:4), (0,2,2), BCTRL: 0x0000 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x0000c000 - 0x0000cfff (0x1000) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xf0000000 - 0xf0ffffff (0x1000000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 3: bridge is at (0:30:0), (0,3,3), BCTRL: 0x0000 (VGA_EN is cleared) (II) Bus 3 I/O range: [0] -1 0 0x0000d000 - 0x0000dfff (0x1000) IX[B] (II) Bus 3 non-prefetchable memory range: [0] -1 0 0xf1000000 - 0xf2ffffff (0x2000000) MX[B] (II) Bus 3 prefetchable memory range: [0] -1 0 0x80000000 - 0x800fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(0:2:0) Intel Corporation Integrated Graphics Controller rev 2, Mem @ 0xf3100000/19, 0xe0000000/28, 0xf3000000/20, I/O @ 0xe200/3 (--) PCI: (0:2:1) Intel Corporation Integrated Graphics Controller rev 2, Mem @ 0xf3180000/19 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [1] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [2] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [3] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [4] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [5] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [6] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [7] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [8] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [9] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [10] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [11] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [12] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [13] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [14] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [15] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [16] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [17] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [18] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [19] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [20] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [21] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [22] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [23] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [24] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [25] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [26] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [27] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [28] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [29] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [30] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [31] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [32] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [33] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [1] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [2] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [3] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [4] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [5] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [6] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [7] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [8] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [9] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [10] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [11] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [12] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [13] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [14] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [15] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [16] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [17] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [18] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [19] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [20] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [21] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [22] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [23] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [24] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [25] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [26] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [27] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [28] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [29] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [30] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [31] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [32] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [33] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [5] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [6] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [7] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [8] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [9] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [10] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [11] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [12] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [13] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [14] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [15] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [16] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [17] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [21] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [22] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [23] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [24] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [25] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [26] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [27] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [28] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [29] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [30] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [31] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [32] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [33] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [34] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [35] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [36] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [37] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [38] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [39] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) (II) LoadModule: "dbe" (II) Loading /usr/lib64/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/lib64/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (II) Loading /usr/lib64/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "freetype" (II) Loading /usr/lib64/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.3.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/lib64/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "record" (II) Loading /usr/lib64/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "xtrap" (II) Loading /usr/lib64/xorg/modules/extensions//libxtrap.so (II) Module xtrap: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DEC-XTRAP (II) LoadModule: "intel" (II) Loading /usr/lib64/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.3.0, module version = 2.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) LoadModule: "mouse" (II) Loading /usr/lib64/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (II) LoadModule: "kbd" (II) Loading /usr/lib64/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (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, 965G, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33 (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found (--) Chipset G33 found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [5] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [6] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [7] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [8] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [9] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [10] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [11] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [12] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [13] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [14] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [15] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [16] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [17] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [21] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [22] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [23] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [24] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [25] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [26] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [27] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [28] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [29] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [30] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [31] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [32] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [33] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [34] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [35] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [36] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [37] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [38] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [39] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [5] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [6] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [7] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [8] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [9] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [10] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [11] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [12] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [13] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [14] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [15] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [16] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [17] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [18] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [19] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [20] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [21] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [22] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [23] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [24] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [25] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [26] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [27] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [28] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [29] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [30] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [31] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [32] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [33] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [34] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [35] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [36] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [37] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [38] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [39] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [40] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [41] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [42] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) [43] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [44] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib64/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/lib64/xorg/modules//libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.1.0 ABI class: X.Org Video Driver, version 1.2 (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib64/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.3.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.2 (**) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (**) intel(0): Option "DRI" "true" (**) intel(0): Option "ModeDebug" "false" (**) intel(0): Option "FramebufferCompression" "true" (**) intel(0): Option "Tiling" "true" (II) intel(0): Integrated Graphics Chipset: Intel(R) G33 (--) intel(0): Chipset: "G33" (--) intel(0): Linear framebuffer at 0xE0000000 (--) intel(0): IO registers at addr 0xF3100000 (II) intel(0): 2 display pipes available. (==) intel(0): Using EXA for acceleration (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module already built-in (II) intel(0): Output VGA using monitor section dummy (**) intel(0): Option "Ignore" "True" (II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" initialized. (II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" registered at address 0x70. (II) intel(0): I2C bus "SDVOB DDC Bus" initialized. (II) intel(0): Output TMDS-1 using monitor section standard-dvi (**) intel(0): Option "Enable" "True" (II) intel(0): SDVO device VID/DID: 04:AE.00, clock range 25.0MHz - 165.0MHz, input 1: Y, input 2: N, output 1: Y, output 2: N (II) intel(0): I2C bus "SDVOCTRL_E for SDVOC" initialized. (II) intel(0): I2C device "SDVOCTRL_E for SDVOC:SDVO Controller C" registered at address 0x72. (II) intel(0): No SDVO device found on SDVOC (II) intel(0): I2C device "SDVOCTRL_E for SDVOC:SDVO Controller C" removed. (II) intel(0): I2C bus "SDVOCTRL_E for SDVOC" removed. (II) intel(0): Current clock rate multiplier: 1 (II) intel(0): Output TMDS-1 enabled by config file (II) intel(0): I2C device "SDVOB DDC Bus:ddc2" registered at address 0xA0. (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. (II) intel(0): I2C device "SDVOB DDC Bus:ddc2" removed. (II) intel(0): EDID for output TMDS-1 (II) intel(0): Manufacturer: MED Model: 89e0 Serial#: 16843009 (II) intel(0): Year: 2006 Week: 43 (II) intel(0): EDID Version: 1.3 (II) intel(0): Digital Display Input (II) intel(0): Max H-Image Size [cm]: horiz.: 38 vert.: 30 (II) intel(0): Gamma: 2.50 (II) intel(0): DPMS capabilities: Off; RGB/Color Display (II) intel(0): First detailed timing not preferred mode in violation of standard!(II) intel(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 (II) intel(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) intel(0): Supported VESA Video Modes: (II) intel(0): 720x400 at 70Hz (II) intel(0): 640x480 at 60Hz (II) intel(0): 640x480 at 72Hz (II) intel(0): 640x480 at 75Hz (II) intel(0): 800x600 at 56Hz (II) intel(0): 800x600 at 60Hz (II) intel(0): 800x600 at 72Hz (II) intel(0): 800x600 at 75Hz (II) intel(0): 1024x768 at 60Hz (II) intel(0): 1024x768 at 70Hz (II) intel(0): 1024x768 at 75Hz (II) intel(0): 1280x1024 at 75Hz (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported Future Video Modes: (II) intel(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) intel(0): Supported additional Video Mode: (II) intel(0): clock: 108.0 MHz Image Size: 376 x 301 mm (II) intel(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) intel(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) intel(0): Monitor name: MD30799PY (II) intel(0): Ranges: V min: 50 V max: 75 Hz, H min: 31 H max: 83 kHz, PixClock max 140 MHz (II) intel(0): Serial No: 610095744 (II) intel(0): EDID (in hex): (II) intel(0): 00ffffffffffff0034a4e08901010101 (II) intel(0): 2b10010380261e9628de95a3544c9926 (II) intel(0): 0f5054afcf0081800101010101010101 (II) intel(0): 010101010101302a009851002a403070 (II) intel(0): 1300782d1100001e000000fc004d4433 (II) intel(0): 3037393950590a202020000000fd0032 (II) intel(0): 4b1f530e000a202020202020000000ff (II) intel(0): 003631303039353734340a202020006a (II) intel(0): Using EDID range info for horizontal sync (II) intel(0): Using EDID range info for vertical refresh (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) intel(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (II) intel(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) intel(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (II) intel(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) intel(0): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) intel(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) intel(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) intel(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) intel(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) intel(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) intel(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (II) intel(0): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) intel(0): Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (II) intel(0): EDID vendor "MED", prod id 35296 (II) intel(0): Not using default mode "640x350" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "720x400" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1152x864" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1280x960" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1200" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "832x624" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1152x768" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1400x1050" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1600x1024" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) intel(0): Not using default mode "2048x1536" (bad mode clock/interlace/doublescan) (II) intel(0): Printing probed modes for output TMDS-1 (II) intel(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) intel(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) intel(0): Output TMDS-1 enabled by config file (II) intel(0): Output TMDS-1 using initial mode 1280x1024 (II) intel(0): detected 1024 kB GTT. (II) intel(0): detected 7164 kB stolen memory. (==) intel(0): video overlay key set to 0x101fe (==) intel(0): Will not try to enable page flipping (==) intel(0): Triple buffering disabled (==) intel(0): Using gamma correction (1.0, 1.0, 1.0) (**) intel(0): Display dimensions: (380, 300) mm (**) intel(0): DPI set to (85, 108) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib64/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/lib64/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.3.0, module version = 2.1.0 ABI class: X.Org Video Driver, version 1.2 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module already built-in (II) intel(0): Comparing regs from server start up to After PreInit (II) Loading sub module "dri" (II) LoadModule: "dri" (II) Reloading /usr/lib64/xorg/modules/extensions//libdri.so (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xf3000000 - 0xf30fffff (0x100000) MS[B] [1] 0 0 0xe0000000 - 0xefffffff (0x10000000) MS[B] [2] 0 0 0xf3100000 - 0xf317ffff (0x80000) MS[B] [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xf2000000 - 0xf2003fff (0x4000) MX[B] [8] -1 0 0xf2006000 - 0xf20067ff (0x800) MX[B] [9] -1 0 0xf2005000 - 0xf20050ff (0x100) MX[B] [10] -1 0 0xf2007000 - 0xf20070ff (0x100) MX[B] [11] -1 0 0xf2004000 - 0xf20041ff (0x200) MX[B] [12] -1 0 0xf3207000 - 0xf32070ff (0x100) MX[B] [13] -1 0 0xf3206000 - 0xf32067ff (0x800) MX[B] [14] -1 0 0xf3204000 - 0xf32043ff (0x400) MX[B] [15] -1 0 0xf3200000 - 0xf3203fff (0x4000) MX[B] [16] -1 0 0xf3205000 - 0xf32053ff (0x400) MX[B] [17] -1 0 0xf3180000 - 0xf31fffff (0x80000) MX[B](B) [18] -1 0 0xf3000000 - 0xf30fffff (0x100000) MX[B](B) [19] -1 0 0xe0000000 - 0xefffffff (0x10000000) MX[B](B) [20] -1 0 0xf3100000 - 0xf317ffff (0x80000) MX[B](B) [21] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [22] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [23] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [24] 0 0 0x0000e200 - 0x0000e207 (0x8) IS[B] [25] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [26] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [27] -1 0 0x0000d100 - 0x0000d1ff (0x100) IX[B] [28] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [29] -1 0 0x0000c400 - 0x0000c40f (0x10) IX[B] [30] -1 0 0x0000c300 - 0x0000c303 (0x4) IX[B] [31] -1 0 0x0000c200 - 0x0000c207 (0x8) IX[B] [32] -1 0 0x0000c100 - 0x0000c103 (0x4) IX[B] [33] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B] [34] -1 0 0x00000500 - 0x0000051f (0x20) IX[B] [35] -1 0 0x0000eb00 - 0x0000eb1f (0x20) IX[B] [36] -1 0 0x0000ea00 - 0x0000ea03 (0x4) IX[B] [37] -1 0 0x0000e900 - 0x0000e907 (0x8) IX[B] [38] -1 0 0x0000e800 - 0x0000e803 (0x4) IX[B] [39] -1 0 0x0000e700 - 0x0000e707 (0x8) IX[B] [40] -1 0 0x0000e500 - 0x0000e51f (0x20) IX[B] [41] -1 0 0x0000e400 - 0x0000e41f (0x20) IX[B] [42] -1 0 0x0000e300 - 0x0000e31f (0x20) IX[B] [43] -1 0 0x0000e100 - 0x0000e11f (0x20) IX[B] [44] -1 0 0x0000e000 - 0x0000e01f (0x20) IX[B] [45] -1 0 0x0000e600 - 0x0000e61f (0x20) IX[B] [46] -1 0 0x0000e200 - 0x0000e207 (0x8) IX[B](B) [47] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [48] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) intel(0): Kernel reported 488704 total, 1 used (II) intel(0): I830CheckAvailableMemory: 1954812 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) intel(0): [drm] loaded kernel module for "i915" driver (II) intel(0): [drm] DRM interface version 1.3 (II) intel(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) intel(0): [drm] added 8192 byte SAREA at 0x2efff000 (II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x2ad7d4f39000 (II) intel(0): [drm] framebuffer handle = 0xe0000000 (II) intel(0): [drm] added 1 reserved context for kernel (WW) intel(0): Removed DRI frontbuffer mapping in compatibility mode. (WW) intel(0): DRIGetDeviceInfo will report incorrect frontbuffer handle. (==) intel(0): VideoRam: 262144 KB (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (II) intel(0): Attempting memory allocation with tiled buffers. (WW) intel(0): Allocation error, framebuffer compression disabled (II) intel(0): Success. (II) intel(0): Increasing the scanline pitch to allow tiling mode (1280 -> 2048). (II) intel(0): [drm] Registers = 0xf3100000 (II) intel(0): [drm] ring buffer = 0x2fff9000 (II) intel(0): [drm] mapped front buffer at 0xe1000000, handle = 0xe1000000 (II) intel(0): [drm] mapped back buffer at 0xe4000000, handle = 0xe4000000 (II) intel(0): [drm] mapped depth buffer at 0xe5000000, handle = 0xe5000000 (II) intel(0): [drm] mapped classic textures at 0xe6000000, handle = 0xe6000000 (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432 (II) intel(0): [dri] visual configs initialized (II) intel(0): Page Flipping disabled (==) intel(0): Write-combining range (0xe0000000,0x10000000) (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (WW) intel(0): EXA compatibility mode. Output rotation rendering performance may suffer (II) EXA(0): Offscreen pixmap area of 31457280 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): X context handle = 0x1 (II) intel(0): [drm] installed DRM signal handler (II) intel(0): [DRI] installation complete (II) intel(0): [drm] dma control initialized, using IRQ 16 (II) intel(0): Current clock rate multiplier: 1 (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x01000000 (pgoffset 4096) (II) intel(0): xf86BindGARTMemory: bind key 1 at 0x02000000 (pgoffset 8192) (II) intel(0): xf86BindGARTMemory: bind key 2 at 0x04000000 (pgoffset 16384) (II) intel(0): xf86BindGARTMemory: bind key 3 at 0x05000000 (pgoffset 20480) (II) intel(0): xf86BindGARTMemory: bind key 4 at 0x06000000 (pgoffset 24576) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB) (II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB) (II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB) (II) intel(0): 0x00033000-0x00033fff: G33 hw status (4 kB) (II) intel(0): 0x006ff000: end of stolen memory (II) intel(0): 0x01000000-0x01ffffff: front buffer (10240 kB) X tiled (II) intel(0): 0x02000000-0x03dfffff: exa offscreen (30720 kB) (II) intel(0): 0x04000000-0x04ffffff: back buffer (10240 kB) X tiled (II) intel(0): 0x05000000-0x05ffffff: depth buffer (10240 kB) X tiled (II) intel(0): 0x06000000-0x07ffffff: classic textures (32768 kB) (II) intel(0): 0x10000000: end of aperture (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (WW) Option "dpms" requires a boolean value (**) intel(0): DPMS enabled (II) intel(0): Set up textured video (II) intel(0): Set up overlay video (II) intel(0): direct rendering: Enabled (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (WW) intel(0): Option "XAANoOffscreenPixmaps" is not used (WW) intel(0): Option "enable" is not used (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)(EE) AIGLX: reverting to software rendering (II) Loading local sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/lib64/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) intel(0): Setting screen physical size to 376 x 301 (**) Option "Protocol" "IMPS/2" (**) Mouse1: Device: "/dev/misc/psaux" (**) Mouse1: Protocol: "IMPS/2" (**) Option "CorePointer" (**) Mouse1: Core Pointer (**) Option "Device" "/dev/misc/psaux" (==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse1: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse1: Buttons: 11 (**) Mouse1: Sensitivity: 1 (**) Option "CoreKeyboard" (**) Keyboard1: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "ch" (**) Keyboard1: XkbLayout: "ch" (**) Option "XkbVariant" "de_nodeadkeys" (**) Keyboard1: XkbVariant: "de_nodeadkeys" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (II) Mouse1: ps2EnableDataReporting: succeeded (II) 3rd Button detected: disabling emulate3Button (II) intel(0): xf86UnbindGARTMemory: unbind key 0 (II) intel(0): xf86UnbindGARTMemory: unbind key 1 (II) intel(0): xf86UnbindGARTMemory: unbind key 2 (II) intel(0): xf86UnbindGARTMemory: unbind key 3 (II) intel(0): xf86UnbindGARTMemory: unbind key 4 (II) intel(0): [drm] removed 1 reserved context for kernel (II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x2ad7d4f39000 FreeFontPath: FPE "/usr/share/fonts/misc/" refcount is 2, should be 1; fixing. (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) intel(0): Kernel reported 488704 total, 1 used (II) intel(0): I830CheckAvailableMemory: 1954812 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) intel(0): [drm] DRM interface version 1.3 (II) intel(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) intel(0): [drm] added 8192 byte SAREA at 0x2efff000 (II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x2ad7d4f39000 (II) intel(0): [drm] framebuffer handle = 0xe0000000 (II) intel(0): [drm] added 1 reserved context for kernel (WW) intel(0): Removed DRI frontbuffer mapping in compatibility mode. (WW) intel(0): DRIGetDeviceInfo will report incorrect frontbuffer handle. (==) intel(0): VideoRam: 262144 KB (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (II) intel(0): Attempting memory allocation with tiled buffers. (WW) intel(0): Allocation error, framebuffer compression disabled (II) intel(0): Success. (II) intel(0): Increasing the scanline pitch to allow tiling mode (1280 -> 2048). (II) intel(0): [drm] Registers = 0xf3100000 (II) intel(0): [drm] ring buffer = 0x2fff9000 (II) intel(0): [drm] mapped front buffer at 0xe1000000, handle = 0xe1000000 (II) intel(0): [drm] mapped back buffer at 0xe0800000, handle = 0xe0800000 (II) intel(0): [drm] mapped depth buffer at 0xe3800000, handle = 0xe3800000 (II) intel(0): [drm] mapped classic textures at 0xe4000000, handle = 0xe4000000 (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432 (II) intel(0): [dri] visual configs initialized (II) intel(0): Page Flipping disabled (==) intel(0): Write-combining range (0xe0000000,0x10000000) (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (WW) intel(0): EXA compatibility mode. Output rotation rendering performance may suffer (II) EXA(0): Offscreen pixmap area of 25165824 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) intel(0): Initializing HW Cursor (II) intel(0): X context handle = 0x1 (II) intel(0): [drm] installed DRM signal handler (II) intel(0): [DRI] installation complete (II) intel(0): [drm] dma control initialized, using IRQ 16 (II) intel(0): Current clock rate multiplier: 1 (II) intel(0): xf86BindGARTMemory: bind key 2 at 0x00800000 (pgoffset 2048) (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x01000000 (pgoffset 4096) (II) intel(0): xf86BindGARTMemory: bind key 1 at 0x02000000 (pgoffset 8192) (II) intel(0): xf86BindGARTMemory: bind key 3 at 0x03800000 (pgoffset 14336) (II) intel(0): xf86BindGARTMemory: bind key 4 at 0x04000000 (pgoffset 16384) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB) (II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB) (II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB) (II) intel(0): 0x00033000-0x00033fff: G33 hw status (4 kB) (II) intel(0): 0x006ff000: end of stolen memory (II) intel(0): 0x00800000-0x00ffffff: back buffer (8192 kB) X tiled (II) intel(0): 0x01000000-0x01ffffff: front buffer (10240 kB) X tiled (II) intel(0): 0x02000000-0x037fffff: exa offscreen (24576 kB) (II) intel(0): 0x03800000-0x03ffffff: depth buffer (8192 kB) X tiled (II) intel(0): 0x04000000-0x05ffffff: classic textures (32768 kB) (II) intel(0): 0x10000000: end of aperture (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe B. (II) intel(0): Output TMDS-1 is connected to pipe A (WW) Option "dpms" requires a boolean value (**) intel(0): DPMS enabled (II) intel(0): Set up textured video (II) intel(0): Set up overlay video (II) intel(0): direct rendering: Enabled (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)(EE) AIGLX: reverting to software rendering (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) intel(0): Setting screen physical size to 376 x 301 (II) Mouse1: ps2EnableDataReporting: succeeded (II) 3rd Button detected: disabling emulate3Button ------------------------------------------------------------------------------------------------------------ xorg.conf ------------------------------------------------------------------------------------------------------------ Section "Module" Load "dbe" SubSection "extmod" Option "omit xfree86-dga" EndSubSection Load "type1" Load "freetype" Load "glx" Load "dri" Load "record" Load "xtrap" EndSection Section "Files" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/ttf-bitstream-vera/" FontPath "/usr/share/fonts/corefonts/" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/CID/" FontPath "/usr/share/fonts/100dpi/" FontPath "/usr/share/fonts/75dpi/" EndSection Section "ServerFlags" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "ch" Option "XkbVariant" "de_nodeadkeys" EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" # IntelliMouse PS/2 Option "Device" "/dev/misc/psaux" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "dummy" Option "Ignore" "True" EndSection Section "Monitor" Identifier "standard-dvi" Option "DPMS" "enable" Option "enable" "True" EndSection Section "Device" Identifier "intel G33" Driver "intel" Option "DRI" "true" Option "XAANoOffscreenPixmaps" "true" Option "FramebufferCompression" "true" Option "Tiling" "true" Option "monitor-VGA" "dummy" Option "monitor-TMDS-1" "standard-dvi" Option "ModeDebug" "false" EndSection Section "Device" Identifier "vesa" Driver "vesa" EndSection Section "Screen" Identifier "Screen 1" Device "intel G33" #Device "vesa" Monitor "standard-dvi" DefaultDepth 24 Subsection "Display" Depth 24 ViewPort 0 0 EndSubsection EndSection Section "ServerLayout" Identifier "Simple Layout" Screen "Screen 1" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection Section "Extensions" Option "Composite" "enable" EndSection Section "DRI" Mode 0666 EndSection From bernie at codewiz.org Sun Dec 16 15:48:09 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sun, 16 Dec 2007 18:48:09 -0500 Subject: xcalloc called from signal handler In-Reply-To: <476584ED.9060502@laas.fr> References: <476584ED.9060502@laas.fr> Message-ID: <4765B939.5010203@codewiz.org> Matthieu Herrb wrote: > Unfortunalty the xserver 1.4 new Xinput code calls xcalloc() in > functions that are called by the SIGIO handler. This has been identified > as the cause of many X server segfaults on OpenBSD, and will probably > also cause random problems on other systems. I've observed such problems on Linux too, when you try to quit the X server through SIGINT. + /* Preallocate xEvent store */ + if (!xf86Events) + xf86Events = (xEvent *)xcalloc(sizeof(xEvent), GetMaximumEventsNum()); + if (!xf86Events) + FatalError("Couldn't allocate event store\n"); The error message is never going to show up because xcalloc() is supposed to automatically abort() on failure. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From khc at pm.waw.pl Sun Dec 16 15:50:22 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 17 Dec 2007 00:50:22 +0100 Subject: interlace modes support for intel driver In-Reply-To: <47659C9A.9020307@rega-sense.ch> (Beat Kneubuehl's message of "Sun, 16 Dec 2007 22:46:02 +0100") References: <47659C9A.9020307@rega-sense.ch> Message-ID: Beat Kneubuehl writes: > I know that the hardware (G33) is perfectly able to do 1080i with my TV, > because it works with the Windows driver, I guess G33 doesn't have 2D video overlay and always uses textured overlay? Interlaced mode support is not a real problem here, I have a patch which generally works (though may need some additional, probably trivial work, and I tested only PAL 576i). The problem is the lack of frame synchronization between the program (X client) and the Xserver/hardware. Is it now possible to have frame synchronization, using textured Xv? I mean, Xserver switching active video frames on vertical retrace or something like that. > I think it might be a valuable feature to support interlace modes, > because lot's of TV screens are floating around which are not 1080p > capable, and even when they support 1080p, it might be easier to let > the TV screen to the deinterlacing work and send him a 1080i signal. Right. -- Krzysztof Halasa From dickey at his.com Sun Dec 16 16:04:23 2007 From: dickey at his.com (Thomas Dickey) Date: Sun, 16 Dec 2007 19:04:23 -0500 (EST) Subject: xcalloc called from signal handler In-Reply-To: <4765B939.5010203@codewiz.org> References: <476584ED.9060502@laas.fr> <4765B939.5010203@codewiz.org> Message-ID: <20071216190332.W98625@mail101.his.com> On Sun, 16 Dec 2007, Bernardo Innocenti wrote: > The error message is never going to show up because xcalloc() is > supposed to automatically abort() on failure. indeed. (one of the things abort() does is dump core ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From daniel at fooishbar.org Sun Dec 16 16:36:27 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 17 Dec 2007 02:36:27 +0200 Subject: xcalloc called from signal handler In-Reply-To: <4765B939.5010203@codewiz.org> References: <476584ED.9060502@laas.fr> <4765B939.5010203@codewiz.org> Message-ID: <20071217003627.GB20109@fooishbar.org> On Sun, Dec 16, 2007 at 06:48:09PM -0500, Bernardo Innocenti wrote: > Matthieu Herrb wrote: > > Unfortunalty the xserver 1.4 new Xinput code calls xcalloc() in > > functions that are called by the SIGIO handler. This has been identified > > as the cause of many X server segfaults on OpenBSD, and will probably > > also cause random problems on other systems. > > I've observed such problems on Linux too, when you try to quit the X server > through SIGINT. Feel free to file bugs (or, better, send patches) for malloc() on exit or in signal handlers. > + /* Preallocate xEvent store */ > + if (!xf86Events) > + xf86Events = (xEvent *)xcalloc(sizeof(xEvent), GetMaximumEventsNum()); > + if (!xf86Events) > + FatalError("Couldn't allocate event store\n"); > > The error message is never going to show up because xcalloc() is > supposed to automatically abort() on failure. Er, in which parallel universe? _X_EXPORT void * Xcalloc(unsigned long amount) { unsigned long *ret; ret = Xalloc (amount); if (ret) bzero ((char *) ret, (int) amount); return ret; } Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bernie at codewiz.org Sun Dec 16 18:53:01 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sun, 16 Dec 2007 21:53:01 -0500 Subject: xcalloc called from signal handler In-Reply-To: <20071217003627.GB20109@fooishbar.org> References: <476584ED.9060502@laas.fr> <4765B939.5010203@codewiz.org> <20071217003627.GB20109@fooishbar.org> Message-ID: <4765E48D.9040402@codewiz.org> Daniel Stone wrote: > On Sun, Dec 16, 2007 at 06:48:09PM -0500, Bernardo Innocenti wrote: >> Matthieu Herrb wrote: >>> Unfortunalty the xserver 1.4 new Xinput code calls xcalloc() in >>> functions that are called by the SIGIO handler. This has been identified >>> as the cause of many X server segfaults on OpenBSD, and will probably >>> also cause random problems on other systems. >> I've observed such problems on Linux too, when you try to quit the X server >> through SIGINT. > > Feel free to file bugs (or, better, send patches) for malloc() on exit > or in signal handlers. This is my original post: http://lists.freedesktop.org/archives/xorg/2007-March/022406.html And these are the bugs I filed back then: https://bugs.freedesktop.org/show_bug.cgi?id=10212 https://bugs.freedesktop.org/show_bug.cgi?id=10213 The second one I never got to reproduce because I now have a working XKB setup... >> The error message is never going to show up because xcalloc() is >> supposed to automatically abort() on failure. > > Er, in which parallel universe? > > _X_EXPORT void * > Xcalloc(unsigned long amount) > { > unsigned long *ret; > > ret = Xalloc (amount); > if (ret) > bzero ((char *) ret, (int) amount); > return ret; > } Oh, I had assumed Xalloc() had this semantic because this is what the xfoo() allocators do in GNU projects. But, the real thing behaves like this: _X_EXPORT void * Xalloc(unsigned long amount) { register pointer ptr; if ((long)amount <= 0) { return (unsigned long *)NULL; } /* aligned extra on long word boundary */ amount = (amount + (sizeof(long) - 1)) & ~(sizeof(long) - 1); #ifdef MEMBUG if (!Must_have_memory && Memory_fail && ((random() % MEM_FAIL_SCALE) < Memory_fail)) return (unsigned long *)NULL; #endif if ((ptr = (pointer)malloc(amount))) { return (unsigned long *)ptr; } if (Must_have_memory) FatalError("Out of memory"); return (unsigned long *)NULL; } ... the behavior is actually configurable through the global variable Must_have_memory, which is usually NULL and gets flicked to TRUE in specific places, like so: Must_have_memory = TRUE; /* XXX */ spriteTrace = (WindowPtr *)xrealloc( spriteTrace, spriteTraceSize*sizeof(WindowPtr)); Must_have_memory = FALSE; /* XXX */ What a horrible semantics for an allocator! Would you approve a set of patches that converts our codebase to use the regular malloc() and free() and kill off this custom allocator? I'd be delighted to do it. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From rich at wittyname.com Sun Dec 16 19:05:02 2007 From: rich at wittyname.com (Rich Aycock) Date: Sun, 16 Dec 2007 19:05:02 -0800 Subject: Noisy picture with intel driver and DVI ADD2 card Message-ID: I've got an Intel G33 that I'm trying to hook up to my 720p DLP TV. I'm using an ADD2 card to output DVI to my Toshiba 42HM66 HDMI input. The picture comes up but there is a lot of noise (speckles bouncing around all over the TV) and occasional flickering. In the Xorg log I see this line: (EE) intel(0): First SDVO output reported failure to sync which I think is the source of the problem. When I use 640x480 intead of 1280x720 (720p) the picture is fine and I don't get that error above. I also hooked an LCD monitor up to it via DVI and it worked fine. I've used the DVI out on my cable box with this TV without problems. Any ideas of how to fix this, or is it just a buggy TV? I'm using v2.2.0 of the intel driver from Debian Unstable. I've attached my xorg.conf and Xorg.0.log. Thanks in advance for any help you can provide. Rich -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 33707 bytes Desc: not available URL: From irwin at beluga.phys.uvic.ca Sun Dec 16 19:43:43 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 16 Dec 2007 19:43:43 -0800 (PST) Subject: [xorg] Noisy picture with intel driver and DVI ADD2 card In-Reply-To: References: Message-ID: On 2007-12-16 19:05-0800 Rich Aycock wrote: > I've got an Intel G33 that I'm trying to hook up to my 720p DLP TV. I'm using > an ADD2 card to output DVI to my Toshiba 42HM66 HDMI input. The picture > comes up but there is a lot of noise (speckles bouncing around all over the > TV) and occasional flickering. In the Xorg log I see this line: > > (EE) intel(0): First SDVO output reported failure to sync > > which I think is the source of the problem. When I use 640x480 intead of > 1280x720 (720p) the picture is fine and I don't get that error above. I also > hooked an LCD monitor up to it via DVI and it worked fine. I've used the DVI > out on my cable box with this TV without problems. Any ideas of how to fix > this, or is it just a buggy TV? > > I'm using v2.2.0 of the intel driver from Debian Unstable. I've attached my > xorg.conf and Xorg.0.log. This issue may be related to bug 13399. There I reported a problem with my g33 chipset without ADD2 card. I couldn't get the Debian unstable driver to work at all (keyboard lockup + monitor in extreme power save mode) unless I applied the i830-restore-pipeconf-fix.patch from bug #13196 to version 2.2.0. So you might want to try that patch yourself. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nian.wu at intel.com Sun Dec 16 20:57:03 2007 From: nian.wu at intel.com (Wu, Nian) Date: Mon, 17 Dec 2007 12:57:03 +0800 Subject: 945GM xrandr and DRI configuration In-Reply-To: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> Message-ID: <1104166E0B63A341805FDB977862AAD2010320EC@pdsmsx414.ccr.corp.intel.com> Please uncomment below lines in your xorg.conf: # Load "dri" #Section "DRI" # Mode 0666 #EndSection -Nian Wu -----Original Message----- From: xorg-bounces at lists.freedesktop.org [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of Albert Vilella Sent: 2007?12?15? 18:24 To: xorg at lists.freedesktop.org Subject: 945GM xrandr and DRI configuration Hi, I've got a sony sz1xp laptop with an intel 945GM. Is it possible to have a configuration that would allow me to configure the external screens / projectors with xrandr and yet to have DRI enabled when not plugged? Right now, my xrandr configuration works, but I don't have acceleration when using only the laptop's screen. xorg.conf attached. Thanks in advance, Cheers, Albert. From dparsons at debian.org Sun Dec 16 04:12:35 2007 From: dparsons at debian.org (Drew Parsons) Date: Sun, 16 Dec 2007 23:12:35 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712131701.10250.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712131111.42297.jbarnes@virtuousgeek.org> <1197588501.17258.31.camel@localhost.localdomain> <200712131701.10250.jbarnes@virtuousgeek.org> Message-ID: <1197807155.6102.7.camel@localhost.localdomain> On Thu, 2007-12-13 at 17:01 -0800, Jesse Barnes wrote: > On Thursday, December 13, 2007 3:28 pm Drew Parsons wrote: > > > > I think it broke in intel 2.2. That is, I had been using linux 2.6.22 + > > intel 2.1.1 at the point where S3 suspend worked [1], but after the > > upgrade to intel 2.2 last month, still with linux 2.6.22, resume no > > longer worked. > > Does it hang or crash now? Or just not restore the display? These 855GM > chips are starting to drive me crazy... > S3 resume simply doesn't restore the display. Resume works fine, that is I can get to the virtual consoles with [Ctrl-]Alt-Fn and login. But the X display initially comes up black, except for the mouse. The mouse cursor itself is properly displayed and moves around. Then when I return to X from the vc via Alt-F7, I can see some of the windows with the background behind. The background at this point is painted correctly but the windows are only grey boxes, not fully formed. A couple of corrupted icons appear in the top right corner where the Gnome Notification icons in the panel would be. But none of the windows (gnome-terminals) seem to respond, keyboard doesn't seem to work (except that Ctrl-Alt-Fn still returns to virtual consoles). I ended up rebooting from vc. Drew From pangdae at gmail.com Sun Dec 16 23:13:37 2007 From: pangdae at gmail.com (Pang Dawei) Date: Mon, 17 Dec 2007 15:13:37 +0800 Subject: How the scancode convert to x keycode/keysym Message-ID: Hi,there, Could you give me some idea about how the scancode convert to X keycode/keysum? For example, the scancode of WIN key is the e05b, I use the xev to test the same key, the xev showed the keycode is 115. I want to know what the algorithm to convert from the 5b to 115 and what part of Xorg source code is related to the algorithm. Thank you very much. -- --Pang Dawei From linuxhippy at gmail.com Mon Dec 17 01:25:41 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 17 Dec 2007 10:25:41 +0100 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <1197837776.4462.17.camel@localhost> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> <1197837776.4462.17.camel@localhost> Message-ID: <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> Hi Eric, > No, non-965 doesn't wait for rendering like that. Does this mean we should not expect major composition performance improvements on non-965 hardware with new drivers? Thanks a lot, lg Clemens From avilella at gmail.com Mon Dec 17 01:27:13 2007 From: avilella at gmail.com (Albert Vilella) Date: Mon, 17 Dec 2007 09:27:13 +0000 Subject: 945GM xrandr and DRI configuration In-Reply-To: <1104166E0B63A341805FDB977862AAD2010320EC@pdsmsx414.ccr.corp.intel.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> <1104166E0B63A341805FDB977862AAD2010320EC@pdsmsx414.ccr.corp.intel.com> Message-ID: <358f4d650712170127k7d2fc7ddge7c15c1caff65ae@mail.gmail.com> It doesn't work either. I attach an xorg.conf for which DRI works, but no xrandr, and viceversa. On Dec 17, 2007 4:57 AM, Wu, Nian wrote: > > Please uncomment below lines in your xorg.conf: > > # Load "dri" > > #Section "DRI" > # Mode 0666 > #EndSection > > > -Nian Wu > > > -----Original Message----- > From: xorg-bounces at lists.freedesktop.org [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of Albert Vilella > Sent: 2007?12?15? 18:24 > To: xorg at lists.freedesktop.org > Subject: 945GM xrandr and DRI configuration > > Hi, > > I've got a sony sz1xp laptop with an intel 945GM. Is it possible to > have a configuration > that would allow me to configure the external screens / projectors > with xrandr and yet > to have DRI enabled when not plugged? > > Right now, my xrandr configuration works, but I don't have > acceleration when using only > the laptop's screen. > > xorg.conf attached. > > Thanks in advance, > > Cheers, > > Albert. > -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf.intel.3d Type: application/octet-stream Size: 5893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf.intel.xrandr Type: application/octet-stream Size: 6904 bytes Desc: not available URL: From nian.wu at intel.com Mon Dec 17 01:31:39 2007 From: nian.wu at intel.com (Wu, Nian) Date: Mon, 17 Dec 2007 17:31:39 +0800 Subject: 945GM xrandr and DRI configuration In-Reply-To: <358f4d650712170127k7d2fc7ddge7c15c1caff65ae@mail.gmail.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> <1104166E0B63A341805FDB977862AAD2010320EC@pdsmsx414.ccr.corp.intel.com> <358f4d650712170127k7d2fc7ddge7c15c1caff65ae@mail.gmail.com> Message-ID: <1104166E0B63A341805FDB977862AAD20103232C@pdsmsx414.ccr.corp.intel.com> You can attach xorg.log which is more helpful. -Nian -----Original Message----- From: Albert Vilella [mailto:avilella at gmail.com] Sent: 2007?12?17? 17:27 To: Wu, Nian Cc: xorg at lists.freedesktop.org Subject: Re: 945GM xrandr and DRI configuration It doesn't work either. I attach an xorg.conf for which DRI works, but no xrandr, and viceversa. On Dec 17, 2007 4:57 AM, Wu, Nian wrote: > > Please uncomment below lines in your xorg.conf: > > # Load "dri" > > #Section "DRI" > # Mode 0666 > #EndSection > > > -Nian Wu > > > -----Original Message----- > From: xorg-bounces at lists.freedesktop.org [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of Albert Vilella > Sent: 2007?12?15? 18:24 > To: xorg at lists.freedesktop.org > Subject: 945GM xrandr and DRI configuration > > Hi, > > I've got a sony sz1xp laptop with an intel 945GM. Is it possible to > have a configuration > that would allow me to configure the external screens / projectors > with xrandr and yet > to have DRI enabled when not plugged? > > Right now, my xrandr configuration works, but I don't have > acceleration when using only > the laptop's screen. > > xorg.conf attached. > > Thanks in advance, > > Cheers, > > Albert. > From avilella at gmail.com Mon Dec 17 01:42:32 2007 From: avilella at gmail.com (Albert Vilella) Date: Mon, 17 Dec 2007 09:42:32 +0000 Subject: 945GM xrandr and DRI configuration In-Reply-To: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> Message-ID: <358f4d650712170142g4b09be44p101ec0b86ed65a65@mail.gmail.com> attached On Dec 15, 2007 10:23 AM, Albert Vilella wrote: > Hi, > > I've got a sony sz1xp laptop with an intel 945GM. Is it possible to > have a configuration > that would allow me to configure the external screens / projectors > with xrandr and yet > to have DRI enabled when not plugged? > > Right now, my xrandr configuration works, but I don't have > acceleration when using only > the laptop's screen. > > xorg.conf attached. > > Thanks in advance, > > Cheers, > > Albert. > -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 51716 bytes Desc: not available URL: From bve at gmx.de Mon Dec 17 03:24:50 2007 From: bve at gmx.de (Ben E. Hard) Date: Mon, 17 Dec 2007 12:24:50 +0100 Subject: blank screen on LVDS when VGA connected In-Reply-To: <200712101146.00103.bve@gmx.de> References: <200712101146.00103.bve@gmx.de> Message-ID: <200712171224.51281.bve@gmx.de> Am Montag, 10. Dezember 2007 schrieb Ben E. Hard: > Hi, > > when I have a VGA-Monitor connected to my Sony Vaio Laptop (PCG-R600 HFPD), > the internal LVDS gets deactivated. I tried all the xrandr --output > LVDS --left-of VGA stuff, nothing changes. System: debian lenny, > xserver-xorg-video-intel 2.1.0-2 (now trying with xserver-xorg-video-intel > 2.2.0-1 from debian unstable). However, kde thinks, that there is a second > monitor, where it can put my applications, which I cannot see than. > > The tool i810switch or i810rotate permits me to reactivate the internal > monitor, giving me a clone of the other. xrandr -q shows me, that I can > disconnect the ouptut VGA with i810rotate, but not the LVDS, which is > always shown as "connected" in xrandr -q. Still not found any solution, but as I can see with i810switch, the internal display get's deactivated through xrandr --output LVDS --left-of VGA. i810switch tells me, that CRT (the ext. output) is activated, while lcd is deactivated after executing the xrandr-command. When I try to change the crtc with xrandr --output LVDS --crtc 0 X crashes. Find the Xorg.0.log at http://nopaste.debianforum.de/7142 Greetings, Ben From pratish.ganguly at gmail.com Mon Dec 17 04:38:36 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Mon, 17 Dec 2007 18:08:36 +0530 Subject: Xephyr crashing on 8 bit connection attempt Message-ID: Dear all I am using Xorg version 7.2 on a AMD Geode. When I am trying to connect to a X server using Xephyr at 8 bit depth, the connection is terminated abruptly, while the same connection at any other depth is connecting without any problem. Am I missing something here ? Please provide me some pointer to the solution of the above problem. With best regards Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.thum at gmx.de Mon Dec 17 05:09:33 2007 From: simon.thum at gmx.de (Simon Thum) Date: Mon, 17 Dec 2007 14:09:33 +0100 Subject: minor build problem Message-ID: <4766750D.3020609@gmx.de> Hi all, I just recompiled a fresh git xserver and had: /usr/src/xorg/build/include/X11/Xdefs.h:49: error: redefinition of typedef ?Bool? ../../Xext/dpmsstubs.c:29: error: previous declaration of ?Bool? was here Removing the latter did the trick, so I guess it is an oversight. Maybe someone can fix it? -- Simon From sidkapoor2000 at gmail.com Mon Dec 17 06:22:12 2007 From: sidkapoor2000 at gmail.com (Sid Kapoor) Date: Mon, 17 Dec 2007 19:52:12 +0530 Subject: Xephyr crashing with -grayscale option on amd geode Message-ID: hi, I am having a customised linux distribution installed on a thin client with the following configuration. AMD LX800 128MB RAM Xorg version 7.2 The display driver that I am using is from xorg git http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary On running the Xephyr binary in this thin client with -grayscale option, it opens the login page and then crashes without giving any warnings or error. Ex: Xephyr -once -query 107.108.92.137 -fp /usr/share/X11/fonts/misc -grayscale My xorg.conf file is also attached . Any pointers to the solution of the above problem ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 3213 bytes Desc: not available URL: From simon.thum at gmx.de Mon Dec 17 06:56:45 2007 From: simon.thum at gmx.de (Simon Thum) Date: Mon, 17 Dec 2007 15:56:45 +0100 Subject: possible bug In-Reply-To: <474B877F.8070507@who-t.net> References: <474AF85B.7030608@gmx.de> <474B877F.8070507@who-t.net> Message-ID: <47668E2D.7010408@gmx.de> Hi Peter, I think I've found a followup: Again in getdctl.c, l. 300: case DEVICE_CORE: total_length = sizeof(xDeviceCoreCtl); Shouldn't that, if only for consitency, refer to xDevice*State? I don't think those stuctures are actually diffently sized, but they differ for sure. >> I'm currently trying to extend the X*DeviceControl mechanism found in >> Xinput.h, and I think I have found a bug. >> >> E.g. in getdctl.c, l. 134: (not the only occassion) >> >> xDeviceAbsCalibState *calib = (xDeviceAbsCalibState *) buf; >> [...] >> calib->length = sizeof(calib); >> >> AFAIK, sizeof(pointer) is 4 or 8 for most archs, which is too low in >> some if not all cases. This length is pretty much ignored on the server >> side, so we have no problems here. But if I haven't missed a thing, that >> wrong lenght still makes it to the client, asking for trouble there. > > thanks. yes, that was a bug. fixed and pushed. > > same bug was btw also in the libXi decoding of the same request. fixed too. > > thanks again. > > Cheers, > Peter > From jbarnes at virtuousgeek.org Mon Dec 17 08:28:26 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 17 Dec 2007 08:28:26 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197807155.6102.7.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> Message-ID: <200712170828.26281.jbarnes@virtuousgeek.org> On Sunday, December 16, 2007 4:12 am Drew Parsons wrote: > On Thu, 2007-12-13 at 17:01 -0800, Jesse Barnes wrote: > > On Thursday, December 13, 2007 3:28 pm Drew Parsons wrote: > > > I think it broke in intel 2.2. That is, I had been using linux 2.6.22 > > > + intel 2.1.1 at the point where S3 suspend worked [1], but after the > > > upgrade to intel 2.2 last month, still with linux 2.6.22, resume no > > > longer worked. > > > > Does it hang or crash now? Or just not restore the display? These 855GM > > chips are starting to drive me crazy... > > S3 resume simply doesn't restore the display. Resume works fine, that > is I can get to the virtual consoles with [Ctrl-]Alt-Fn and login. > > But the X display initially comes up black, except for the mouse. The > mouse cursor itself is properly displayed and moves around. > > Then when I return to X from the vc via Alt-F7, I can see some of the > windows with the background behind. The background at this point is > painted correctly but the windows are only grey boxes, not fully formed. > A couple of corrupted icons appear in the top right corner where the > Gnome Notification icons in the panel would be. But none of the windows > (gnome-terminals) seem to respond, keyboard doesn't seem to work (except > that Ctrl-Alt-Fn still returns to virtual consoles). > > I ended up rebooting from vc. And you're using git tip? Are you using compiz? Sounds like we're definitely not restoring some important state... Jesse From xhejtman at ics.muni.cz Mon Dec 17 08:47:51 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Mon, 17 Dec 2007 17:47:51 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712170828.26281.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> <200712170828.26281.jbarnes@virtuousgeek.org> Message-ID: <20071217164750.GC14091@ics.muni.cz> On Mon, Dec 17, 2007 at 08:28:26AM -0800, Jesse Barnes wrote: > And you're using git tip? Are you using compiz? Sounds like we're > definitely not restoring some important state... He may be facing the same problem I reported at bugzilla. Drew, what is the version of DRI you are using? -- Luk?? Hejtm?nek From e.baldinotti at bancolini.com Mon Dec 17 09:18:47 2007 From: e.baldinotti at bancolini.com (Ezio Baldinotti) Date: Mon, 17 Dec 2007 18:18:47 +0100 Subject: kdrive rotation problems Message-ID: <20071217181847.640d0238@bailey> Using X11R7.3 X.org release, I experienced the following issue. Everything works fine if I run the server with: Xfbdev -keybd keyboard,device=/dev/input/event1 -mouse tslib,,device=/dev/input/event0 Instead, when I rotate the screen with: Xfbdev -screen 240x320 at 90 -keybd keyboard,device=/dev/input/event1 -mouse tslib,,device=/dev/input/event0 The Y coordinate is correctly managed, while the X remains stuck at 0... Any suggestion will be appreciated. Thanks, Ezio Baldinotti From daniel.naughton at gmail.com Mon Dec 17 09:51:49 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Mon, 17 Dec 2007 11:51:49 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? Message-ID: Does the intel 945GM chipset and driver provide 3D hardware acceleration. The program I use to test in (this dungeon shoot'em up game tremulous) complains that there is no hardware acceleration. Does it need to be enabled in the xorg.conf or is it always enabled in the intel driver. The documentation only mentions 3D in the 965, nothing about the 945. I shutoff all the dual head stuff I was running and am using the VGA output on the motherboard. The man page for the i810 driver states that acceleration (I'm assuming that's hardware acceleration) is enabled by default. I see DRI enabled in the log files, but I don't know if enabling DRI and enabling hardware acceleration are the same thing -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: From eric at anholt.net Mon Dec 17 10:10:46 2007 From: eric at anholt.net (Eric Anholt) Date: Mon, 17 Dec 2007 10:10:46 -0800 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> <1197837776.4462.17.camel@localhost> <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> Message-ID: <1197915046.4462.19.camel@localhost> On Mon, 2007-12-17 at 10:25 +0100, Clemens Eisserer wrote: > Hi Eric, > > > No, non-965 doesn't wait for rendering like that. > Does this mean we should not expect major composition performance > improvements on non-965 hardware with new drivers? EXA is a major performance improvement over XAA on my non-965 systems. -- Eric Anholt anholt at FreeBSD.org eric at anholt.net eric.anholt at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part URL: From Magnus.Vigerlof at home.se Mon Dec 17 10:24:57 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-15?q?Vigerl=F6f?=) Date: Mon, 17 Dec 2007 19:24:57 +0100 Subject: [PATCH] dix: Always add valuator information if present In-Reply-To: <20071216174549.GA18414@fooishbar.org> References: <200712161425.10522.Magnus.Vigerlof@home.se> <200712161812.41747.Magnus.Vigerlof@home.se> <20071216174549.GA18414@fooishbar.org> Message-ID: <200712171924.57821.Magnus.Vigerlof@home.se> On s?ndag 16 december 2007, Daniel Stone wrote: [...] > > As long as the net result will be that the coordinates in the InputDevice > > coordinate space will be included in the event that reaches the XClient > > (for example Gimp that doesn't look at the screen-scaled x&y, but will > > use the high-resolution axis that a Wacom tablet will provide). > > Ah! Good point. Yes, we always want to send valuators if they're at all > scaled. But given that we need to send all valuators on motion events > anyway, it doesn't make sense overoptimising the button case. My thought went along some of those lines since it was only relative button-events that didn't get the valuators included. Currently the core and extended x&y are required to be same so they are not scaled at the moment, but I hope the other patch I sent (only sent as an [RFC]) could be used in some way until you will have time to do the real work for 1.6. Btw, the patch removes a possible false unknown event if an absolute Button-event is generated without any valuators. I that case we got the core event and the extended event with the MORE_EVENTS bit set, but the valuator event was never populated so that would be sent with whatever data was in there at the time of event generation. Cheers Magnus From daniel.naughton at gmail.com Mon Dec 17 10:56:36 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Mon, 17 Dec 2007 12:56:36 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? Message-ID: It looks like the direct rendering is a problem. But I'm not sure how to fix it.. This is a fedora 8 distro with the intel driver 945GM chipset. $DISPLAY=:0 glxinfo | grep render direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL renderer string: Mesa GLX Indirect I added the following to the xorg.conf, even though I saw glx and dri enabled already in the Xorg.0.log file, but it didn't do anything. Section "Module" Load "dri" Load "glx" EndSection Section "DRI" Mode 0666 EndSection -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: From daniel.naughton at gmail.com Mon Dec 17 11:09:29 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Mon, 17 Dec 2007 13:09:29 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? Message-ID: I swapped the driver for the i810, but the results were the same. DRI get's disabled during startup after it gets loaded. Not sure what to make of that. I've attached by xorg.conf and the log file, but the part that looks bad is this: (II) intel(0): depth buffer is tiled drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: drmOpenMinor returns 11 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.0 (EE) [drm] Could not set DRM device bus ID. <=== BAD (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. (II) intel(0): Page Flipping disabled -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log.txt URL: From jbarnes at virtuousgeek.org Mon Dec 17 11:20:38 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 17 Dec 2007 11:20:38 -0800 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: References: Message-ID: <200712171120.38652.jbarnes@virtuousgeek.org> On Monday, December 17, 2007 11:09 am Dan Naughton wrote: > I swapped the driver for the i810, but the results were the same. DRI > get's disabled during startup after it gets loaded. Not sure what to make > of that. I've attached by xorg.conf and the log file, but the part that > looks bad is this: > > (II) intel(0): depth buffer is tiled > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 11, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 11, (OK) > drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 11, (OK) > drmOpenByBusid: drmOpenMinor returns 11 > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 > (II) [drm] DRM interface version 1.0 > (EE) [drm] Could not set DRM device bus ID. <=== BAD > (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. > (II) intel(0): Page Flipping disabled Hm, the intel driver definitely supports 3d on 945GM so something is definitely wrong here. What kernel DRM driver are you using? Are you just trying to run a single instance of the X server? Jesse From nsollars at gmail.com Mon Dec 17 12:05:10 2007 From: nsollars at gmail.com (Nigel Sollars) Date: Mon, 17 Dec 2007 15:05:10 -0500 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: <200712171120.38652.jbarnes@virtuousgeek.org> References: <200712171120.38652.jbarnes@virtuousgeek.org> Message-ID: <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> On Dec 17, 2007 2:20 PM, Jesse Barnes wrote: > On Monday, December 17, 2007 11:09 am Dan Naughton wrote: > > I swapped the driver for the i810, but the results were the same. DRI > > get's disabled during startup after it gets loaded. Not sure what to > make > > of that. I've attached by xorg.conf and the log file, but the part that > > looks bad is this: > > > > (II) intel(0): depth buffer is tiled > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 11, (OK) > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 11, (OK) > > drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 11, (OK) > > drmOpenByBusid: drmOpenMinor returns 11 > > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 > > (II) [drm] DRM interface version 1.0 > > (EE) [drm] Could not set DRM device bus ID. <=== BAD > > (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. > > (II) intel(0): Page Flipping disabled > Cetainly agree with below, As i stated earlier youl need agpgart and i915 kernel drm module loaded, Regards Nige > > Hm, the intel driver definitely supports 3d on 945GM so something is > definitely wrong here. > > What kernel DRM driver are you using? Are you just trying to run a single > instance of the X server? > > Jesse > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.naughton at gmail.com Mon Dec 17 12:17:49 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Mon, 17 Dec 2007 14:17:49 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> References: <200712171120.38652.jbarnes@virtuousgeek.org> <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> Message-ID: I think I have them loaded: $ dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 $ dmesg | grep agp Linux agpgart interface v0.102 agpgart: Detected an Intel 945GM Chipset. agpgart: Detected 7932K stolen memory. agpgart: AGP aperture is 256M @ 0xd0000000 $ DISPLAY=:0 glxinfo | grep render direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbo se) OpenGL renderer string: Mesa GLX Indirect On Dec 17, 2007 2:05 PM, Nigel Sollars wrote: > > > On Dec 17, 2007 2:20 PM, Jesse Barnes wrote: > > > On Monday, December 17, 2007 11:09 am Dan Naughton wrote: > > > I swapped the driver for the i810, but the results were the same. DRI > > > get's disabled during startup after it gets loaded. Not sure what to > > make > > > of that. I've attached by xorg.conf and the log file, but the part > > that > > > looks bad is this: > > > > > > (II) intel(0): depth buffer is tiled > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 11, (OK) > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 11, (OK) > > > drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 11, (OK) > > > drmOpenByBusid: drmOpenMinor returns 11 > > > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 > > > (II) [drm] DRM interface version 1.0 > > > (EE) [drm] Could not set DRM device bus ID. <=== BAD > > > (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. > > > (II) intel(0): Page Flipping disabled > > > > Cetainly agree with below, > > As i stated earlier youl need agpgart and i915 kernel drm module loaded, > > Regards > > Nige > > > > > > > > Hm, the intel driver definitely supports 3d on 945GM so something is > > definitely wrong here. > > > > What kernel DRM driver are you using? Are you just trying to run a > > single > > instance of the X server? > > > > Jesse > > _______________________________________________ > > xorg mailing list > > xorg at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xorg > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dm at chello.nl Mon Dec 17 12:20:33 2007 From: dm at chello.nl (Dick) Date: Mon, 17 Dec 2007 20:20:33 +0000 (UTC) Subject: G35/33 X3500/3100 HDMI References: <4752EB4E.9000002@trypill.org> <4765948B.1090705@rega-sense.ch> <47659F6B.3030602@rega-sense.ch> Message-ID: Beat Kneubuehl rega-sense.ch> writes: > Here is my Xorg.0.log and my xorg.conf: Okay thanks, it seems I2C works for you but it doesn't work for my box :-( I've enabled I2C_DEBUG in src/i830_i2c.c and I get the following debug output: Getting SDVOCTRL_E for SDVOB: v ^ SDVOCTRL_E for SDVOB Debug: C D C D Setting SDVOCTRL_E for SDVOB 0x00005020 to: ^ ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ .... Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ Setting SDVOCTRL_E for SDVOC 0x00005020 to: ^ ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ .... Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ Getting SDVOCTRL_E for SDVOC: v ^ I'm wondering if xf86-video-intel is using the correct I2C addresses (0x70 and 0x72). Is there an easy way to detect the I2C addresses? My kernel can't probe i2c-i830 (only i2c-810) using the i2c-utils (from lm_sensors). Who knows what might be going on? Thanks a lot, Dick From justin at mythtvthemes.co.uk Mon Dec 17 12:25:37 2007 From: justin at mythtvthemes.co.uk (Justin Hornsby) Date: Mon, 17 Dec 2007 20:25:37 +0000 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: References: <200712171120.38652.jbarnes@virtuousgeek.org> <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> Message-ID: <4766DB41.2020600@mythtvthemes.co.uk> I recently ran into an issue like this to get DRM worky on my setup, running Ubuntu. All I needed to do was install libgl1-mesa-dri to make it work. Regards, Justin From daniel.naughton at gmail.com Mon Dec 17 12:49:50 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Mon, 17 Dec 2007 14:49:50 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: <4766DB41.2020600@mythtvthemes.co.uk> References: <200712171120.38652.jbarnes@virtuousgeek.org> <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> <4766DB41.2020600@mythtvthemes.co.uk> Message-ID: I guess the packages are different from Ubuntu to Fedora. It looks like the dri stuff is part of mesa-libGL? # rpm -qa | grep mesa mesa-libGLU-7.0.1-7.fc8 mesa-libGL-7.0.1-7.fc8 # rpm -ql mesa-libGL /usr/lib/dri /usr/lib/dri/i810_dri.so /usr/lib/dri/i915_dri.so /usr/lib/dri/i915tex_dri.so /usr/lib/dri/i965_dri.so /usr/lib/dri/mach64_dri.so /usr/lib/dri/mga_dri.so /usr/lib/dri/r128_dri.so /usr/lib/dri/r200_dri.so /usr/lib/dri/r300_dri.so /usr/lib/dri/radeon_dri.so /usr/lib/dri/savage_dri.so /usr/lib/dri/tdfx_dri.so /usr/lib/dri/unichrome_dri.so /usr/lib/libGL.so.1 /usr/lib/libGL.so.1.2 On Dec 17, 2007 2:25 PM, Justin Hornsby wrote: > I recently ran into an issue like this to get DRM worky on my setup, > running Ubuntu. All I needed to do was install libgl1-mesa-dri to make > it work. > > Regards, > Justin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamish at travellingkiwi.com Mon Dec 17 14:03:50 2007 From: hamish at travellingkiwi.com (Hamie) Date: Mon, 17 Dec 2007 22:03:50 +0000 Subject: Best way of determining multiple monitor config? Message-ID: <200712172203.52352.hamish@travellingkiwi.com> Hi. What's the current recommended method of an application determining the configuration of (Possibly) multiple monitor setup? Should I still use the libXinerama calls? Or are there 'better' calls to use nowadays? TIA Hamish. -------------- 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 xhejtman at ics.muni.cz Mon Dec 17 14:50:13 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Mon, 17 Dec 2007 23:50:13 +0100 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <1197915046.4462.19.camel@localhost> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> <1197837776.4462.17.camel@localhost> <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> <1197915046.4462.19.camel@localhost> Message-ID: <20071217225013.GF14091@ics.muni.cz> On Mon, Dec 17, 2007 at 10:10:46AM -0800, Eric Anholt wrote: > > > No, non-965 doesn't wait for rendering like that. > > Does this mean we should not expect major composition performance > > improvements on non-965 hardware with new drivers? > > EXA is a major performance improvement over XAA on my non-965 systems. I disagree. Text scrolling in terminals was much slower with EXA than XAA. Similarly, firefox and desktop switching was faster with XAA. Unfortunatly, other types of operations are not used much at my system. I had i915GM. -- Luk?? Hejtm?nek From jbarnes at virtuousgeek.org Mon Dec 17 14:53:31 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 17 Dec 2007 14:53:31 -0800 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: References: <1c130fc90712171205k4c0de21amf88316a70b5a1a0d@mail.gmail.com> Message-ID: <200712171453.31563.jbarnes@virtuousgeek.org> On Monday, December 17, 2007 12:17 Dan Naughton wrote: > I think I have them loaded: > > $ dmesg | grep drm > [drm] Initialized drm 1.1.0 20060810 > [drm] Initialized i915 1.6.0 20060119 on minor 0 > > $ dmesg | grep agp > Linux agpgart interface v0.102 > agpgart: Detected an Intel 945GM Chipset. > agpgart: Detected 7932K stolen memory. > agpgart: AGP aperture is 256M @ 0xd0000000 Ok, those look good. > $ DISPLAY=:0 glxinfo | grep render > direct rendering: No (If you want to find out why, try setting > LIBGL_DEBUG=verbo > se) > OpenGL renderer string: Mesa GLX Indirect Obviously this doesn't. :) Did you build your own version of X or your own Intel driver? Or are you just using the Fedora binary packages? Jesse From jbarnes at virtuousgeek.org Mon Dec 17 15:08:19 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 17 Dec 2007 15:08:19 -0800 Subject: Output problems with 945GM In-Reply-To: <476289F8.40608@kaasa.com> References: <4757FF1F.4060500@kaasa.com> <200712101738.19906.jbarnes@virtuousgeek.org> <476289F8.40608@kaasa.com> Message-ID: <200712171508.20029.jbarnes@virtuousgeek.org> On Friday, December 14, 2007 5:49 Matteo Brusa wrote: > > Hm, I think using DVI is your best bet (it'll probably give you the > > best picture quality) but your TV doesn't seem to provide a > > 1360x768 resolution in its EDID data? Or are you overriding it > > somehow? > > > > Can you post your xorg.conf and Xorg.0.log files? > > I auto reconfigured X with the VGA cable plugged, see attached file. > Interesting note, when connected via the DVI-HDMI cable, the monitor > offers no EDID info whatsoever. I have a Hanns-G monitor on my desk that does the same thing. It may be that the X DDC code isn't forgiving enough to some HDMI->DVI timings... > I also attach the Xorg.0.log files > for both VGA and TDMI-1. > The VGA output clearly runs at 1360x768 without overscan, while the > TDMI-1 runs at 1280x720 with overscan. Still i couldn't reach digital > 1360x768. > Is it true, that in order to accept my custom modelines, i have to > specify 'Option "DDC" "off"' in the device section? > Last but not least, is there an 'official' Modeline for 1920x1080p? I'm not sure if disabling DDC is required to program custom mode lines since I've never had to use them. I guess in your case it shouldn't make a difference since DDC is failing anyway. As for a 1920x1080 modeline, I'm not sure. A cvt -r generated mode line will probably work though... Jesse From jbarnes at virtuousgeek.org Mon Dec 17 15:13:32 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 17 Dec 2007 15:13:32 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197807155.6102.7.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> Message-ID: <200712171513.33017.jbarnes@virtuousgeek.org> On Sunday, December 16, 2007 4:12 Drew Parsons wrote: > On Thu, 2007-12-13 at 17:01 -0800, Jesse Barnes wrote: > > On Thursday, December 13, 2007 3:28 pm Drew Parsons wrote: > > > I think it broke in intel 2.2. That is, I had been using linux > > > 2.6.22 + intel 2.1.1 at the point where S3 suspend worked [1], > > > but after the upgrade to intel 2.2 last month, still with linux > > > 2.6.22, resume no longer worked. > > > > Does it hang or crash now? Or just not restore the display? These > > 855GM chips are starting to drive me crazy... > > S3 resume simply doesn't restore the display. Resume works fine, > that is I can get to the virtual consoles with [Ctrl-]Alt-Fn and > login. > > But the X display initially comes up black, except for the mouse. The > mouse cursor itself is properly displayed and moves around. > > Then when I return to X from the vc via Alt-F7, I can see some of the > windows with the background behind. The background at this point is > painted correctly but the windows are only grey boxes, not fully > formed. A couple of corrupted icons appear in the top right corner > where the Gnome Notification icons in the panel would be. But none > of the windows (gnome-terminals) seem to respond, keyboard doesn't > seem to work (except that Ctrl-Alt-Fn still returns to virtual > consoles). > > I ended up rebooting from vc. This may be an EXA bug (we moved to EXA by default in 2.2). Zhenyu recently fixed an EXA suspend/resume bug in the git tree, can you give it a try and see if you still see problems? Thanks, Jesse From dkasak at nusconsulting.com.au Mon Dec 17 15:48:45 2007 From: dkasak at nusconsulting.com.au (Daniel Kasak) Date: Tue, 18 Dec 2007 10:48:45 +1100 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <1197915046.4462.19.camel@localhost> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> <1197837776.4462.17.camel@localhost> <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> <1197915046.4462.19.camel@localhost> Message-ID: <1197935325.31462.13.camel@dkasak.nusconsulting.com.au> On Mon, 2007-12-17 at 10:10 -0800, Eric Anholt wrote: > EXA is a major performance improvement over XAA on my non-965 systems. It's most certainly not on mine. Our in-house Gtk2 app has a notebook with a number of pages. With the 2.2 driver and EXA, you can actually see each widget being rendered when you switch pages, which takes about 2-3 seconds. It's painful. With XAA, it used to be quite snappy ( pretty much instant ). I can't use XAA, because it causes X to lock when compiz starts. Unfortunately I also can't downgrade to 2.1.x because I have to downgrade mesa, and last time I tried that, I lost 3D acceleration altogether, and instead of trying to figure out why, I just restored everything to it's previous state and got back to work. Anyway, without complaining too much ( I realise I'm running unstable software, etc, etc ... I'm mainly responding to the comment at the top ), let me just say that EXA is a MAJOR performance regression on my system. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: dkasak at nusconsulting.com.au website: http://www.nusconsulting.com.au From simon.farnsworth at onelan.co.uk Mon Dec 17 02:05:06 2007 From: simon.farnsworth at onelan.co.uk (Simon Farnsworth) Date: Mon, 17 Dec 2007 10:05:06 +0000 Subject: Problems using 1920x1080 on a 965 with the Intel driver In-Reply-To: <47625D0D.80703@onelan.co.uk> References: <47614B61.7060906@onelan.co.uk> <1197625007.16934.33.camel@localhost> <476255CF.5040302@onelan.co.uk> <1197627317.16934.42.camel@localhost> <47625D0D.80703@onelan.co.uk> Message-ID: <476649D2.50201@onelan.co.uk> Simon Farnsworth wrote: > Alan Hourihane wrote: >> On Fri, 2007-12-14 at 10:07 +0000, Simon Farnsworth wrote: >>> Allowing the driver to use DDC makes it work, so I suspect your "reduced >>> blank" hunch is right. How do I generate a modeline with "reduced blank"? >>> >> The 1920x1080 mode you already have with the 138.5MHz pixel clock is >> already the "reduced blank" mode. You just have to make sure that the >> 173MHz pixel clock mode is removed, or you change the name of the >> 138.5MHz clock to something like 1920x1080R and force that in your >> selection. > > This works. We've added some extra text to our custom modelines, to > ensure that they'll never have the same name as a built-in modeline. Just one more bit of information for the list; the driver in shipped Fedora 8 does not work, but 2.2.0 compiled from source does. -- Simon Farnsworth From regina.anger at hotmail.com Mon Dec 17 16:40:59 2007 From: regina.anger at hotmail.com (Regina Anger) Date: Tue, 18 Dec 2007 01:40:59 +0100 Subject: Status of EXA with intel-2.2.0 In-Reply-To: <1197935325.31462.13.camel@dkasak.nusconsulting.com.au> References: <200712120926.18862.jbarnes@virtuousgeek.org> <194f62550712121051x6be14e90h91d5b4ab9147330c@mail.gmail.com> <1197837776.4462.17.camel@localhost> <194f62550712170125x5882e6bdmda99d561c166426a@mail.gmail.com> <1197915046.4462.19.camel@localhost> <1197935325.31462.13.camel@dkasak.nusconsulting.com.au> Message-ID: > > EXA is a major performance improvement over XAA on my non-965 systems. > > It's most certainly not on mine. This is also the reson why I asked before updating my whole system. The state of XAA is pretty bad - almost everything results in software-fallbacks (even drawcirle??) - which are too slow for my needs. I am currently implementing some 2D heavy stuff and although EXA does some things quite well, it was still too slow last time i tried it - it even slowed down overall GUI feeling. So, I also join the question: Will we see major performance increases with newer drivers, or is the hardware really that limited? Thanks, Regina _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles_hibbits at yahoo.com Mon Dec 17 19:43:16 2007 From: charles_hibbits at yahoo.com (Charles Hibbits) Date: Mon, 17 Dec 2007 19:43:16 -0800 (PST) Subject: radeon 9000 (rv250) tV-out troubles Message-ID: <830408.69555.qm@web51809.mail.re2.yahoo.com> Thank you for the quick response. I tried the values you suggested for the org.conf file. They do not seem to change anything. The xvattr worked great though. I noticed something that may be of interest. If I have a monitor attached GDM starts up fine (minus tv-out). If I start up without the monitor attached, I get a message about Ubuntu is running in low-graphics mode it also modifies my xorg.conf to have all sorts of "failsafe" values in it. Also, I fiddled with the xrandr command order a bit and found I can get away with fewer commands as such: xrandr --addmode S-video 800x600 xrandr --output S-video --set tv_standard ntsc xrandr --output S-video --mode 800x600 Monitor-less is also how I used this machine in xorg 7.2. ----- Original Message ---- From: Alex Deucher To: Charles Hibbits Cc: xorg at lists.freedesktop.org Sent: Thursday, December 13, 2007 7:58:02 PM Subject: Re: radeon 9000 (rv250) tV-out troubles On Dec 13, 2007 10:17 PM, Charles Hibbits wrote: > I realize this has been discussed to some degree, but I may not be understanding the instructions correctly so I apologize for another thread. I have an Sapphire Radeon 9000 64MB with TV out. Everything was running fine with the patched opensource driver on Ubuntu Feisty (xorg 7.2 I believe). Saturday I upgraded to Gutsy (xorg 7.3) and I lost the tv out. At first the gnome X configuration tool set it to a VESA driver which produced black and white TV out. When I use the XORG ATI driver the TV out goes away. > > After searching around I found the following commands can be issued to make it work sorta: > > # xrandr --addmode S-video 800x600 > # xrandr --output S-video --mode 800x600 > # xrandr --output S-video --set tv_standard ntsc > # xrandr --output S-video --off > # xrandr --output S-video --mode 800x600 > > http://lists.freedesktop.org/archive...er/029292.html > > The problem is this is not static, after reboot I loose the TV out again. Also My main usage of this computer is to run mythtv, but the video will not play on the TV, only the monitor. I assume this has something to do with it not being treated as a primary display or something to that effect. I assume there is something wrong with my xorg.conf, but I have not been able to find the right options. Here is my xorg.conf: You can force the TV on with the following options (add to the device section of your config): Option "ForceTVOut" "true" Option "TVStandard" "ntsc" As for the overlay, it can only be sourced to one crtc at a time. In dualhead mode it follows the video window. In clone mode you have to explicitly tell it which crtc to source to. Use an application like xvattr to select the crtc for the overlay: xvattr -a XV_CRTC -v 1 possible values: -1 auto 0 crtc0 1 crtc1 Alex ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From pratish.ganguly at gmail.com Mon Dec 17 20:49:15 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Tue, 18 Dec 2007 10:19:15 +0530 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: References: Message-ID: Dear all This is the Xorg log file that is created on my system. On 12/17/07, pratish ganguly wrote: > > Dear all > > I am using Xorg version 7.2 on a AMD Geode. When I am trying to connect to > a X server using Xephyr at 8 bit depth, the connection is terminated > abruptly, while the same connection at any other depth is connecting without > any problem. > Am I missing something here ? > Please provide me some pointer to the solution of the above problem. > > With best regards > Pratish Ganguly > With best regards Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 29293 bytes Desc: not available URL: From sidkapoor2000 at gmail.com Mon Dec 17 20:55:58 2007 From: sidkapoor2000 at gmail.com (Sid Kapoor) Date: Tue, 18 Dec 2007 10:25:58 +0530 Subject: Xephyr crashing with -grayscale option on amd geode In-Reply-To: <20071217160001.GE2571@cosmic.amd.com> References: <20071217160001.GE2571@cosmic.amd.com> Message-ID: Hi Jordan, Here I am attaching the log file of Xorg. Thanks, Siddharth On Dec 17, 2007 9:30 PM, Jordan Crouse wrote: > On 17/12/07 19:52 +0530, Sid Kapoor wrote: > > hi, > > > > I am having a customised linux distribution installed on a thin client > with > > the following configuration. > > > > AMD LX800 > > 128MB RAM > > Xorg version 7.2 > > > > The display driver that I am using is from xorg git > > > http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-amd.git;a=summary > > > > > > On running the Xephyr binary in this thin client with -grayscale option, > it > > opens the login page and then crashes without giving any warnings or > error. > > Ex: Xephyr -once -query 107.108.92.137 -fp > /usr/share/X11/fonts/misc > > -grayscale > > > > My xorg.conf file is also attached . > > Can you send a X log file from the crash too? > > Jordan > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. > > > -- Siddharth Kapoor Sr. Software Engg., Monitor Group Samsung India Software Center(SISC), Noida Mobile - 9999169466 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 29884 bytes Desc: not available URL: From pratish.ganguly at gmail.com Mon Dec 17 20:59:10 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Tue, 18 Dec 2007 10:29:10 +0530 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: References: Message-ID: Dear all This is the latest Xorg log file that is present on the system as of now, when the Xephyr command ( used to connect to a remote X-server at 8 bit depth ) fails to connect. Kindly ignore the last log file posted. On 12/18/07, pratish ganguly wrote: > Dear all > > This is the Xorg log file that is created on my system. > > > On 12/17/07, pratish ganguly wrote: > > > > Dear all > > > > I am using Xorg version 7.2 on a AMD Geode. When I am trying to connect > > to a X server using Xephyr at 8 bit depth, the connection is terminated > > abruptly, while the same connection at any other depth is connecting without > > any problem. > > Am I missing something here ? > > Please provide me some pointer to the solution of the above problem. > > > > With best regards > > Pratish Ganguly > > > > > > With best regards > Pratish Ganguly > With best regards Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 29297 bytes Desc: not available URL: From nian.wu at intel.com Mon Dec 17 21:14:36 2007 From: nian.wu at intel.com (Wu, Nian) Date: Tue, 18 Dec 2007 13:14:36 +0800 Subject: 945GM xrandr and DRI configuration In-Reply-To: <358f4d650712170142g4b09be44p101ec0b86ed65a65@mail.gmail.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> <358f4d650712170142g4b09be44p101ec0b86ed65a65@mail.gmail.com> Message-ID: <1104166E0B63A341805FDB977862AAD201032632@pdsmsx414.ccr.corp.intel.com> Albert Vilella wrote: > attached > > On Dec 15, 2007 10:23 AM, Albert Vilella wrote: >> Hi, >> >> I've got a sony sz1xp laptop with an intel 945GM. Is it possible to >> have a configuration that would allow me to configure the external >> screens / projectors with xrandr and yet to have DRI enabled when >> not plugged? >> >> Right now, my xrandr configuration works, but I don't have >> acceleration when using only the laptop's screen. >> >> xorg.conf attached. >> >> Thanks in advance, >> >> Cheers, >> >> Albert. You set the virtual screen size as 2560x1024 in xorg.conf: Virtual 2560 1024 Currently, i945 platform support DRI only when virtual screen size is below 2048x2048, this is a known issue. -Nian From dparsons at debian.org Mon Dec 17 22:08:14 2007 From: dparsons at debian.org (Drew Parsons) Date: Tue, 18 Dec 2007 17:08:14 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712171513.33017.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> <200712171513.33017.jbarnes@virtuousgeek.org> Message-ID: <1197958094.17915.29.camel@localhost.localdomain> On Mon, 2007-12-17 at 15:13 -0800, Jesse Barnes wrote: > On Sunday, December 16, 2007 4:12 Drew Parsons wrote: > > > > S3 resume simply doesn't restore the display. Resume works fine, > > that is I can get to the virtual consoles with [Ctrl-]Alt-Fn and > > login. > > > This may be an EXA bug (we moved to EXA by default in 2.2). Zhenyu > recently fixed an EXA suspend/resume bug in the git tree, can you give > it a try and see if you still see problems? > > Thanks, > Jesse Do you mean the rendering fix in intel, commit 13ec9c8141a9f794258869a04a6bab59dac5eefa ? Drew From dparsons at debian.org Mon Dec 17 22:04:58 2007 From: dparsons at debian.org (Drew Parsons) Date: Tue, 18 Dec 2007 17:04:58 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 In-Reply-To: <200712170828.26281.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> <200712170828.26281.jbarnes@virtuousgeek.org> Message-ID: <1197957898.17915.26.camel@localhost.localdomain> On Mon, 2007-12-17 at 08:28 -0800, Jesse Barnes wrote: > On Sunday, December 16, 2007 4:12 am Drew Parsons wrote: > > S3 resume simply doesn't restore the display. Resume works fine, that > > is I can get to the virtual consoles with [Ctrl-]Alt-Fn and login. > > > > But the X display initially comes up black, except for the mouse. The > > mouse cursor itself is properly displayed and moves around. > > > And you're using git tip? Are you using compiz? Sounds like we're definitely > not restoring some important state... > No, not using compiz, nor using git tip for everything. I've got the currently latest Debian versions, which are: linux 2.6.23-1 xserver 2:1.4.1~git20071212-1 (I think that's git in the 1.4 branch up to commit ca59d3f7bdb5f3724ff45ea57912c0b1098a73d6, which is still git tip for that branch but not for master) video-intel 2:2.2.0-1 (up to commit 4a2b0f340357c4ca58dc9586fad1337b83966362) libdrm2 2.3.0-4 mesa 7.0.2-2 (libgl1-mesa-dri, etc) As far as the dri extension goes, libdri.so is v1.0.0: (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 DRM interface version 1.3: (II) [drm] loaded kernel module for "i915" driver. (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. Lukas, do you have the bug number for your report? Drew From jm at orangeandbronze.com Mon Dec 17 22:50:18 2007 From: jm at orangeandbronze.com (JM Ibanez) Date: Tue, 18 Dec 2007 14:50:18 +0800 Subject: Best way of determining multiple monitor config? In-Reply-To: <200712172203.52352.hamish@travellingkiwi.com> (Hamie's message of "Mon\, 17 Dec 2007 22\:03\:50 +0000") References: <200712172203.52352.hamish@travellingkiwi.com> Message-ID: <87hcigts2d.fsf@adler.orangeandbronze.com> Hamie writes: > Hi. > > What's the current recommended method of an application determining the > configuration of (Possibly) multiple monitor setup? Should I still use the > libXinerama calls? Or are there 'better' calls to use nowadays? As I understand it, the recommended way is via XRandR 1.2; although the XRandR 1.2 extension does have Xinerama legacy support, XRandR 1.2 has the added ability to detect runtime changes to the configuration (and more accurate detection of monitor placement, etc.). -- JM Ibanez Software Architect Orange & Bronze Software Labs, Ltd. Co. jm at orangeandbronze.com http://software.orangeandbronze.com/ From florian.harmuth at googlemail.com Mon Dec 17 23:53:32 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Tue, 18 Dec 2007 08:53:32 +0100 Subject: Colormap settings? Message-ID: Hello all, i have a little problem regarding colormaps. After a call of XCreateImage / XShmCreateImage i get under my via cpu (savage gpu) for image->red_mask a value of 0xf800. Under my Geode cpu i get 0x0 for all color masks. My problem is that i should use xrfbviewer where the color choose is implemented with a dependecy on this color values (XFramebuffer.cc). I have attached my Xorg.log file where one line says it uses PseudoColors. Is that my problem? Any suggestions? Best regards, flo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 31385 bytes Desc: not available URL: From michel at tungstengraphics.com Mon Dec 17 23:57:51 2007 From: michel at tungstengraphics.com (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Tue, 18 Dec 2007 08:57:51 +0100 Subject: 3d hardware acceleration in 945GM chipset - is there any? In-Reply-To: References: Message-ID: <1197964672.8928.131.camel@thor.sulgenrain.local> On Mon, 2007-12-17 at 13:09 -0600, Dan Naughton wrote: > > (EE) [drm] Could not set DRM device bus ID. <=== BAD Sounds like something is holding on to the DRM device. What does sudo lsof /dev/dri/card0 say? -- Earthling Michel D?nzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer From dodji at seketeli.org Tue Dec 18 00:04:17 2007 From: dodji at seketeli.org (Dodji Seketeli) Date: Tue, 18 Dec 2007 09:04:17 +0100 Subject: Xephyr crashing with -grayscale option on amd geode In-Reply-To: References: Message-ID: <20071218080416.GA3812@coin> On Mon, Dec 17, 2007 at 07:52:12PM +0530, Sid Kapoor wrote: [...] > > > On running the Xephyr binary in this thin client with -grayscale option, it > opens the login page and then crashes without giving any warnings or error. > Ex: Xephyr -once -query 107.108.92.137 -fp /usr/share/X11/fonts/misc > -grayscale Could you please try and come up with a stack trace of the Xephyr crash ? That would be very helpful. Thanks. -- Dodji Seketeli http://www.seketeli.org/dodji From dodji at seketeli.org Tue Dec 18 00:18:26 2007 From: dodji at seketeli.org (Dodji Seketeli) Date: Tue, 18 Dec 2007 09:18:26 +0100 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: References: Message-ID: <20071218081826.GB3812@coin> On Mon, Dec 17, 2007 at 06:08:36PM +0530, pratish ganguly wrote: [...] > I am using Xorg version 7.2 on a AMD Geode. When I am trying to connect to a > X server using Xephyr at 8 bit depth, the connection is terminated abruptly, > while the same connection at any other depth is connecting without any > problem. I am not sure to understand what you mean. The Xorg logs you posted show that the X server is configured with 24 bits depth. So does that mean you are trying to make Xephyr connect to a 24 bits depth Xorg while configuring Xephyr itself to use a depth of 8 bits ? What is the command line you are launching Xephyr with exactly ? Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji From avilella at gmail.com Tue Dec 18 01:24:50 2007 From: avilella at gmail.com (Albert Vilella) Date: Tue, 18 Dec 2007 09:24:50 +0000 Subject: 945GM xrandr and DRI configuration In-Reply-To: <1104166E0B63A341805FDB977862AAD201032632@pdsmsx414.ccr.corp.intel.com> References: <358f4d650712150223j12a47c14u1e69fecd82fcbc0c@mail.gmail.com> <358f4d650712170142g4b09be44p101ec0b86ed65a65@mail.gmail.com> <1104166E0B63A341805FDB977862AAD201032632@pdsmsx414.ccr.corp.intel.com> Message-ID: <358f4d650712180124p72a9a3eapc8a43efc8960bce4@mail.gmail.com> So basically, if I start the X with this configuration, I won't be able to have DRI working even if my second screen is not plugged, is that right? Am I right then in thinking that I need to restart the X with a different xorg.conf that has no virtual screen or one below 2048x2048? Cheers, Albert. On Dec 18, 2007 5:14 AM, Wu, Nian wrote: > > Albert Vilella wrote: > > attached > > > > On Dec 15, 2007 10:23 AM, Albert Vilella wrote: > >> Hi, > >> > >> I've got a sony sz1xp laptop with an intel 945GM. Is it possible to > >> have a configuration that would allow me to configure the external > >> screens / projectors with xrandr and yet to have DRI enabled when > >> not plugged? > >> > >> Right now, my xrandr configuration works, but I don't have > >> acceleration when using only the laptop's screen. > >> > >> xorg.conf attached. > >> > >> Thanks in advance, > >> > >> Cheers, > >> > >> Albert. > > You set the virtual screen size as 2560x1024 in xorg.conf: > Virtual 2560 1024 > > Currently, i945 platform support DRI only when virtual screen size is > below 2048x2048, this is a known issue. > > -Nian > From pratish.ganguly at gmail.com Tue Dec 18 01:30:34 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Tue, 18 Dec 2007 15:00:34 +0530 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: <20071218081826.GB3812@coin> References: <20071218081826.GB3812@coin> Message-ID: Dear Dodji The command that I am using is Xephyr :1 -ac -once -screen 800x600x8 -query 107.108.92.131 -fp /usr/share/X11/fonts/misc/ Hope this helps. On 12/18/07, Dodji Seketeli wrote: > > On Mon, Dec 17, 2007 at 06:08:36PM +0530, pratish ganguly wrote: > > [...] > > > I am using Xorg version 7.2 on a AMD Geode. When I am trying to connect > to a > > X server using Xephyr at 8 bit depth, the connection is terminated > abruptly, > > while the same connection at any other depth is connecting without any > > problem. > > I am not sure to understand what you mean. The Xorg logs you posted show > that the X server is configured with 24 bits depth. So does that mean you > are trying to make Xephyr connect to a 24 bits depth Xorg while > configuring > Xephyr itself to use a depth of 8 bits ? What is the command line you are > launching Xephyr with exactly ? > > Cheers, > > -- > Dodji Seketeli > http://www.seketeli.org/dodji > > With best regards Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratish.ganguly at gmail.com Tue Dec 18 01:36:10 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Tue, 18 Dec 2007 15:06:10 +0530 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: References: <20071218081826.GB3812@coin> Message-ID: Dear all The X server here is configured with 24 bits depth. I am indeed trying to make a Xephyr connect to a 24 bits depth Xorg while configuring Xephyr itself to use a depth of 8 bits. For this I am using the following command only. Xephyr :1 -ac -once -screen 800x600x8 -query 107.108.92.131 -fp /usr/share/X11/fonts/misc/ On 12/18/07, pratish ganguly wrote: > Dear Dodji > > The command that I am using is > > Xephyr :1 -ac -once -screen 800x600x8 -query 107.108.92.131 -fp > /usr/share/X11/fonts/misc/ > Hope this helps. > > On 12/18/07, Dodji Seketeli wrote: > > > > On Mon, Dec 17, 2007 at 06:08:36PM +0530, pratish ganguly wrote: > > > > [...] > > > > > I am using Xorg version 7.2 on a AMD Geode. When I am trying to > > connect to a > > > X server using Xephyr at 8 bit depth, the connection is terminated > > abruptly, > > > while the same connection at any other depth is connecting without any > > > problem. > > > > I am not sure to understand what you mean. The Xorg logs you posted show > > that the X server is configured with 24 bits depth. So does that mean > > you > > are trying to make Xephyr connect to a 24 bits depth Xorg while > > configuring > > Xephyr itself to use a depth of 8 bits ? What is the command line you > > are > > launching Xephyr with exactly ? > > > > Cheers, > > > > -- > > Dodji Seketeli > > http://www.seketeli.org/dodji > > > > > > > With best regards > Pratish Ganguly > With best regards Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.harmuth at googlemail.com Tue Dec 18 01:54:04 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Tue, 18 Dec 2007 10:54:04 +0100 Subject: Colormap settings? Message-ID: > > Date: Tue, 18 Dec 2007 08:53:32 +0100 > From: "Florian Harmuth" > Subject: Colormap settings? > To: xorg at lists.freedesktop.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hello all, > i have a little problem regarding colormaps. After a call of XCreateImage > / > XShmCreateImage i get under my via cpu (savage gpu) for image->red_mask a > value of 0xf800. Under my Geode cpu i get 0x0 for all color masks. My > problem is that i should use xrfbviewer where the color choose is > implemented with a dependecy on this color values (XFramebuffer.cc). > I have attached my Xorg.log file where one line says it uses PseudoColors. > Is that my problem? Any suggestions? > > Best regards, > flo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.freedesktop.org/archives/xorg/attachments/20071218/3fd6632a/attachment.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Xorg.0.log > Type: text/x-log > Size: 31385 bytes > Desc: not available > Url : > http://lists.freedesktop.org/archives/xorg/attachments/20071218/3fd6632a/attachment.bin > > ------------------------------ > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg Hello all, its solved. I have set the default depth in my xorg.conf file to 24 -> now the driver uses TrueColor instead of PseudoColors and xrfbviewer works fine :-). best regards, flo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dodji at seketeli.org Tue Dec 18 02:49:21 2007 From: dodji at seketeli.org (Dodji Seketeli) Date: Tue, 18 Dec 2007 11:49:21 +0100 Subject: Xephyr crashing on 8 bit connection attempt In-Reply-To: References: <20071218081826.GB3812@coin> Message-ID: <20071218104921.GA4578@coin> On Tue, Dec 18, 2007 at 03:00:34PM +0530, pratish ganguly wrote: > Dear Dodji > > The command that I am using is > > Xephyr :1 -ac -once -screen 800x600x8 -query 107.108.92.131 -fp > /usr/share/X11/fonts/misc/ I tried something similar (without the -query part) to launch Xephyr on the Xorg server running on my local machine, and it runs fine with Xephyr from git master tip. What happens when you just try: Xephyr :1 -ac -once -screen 800x600x8 -fb /usr/share/X11/fonts/misc/ Cheers. -- Dodji Seketeli http://www.seketeli.org/dodji From xhejtman at ics.muni.cz Tue Dec 18 03:04:19 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Tue, 18 Dec 2007 12:04:19 +0100 Subject: Major stability issues with xf86-video-intel 2.2.0 In-Reply-To: <1197957898.17915.26.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712131701.10250.jbarnes@virtuousgeek.org> <1197807155.6102.7.camel@localhost.localdomain> <200712170828.26281.jbarnes@virtuousgeek.org> <1197957898.17915.26.camel@localhost.localdomain> Message-ID: <20071218110419.GB4249@ics.muni.cz> On Tue, Dec 18, 2007 at 05:04:58PM +1100, Drew Parsons wrote: > Lukas, do you have the bug number for your report? https://bugs.freedesktop.org/show_bug.cgi?id=13685 But it seems that you are using DRI from vanila kernel, in such a case, it is probably not my bug. -- Luk?? Hejtm?nek From ml at hboeck.de Tue Dec 18 05:41:23 2007 From: ml at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Tue, 18 Dec 2007 14:41:23 +0100 Subject: synaptics development? Message-ID: <200712181441.28708.ml@hboeck.de> Is there somewhere up-to-date-code for the synaptics driver? Last thing I heared was some relicensing efforts. Latest synaptics-git doesn't compile against xserver-head (wrong path for pixman.h include and still deps on libc wrapper). -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de -------------- 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 xhejtman at ics.muni.cz Tue Dec 18 05:48:10 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Tue, 18 Dec 2007 14:48:10 +0100 Subject: synaptics development? In-Reply-To: <200712181441.28708.ml@hboeck.de> References: <200712181441.28708.ml@hboeck.de> Message-ID: <20071218134810.GD4249@ics.muni.cz> On Tue, Dec 18, 2007 at 02:41:23PM +0100, Hanno B?ck wrote: > Is there somewhere up-to-date-code for the synaptics driver? Last thing I > heared was some relicensing efforts. > > Latest synaptics-git doesn't compile against xserver-head (wrong path for > pixman.h include and still deps on libc wrapper). this is trivial fix. but more serious is that it does not work with xserver-head (the server complains that xf86OpenSerial has been called without device). using this, you can get it compiled if you add -I/usr/include/pixman-1 into the Makefile. diff --git a/synaptics.c b/synaptics.c index 802132c..63e8971 100644 --- a/synaptics.c +++ b/synaptics.c @@ -70,7 +70,7 @@ #include #include #define NEED_XF86_TYPES -#include +#include #include #include #include "mipointer.h" @@ -491,16 +491,12 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flag priv->fifofd = -1; if (repeater) { /* create repeater fifo */ - if ((xf86mknod(repeater, 666, XF86_S_IFIFO) != 0) && - (xf86errno != xf86_EEXIST)) { - xf86Msg(X_ERROR, "%s can't create repeater fifo\n", local->name); - } else { + xf86mknod(repeater, 666, XF86_S_IFIFO); /* open the repeater fifo */ optList = xf86NewOption("Device", repeater); if ((priv->fifofd = xf86OpenSerial(optList)) == -1) { xf86Msg(X_ERROR, "%s repeater device open failed\n", local->name } - } xf86free(repeater); } -- Luk?? Hejtm?nek From glynn at gclements.plus.com Tue Dec 18 09:39:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue, 18 Dec 2007 17:39:58 +0000 Subject: Colormap settings? In-Reply-To: References: Message-ID: <18280.1518.186089.405578@cerise.gclements.plus.com> Florian Harmuth wrote: > i have a little problem regarding colormaps. After a call of XCreateImage / > XShmCreateImage i get under my via cpu (savage gpu) for image->red_mask a > value of 0xf800. Under my Geode cpu i get 0x0 for all color masks. My > problem is that i should use xrfbviewer where the color choose is > implemented with a dependecy on this color values (XFramebuffer.cc). > I have attached my Xorg.log file where one line says it uses PseudoColors. > Is that my problem? Yes. The colour masks are only meaningful for TrueColor and DirectColor visuals. > Any suggestions? Well, you can tell the X server to use a TrueColor visual with "-cc 4", but you'll also need to increase the display depth above 8bpp (with e.g. "-depth 16") to get decent quality. The only other solution is to re-write the code to support other visual types. Even then, there are so many applications which take a true-colour display for granted that this particular application is likely to be the least of your problems. It isn't just code which is the problem, but also graphics (icons, splash screens etc) which can consume the entire colourmap. -- Glynn Clements From Mathieu.Berard at crans.org Tue Dec 18 08:35:51 2007 From: Mathieu.Berard at crans.org (=?ISO-8859-15?Q?Mathieu_B=E9rard?=) Date: Tue, 18 Dec 2007 17:35:51 +0100 Subject: synaptics development? In-Reply-To: <200712181441.28708.ml@hboeck.de> References: <200712181441.28708.ml@hboeck.de> Message-ID: <4767F6E7.5000703@crans.org> Hanno B?ck a ?crit : > > Latest synaptics-git doesn't compile against xserver-head ( Here is a quick fix that unlibcwrap synaptics: -------------- next part -------------- A non-text attachment was scrubbed... Name: synaptics.patch Type: text/x-patch Size: 7874 bytes Desc: not available URL: From pbeerda at gmail.com Tue Dec 18 08:53:27 2007 From: pbeerda at gmail.com (Pier Beerda) Date: Tue, 18 Dec 2007 17:53:27 +0100 Subject: Problems Dual Screen; Ati driver; Ati Radeon IGP 320M (aka U1) Message-ID: <4767fb0d.05ed300a.78a9.ffffdb4b@mx.google.com> Hello Xorg mailing list, Recently I have started working with Kubuntu, but I am not able to set up dual screen properly. I use Xrandr for configuring my dual screen, with the GUI UrandR. I have had contact with the developer of the GUI UrandR, Alberto Milone, and I have sent him some output of using Xrandr and UrandR. He told me it probably is a bug in the ATI driver and I should file a bug report for the ATI driver, but first I should contact the Xorg mailing list and the developer of the ATI driver would help me. So here I am, looking for help. On my many visits to different websites looking for information about my problem, I found more people with the same problem, using the same video card. Hopefully you will be able to help me solve this problem. Thanks in Advance Pier -------------- next part -------------- An HTML attachment was scrubbed... URL: From egore at gmx.de Tue Dec 18 08:50:17 2007 From: egore at gmx.de (Christoph Brill) Date: Tue, 18 Dec 2007 17:50:17 +0100 Subject: synaptics development? In-Reply-To: <200712181441.28708.ml@hboeck.de> References: <200712181441.28708.ml@hboeck.de> Message-ID: <1197996617.6556.1.camel@egore912.egore.lan> Am Dienstag, den 18.12.2007, 14:41 +0100 schrieb Hanno B?ck: > Is there somewhere up-to-date-code for the synaptics driver? Last thing I > heared was some relicensing efforts. > > Latest synaptics-git doesn't compile against xserver-head (wrong path for > pixman.h include and still deps on libc wrapper). >From what I can tell the synaptics driver is no longer maintained. After I got all the agreements to the license change I could not get in contact with the maintainer. I was thinking about putting a fork of the synaptics driver into the freedesktop git so that it would be used by someone but I never took the time. From creder at digitalcpt.com Tue Dec 18 08:58:38 2007 From: creder at digitalcpt.com (christopher reder) Date: Tue, 18 Dec 2007 10:58:38 -0600 Subject: xserver-kdrive, mouse, motion issues Message-ID: <1197997118.14968.27.camel@linuxserver.digital> All - I have an embedded system running a AT91RM9200 with Kdrive 1.3.0 . With it, we have a 16 bit framebuffer setup through linux running 2.6.21. When I use a mouse pointer and drag it along the screen, it will change the background color such that I can see the 'box' that it redraws for the mouse pointer and at the edges, it changes the value of the color behind it. I also have a program that has some motion with it where a golfer takes a swing, The same phenomenon happens. I am trying to figure out if there is a way to force kdrive to access a routine in the framebuffer code for reads and writes so I can figure out what is messing up in the interaction with the framebuffer and the ARM9. Are there functions in the X library that do the mouse 'read modify write' and can I have access to them via the framebuffer code to see what may be going wrong (for example, trying to access as a 24 bit vs a 16 bit, bad mask, or anything else?) Does anyone have a suggestion or a way to do this so I can debug it better/further? Thanks Christopher From alexdeucher at gmail.com Tue Dec 18 09:03:46 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Tue, 18 Dec 2007 12:03:46 -0500 Subject: Problems Dual Screen; Ati driver; Ati Radeon IGP 320M (aka U1) In-Reply-To: <4767fb0d.05ed300a.78a9.ffffdb4b@mx.google.com> References: <4767fb0d.05ed300a.78a9.ffffdb4b@mx.google.com> Message-ID: On Dec 18, 2007 11:53 AM, Pier Beerda wrote: > > > > > > Hello Xorg mailing list, > > > > Recently I have started working with Kubuntu, but I am not able to set up > dual screen properly. I use Xrandr for configuring my dual screen, with the > GUI UrandR. I have had contact with the developer of the GUI UrandR, Alberto > Milone, and I have sent him some output of using Xrandr and UrandR. He told > me it probably is a bug in the ATI driver and I should file a bug report for > the ATI driver, but first I should contact the Xorg mailing list and the > developer of the ATI driver would help me. > > > > So here I am, looking for help. On my many visits to different websites > looking for information about my problem, I found more people with the same > problem, using the same video card. Hopefully you will be able to help me > solve this problem. well, what problem are you having exactly? To make things easier, you might want to file a bug (https://bugs.freedesktop.org) and attach your xorg log, config and the output of xrandr. Please also detail on the bug what you are trying to accomplish and what problems you are having. Alex From jbarnes at virtuousgeek.org Tue Dec 18 09:13:32 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 18 Dec 2007 09:13:32 -0800 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1197958094.17915.29.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> Message-ID: <200712180913.32212.jbarnes@virtuousgeek.org> On Monday, December 17, 2007 10:08 pm Drew Parsons wrote: > On Mon, 2007-12-17 at 15:13 -0800, Jesse Barnes wrote: > > On Sunday, December 16, 2007 4:12 Drew Parsons wrote: > > > S3 resume simply doesn't restore the display. Resume works fine, > > > that is I can get to the virtual consoles with [Ctrl-]Alt-Fn and > > > login. > > > > This may be an EXA bug (we moved to EXA by default in 2.2). Zhenyu > > recently fixed an EXA suspend/resume bug in the git tree, can you give > > it a try and see if you still see problems? > > > > Thanks, > > Jesse > > Do you mean the rendering fix in intel, commit > 13ec9c8141a9f794258869a04a6bab59dac5eefa ? Yeah, that's the one. Jesse From florian.harmuth at googlemail.com Tue Dec 18 10:23:09 2007 From: florian.harmuth at googlemail.com (Florian Harmuth) Date: Tue, 18 Dec 2007 19:23:09 +0100 Subject: Colormap settings? In-Reply-To: <18280.1518.186089.405578@cerise.gclements.plus.com> References: <18280.1518.186089.405578@cerise.gclements.plus.com> Message-ID: thx for your explanation. flo 2007/12/18, Glynn Clements : > > > Florian Harmuth wrote: > > > i have a little problem regarding colormaps. After a call of > XCreateImage / > > XShmCreateImage i get under my via cpu (savage gpu) for image->red_mask > a > > value of 0xf800. Under my Geode cpu i get 0x0 for all color masks. My > > problem is that i should use xrfbviewer where the color choose is > > implemented with a dependecy on this color values (XFramebuffer.cc). > > I have attached my Xorg.log file where one line says it uses > PseudoColors. > > Is that my problem? > > Yes. The colour masks are only meaningful for TrueColor and DirectColor > visuals. > > > Any suggestions? > > Well, you can tell the X server to use a TrueColor visual with "-cc 4", > but you'll also need to increase the display depth above 8bpp (with > e.g. "-depth 16") to get decent quality. > > The only other solution is to re-write the code to support other visual > types. > > Even then, there are so many applications which take a true-colour > display for granted that this particular application is likely to be > the least of your problems. It isn't just code which is the problem, > but also graphics (icons, splash screens etc) which can consume the > entire colourmap. > > -- > Glynn Clements > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.harris at hummingbird.com Tue Dec 18 10:36:52 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 18 Dec 2007 13:36:52 -0500 Subject: swapl (&stuff->window, n); swapl (&stuff->screen, n); Message-ID: <200712181336.52944.peter.harris@hummingbird.com> From a4600733ef46585df5481923b8eedffe922c23dc Mon Sep 17 00:00:00 2001 From: Peter Harris Date: Tue, 18 Dec 2007 13:14:07 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping --- My previous patch missed replies, and also missed the RandR panoramiX emulation layer. This patch fixes those omissions. I noticed while creating this patch that the reference server does not set rep.window anywhere. Should I send another patch to fix that omission (or amend this patch)? Xext/panoramiX.c | 10 ++++++---- randr/rrxinerama.c | 14 ++++++++++---- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c index 311a8e7..650e34e 100644 --- a/Xext/panoramiX.c +++ b/Xext/panoramiX.c @@ -920,7 +920,7 @@ ProcPanoramiXGetState(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetStateReply), (char *) &rep); return client->noClientException; @@ -947,7 +947,7 @@ ProcPanoramiXGetScreenCount(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.ScreenCount, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenCountReply), (char *) &rep); return client->noClientException; @@ -975,8 +975,10 @@ ProcPanoramiXGetScreenSize(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.width, n); - swaps (&rep.height, n); + swapl (&rep.width, n); + swapl (&rep.height, n); + swapl (&rep.window, n); + swapl (&rep.screen, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenSizeReply), (char *) &rep); return client->noClientException; diff --git a/randr/rrxinerama.c b/randr/rrxinerama.c index 896f61f..a9bc212 100644 --- a/randr/rrxinerama.c +++ b/randr/rrxinerama.c @@ -141,7 +141,7 @@ ProcRRXineramaGetState(ClientPtr client) if(client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetStateReply), (char *)&rep); return client->noClientException; @@ -195,7 +195,7 @@ ProcRRXineramaGetScreenCount(ClientPtr client) if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.ScreenCount, n); + swapl(&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenCountReply), (char *)&rep); return client->noClientException; @@ -226,8 +226,10 @@ ProcRRXineramaGetScreenSize(ClientPtr client) if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.width, n); - swaps(&rep.height, n); + swapl(&rep.width, n); + swapl(&rep.height, n); + swapl(&rep.window, n); + swapl(&rep.screen, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenSizeReply), (char *)&rep); return client->noClientException; @@ -351,6 +353,7 @@ SProcRRXineramaGetState(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetStateReq); + swapl (&stuff->window, n); return ProcRRXineramaGetState(client); } @@ -361,6 +364,7 @@ SProcRRXineramaGetScreenCount(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenCountReq); + swapl (&stuff->window, n); return ProcRRXineramaGetScreenCount(client); } @@ -371,6 +375,8 @@ SProcRRXineramaGetScreenSize(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenSizeReq); + swapl (&stuff->window, n); + swapl (&stuff->screen, n); return ProcRRXineramaGetScreenSize(client); } -- 1.5.3.7 -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From ast at arlut.utexas.edu Tue Dec 18 09:33:14 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Tue, 18 Dec 2007 11:33:14 -0600 Subject: Raise/Map and Focus a window: BadMatch error Message-ID: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> Hello everyone, I'm struggling with xlib here since I've been given a project that requires a lot of low level window management and I've never really done any coding with xlib before now. Currently I have an issue with XSetInputFocus(). What I'm trying to do is write a function that will: 1. Map a window (if it's unmapped) 2. Raise it 3. Focus that window Here's what I've got thus far: void map_raise_focus(Display *display, Window window) { XEvent e; XSelectInput (display, windw, ExposureMask); XMapRaised (display, window); while (e.type != Expose) { XNextEvent (display, &e); } XSelectInputFocus (display, window, RevertToParent, CurrentTime); } Sometimes (not always) I get a BadMatch error (Details: serial 2738 error_code 8 request_code 42 minor_code 0) which I'm sure is being caused by my XSelectInputFocus() call. I have a feeling that I'm doing something very wrong here but looking at the docs I can't seem to figure out how one would go about writing a function like map_raise_focus(). Can anyone shed some light on this problem for me please? -- Andrew Troschinetz Applied Research Laboratories From peter.harris at hummingbird.com Tue Dec 18 10:51:01 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 18 Dec 2007 13:51:01 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping Message-ID: <200712181351.01176.peter.harris@hummingbird.com> From a4600733ef46585df5481923b8eedffe922c23dc Mon Sep 17 00:00:00 2001 From: Peter Harris Date: Tue, 18 Dec 2007 13:14:07 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping --- Resending, this time with the correct subject line. My previous patch missed replies, and also missed the RandR panoramiX emulation layer. This patch fixes those omissions. I noticed while creating this patch that the reference server does not set rep.window anywhere. Should I send another patch to fix that omission (or amend this patch)? Xext/panoramiX.c | 10 ++++++---- randr/rrxinerama.c | 14 ++++++++++---- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c index 311a8e7..650e34e 100644 --- a/Xext/panoramiX.c +++ b/Xext/panoramiX.c @@ -920,7 +920,7 @@ ProcPanoramiXGetState(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetStateReply), (char *) &rep); return client->noClientException; @@ -947,7 +947,7 @@ ProcPanoramiXGetScreenCount(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.ScreenCount, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenCountReply), (char *) &rep); return client->noClientException; @@ -975,8 +975,10 @@ ProcPanoramiXGetScreenSize(ClientPtr client) if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.width, n); - swaps (&rep.height, n); + swapl (&rep.width, n); + swapl (&rep.height, n); + swapl (&rep.window, n); + swapl (&rep.screen, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenSizeReply), (char *) &rep); return client->noClientException; diff --git a/randr/rrxinerama.c b/randr/rrxinerama.c index 896f61f..a9bc212 100644 --- a/randr/rrxinerama.c +++ b/randr/rrxinerama.c @@ -141,7 +141,7 @@ ProcRRXineramaGetState(ClientPtr client) if(client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetStateReply), (char *)&rep); return client->noClientException; @@ -195,7 +195,7 @@ ProcRRXineramaGetScreenCount(ClientPtr client) if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.ScreenCount, n); + swapl(&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenCountReply), (char *)&rep); return client->noClientException; @@ -226,8 +226,10 @@ ProcRRXineramaGetScreenSize(ClientPtr client) if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.width, n); - swaps(&rep.height, n); + swapl(&rep.width, n); + swapl(&rep.height, n); + swapl(&rep.window, n); + swapl(&rep.screen, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenSizeReply), (char *)&rep); return client->noClientException; @@ -351,6 +353,7 @@ SProcRRXineramaGetState(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetStateReq); + swapl (&stuff->window, n); return ProcRRXineramaGetState(client); } @@ -361,6 +364,7 @@ SProcRRXineramaGetScreenCount(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenCountReq); + swapl (&stuff->window, n); return ProcRRXineramaGetScreenCount(client); } @@ -371,6 +375,8 @@ SProcRRXineramaGetScreenSize(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenSizeReq); + swapl (&stuff->window, n); + swapl (&stuff->screen, n); return ProcRRXineramaGetScreenSize(client); } -- 1.5.3.7 -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From sergio at sergiomb.no-ip.org Tue Dec 18 11:09:06 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Tue, 18 Dec 2007 19:09:06 +0000 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <4760D4E1.3060900@gentoo.org> References: <475F87D6.1040008@gentoo.org> <1197457315.9877.4.camel@pcmik05.zmk.uni-kl.de> <475FC515.20701@gentoo.org> <200712120924.00676.jbarnes@virtuousgeek.org> <4760D4E1.3060900@gentoo.org> Message-ID: <1198004946.2858.4.camel@localhost.localdomain> On Thu, 2007-12-13 at 07:44 +0100, R?mi Cardona wrote: > Willi Mann pointed out bug #13108, and it looks very similar. > Unfortunately, it's not marked as fixed and there's no reference to a > patch either in xf86-video-intel nor xorg-server for me to try. You have a new possible fix on https://bugs.freedesktop.org/show_bug.cgi?id=13108 Reading some treads, I suggest try also : Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "XAA" To identify if a problem specify with EXA Thanks, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From peter.harris at hummingbird.com Tue Dec 18 11:19:15 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 18 Dec 2007 14:19:15 -0500 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> Message-ID: <47681D33.9010804@hummingbird.com> Andrew Troschinetz wrote: > Here's what I've got thus far: > > void map_raise_focus(Display *display, Window window) { > XEvent e; > XSelectInput (display, windw, ExposureMask); (Are you sure you want to overwrite the window's event mask? I don't see you restoring the previous event mask anywhere.) > XMapRaised (display, window); > while (e.type != Expose) { > XNextEvent (display, &e); > } > XSelectInputFocus (display, window, RevertToParent, CurrentTime); > } > > Sometimes (not always) I get a BadMatch error (Details: serial 2738 > error_code 8 request_code 42 minor_code 0) which I'm sure is being > caused by my XSelectInputFocus() call. I have a feeling that I'm doing > something very wrong here but looking at the docs I can't seem to > figure out how one would go about writing a function like > map_raise_focus(). > > Can anyone shed some light on this problem for me please? The problem is that you can't set focus to a window that isn't viewable. Either the window's parent isn't mapped, or you haven't waited long enough for the window manager to map your window. First, you should make sure that this function is only called on toplevel windows (or that all the window's parents are already mapped). XNextEvent isn't polite, as you are consuming events that the rest of the application may need. You probably want to use XWindowEvent or XPeekIfEvent instead of XNextEvent. That aside, checking for an Expose event (on any window) is not a reliable indicator that this window has been mapped. Even if there are no other windows that this application has created, you may receive an early expose event if BackingStores (or maybe Composite) is enabled. Instead, you should check for a MapNotify event on only the window you are interested in. Select StructureNotifyMask instead of ExposureNotifyMask to get this event. Note that you might be waiting for a long time if the window manager decides to start your window minimized, or (in the case of twm) if the user is away from the screen. It might be better to set a flag, and check the flag inside the main loop's MapNotify handler. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From tom at dbservice.com Tue Dec 18 11:43:17 2007 From: tom at dbservice.com (Tomas Carnecky) Date: Tue, 18 Dec 2007 20:43:17 +0100 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> Message-ID: <476822D5.2070607@dbservice.com> Andrew Troschinetz wrote: > I'm struggling with xlib here since I've been given a project that > requires a lot of low level window management and I've never really > done any coding with xlib before now. Currently I have an issue with > XSetInputFocus(). > > What I'm trying to do is write a function that will: > 1. Map a window (if it's unmapped) > 2. Raise it > 3. Focus that window > > Here's what I've got thus far: If that is the real code as you use it in your app, see the comment below. > > void map_raise_focus(Display *display, Window window) { > XEvent e; > XSelectInput (display, windw, ExposureMask); > XMapRaised (display, window); > while (e.type != Expose) { ^^^^^^ 'e' is uninitialized here! > XNextEvent (display, &e); > } > XSelectInputFocus (display, window, RevertToParent, CurrentTime); > } > > Sometimes (not always) I get a BadMatch error (Details: serial 2738 > error_code 8 request_code 42 minor_code 0) which I'm sure is being > caused by my XSelectInputFocus() call. I have a feeling that I'm doing > something very wrong here but looking at the docs I can't seem to > figure out how one would go about writing a function like > map_raise_focus(). > tom From ast at arlut.utexas.edu Tue Dec 18 12:14:14 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Tue, 18 Dec 2007 14:14:14 -0600 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <47681D1B.5090005@hummingbird.com> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <47681D1B.5090005@hummingbird.com> Message-ID: On Dec 18, 2007, at 1:18 PM, Peter Harris wrote: > (Are you sure you want to overwrite the window's event mask? I don't > see > you restoring the previous event mask anywhere.) Oh I see now, XSelectEvent() modifies the window's event mask. Thanks for pointing that out I totally missed it. I rewrote the function to first use XGetWindowAttributes() and then save/restore the your_event_mask field. > First, you should make sure that this function is only called on > toplevel windows (or that all the window's parents are already > mapped). This is actually handled outside of this function, I make sure not to call it without knowing that the given Window is a toplevel (with parents already mapped). > XNextEvent isn't polite, as you are consuming events that the rest of > the application may need. You probably want to use XWindowEvent or > XPeekIfEvent instead of XNextEvent. Ah, didn't know that either. I was going off the Xlib tutorial found at http://www.tronche.com/gui/x/ I got the function to work reliably using XWindowEvent() instead but I assume that eventually I want to move to XPeekIfEvent() so that I'm not arbitrarily pulling events off the queue. > That aside, checking for an Expose > event (on any window) is not a reliable indicator that this window has > been mapped. Even if there are no other windows that this application > has created, you may receive an early expose event if BackingStores > (or > maybe Composite) is enabled. Instead, you should check for a MapNotify > event on only the window you are interested in. Select > StructureNotifyMask instead of ExposureNotifyMask to get this event. Thanks again for that point, I was able to use (StructureNotifyMask | SubstructureNotifyMask) to pickup the MapNotify event instead of the Expose event. But first I had to check that the window wasn't already mapped or I'd enter an indefinite loop waiting for a map event. > Note that you might be waiting for a long time if the window manager > decides to start your window minimized, or (in the case of twm) if the > user is away from the screen. It might be better to set a flag, and > check the flag inside the main loop's MapNotify handler. Thankfully this application will only ever run in a strictly regulated environment so I can ignore these issues, but thanks for the note. At least I know now that I might have to rework the code later if the environment changes in the future (though I don't expect this to ever be a real problem in my situation). -- Andrew Troschinetz Applied Research Laboratories (512) 835-3410 From ast at arlut.utexas.edu Tue Dec 18 12:26:46 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Tue, 18 Dec 2007 14:26:46 -0600 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <476822D5.2070607@dbservice.com> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <476822D5.2070607@dbservice.com> Message-ID: On Dec 18, 2007, at 1:43 PM, Tomas Carnecky wrote: > 'e' is uninitialized here! Quite right. Sorry I was transcribing the code from a much more messy looking text as copy&paste wasn't an option. Seems I saw do { ... } while (...); and just happily typed out while (...) { ... } in my transcription. -- Andrew Troschinetz Applied Research Laboratories From ast at arlut.utexas.edu Tue Dec 18 13:48:32 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Tue, 18 Dec 2007 15:48:32 -0600 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <47681D1B.5090005@hummingbird.com> Message-ID: On Dec 18, 2007, at 2:14 PM, Andrew Troschinetz wrote: > I got the function to work reliably using XWindowEvent() instead but I > assume that eventually I want to move to XPeekIfEvent() so that I'm > not arbitrarily pulling events off the queue. After trying to use XPeekIfEvent() I had the same problem as before I moved to XWindowEvent(). Bool map_notify_for_window(Display *display, XEvent *e, XPointer user_data) { Window window = *reinterpret_cast (user_data); if (e->type == MapNotify && e->xmap.window == window && e->xmap.display == display) { return True; } return False; } void map_raise_focus(Display *display, Window window) { XWindowAttributes atts; XGetWindowAttributes (display, window, &atts); if (atts.map_state == IsUnmapped) { unsigned long old_mask = atts.your_event_mask; XSelectInput (display, window, old_mask | StructureNotifyMask); XMapRaised (display, window); XEvent e; // predicate function won't return till I get exactly what I want, do-while not needed here: XPeekIfEvent (display, &e, map_notify_for_window, reinterpret_cast (window)); XSelectInput (display, window, old_mask); } XSetInputFocus (display, window, RevertToParent, CurrentTime); } With the above I sometimes get BadMatch errors just like before. Perhaps there's something wrong with my predicate function? If I go with the XWindowEvent() and a do-while loop instead of XPeekIfEvent() would it be ok for me to keep track of the events I remove and then put them all back on the queue once I leave the do- while loop? Or is that sort of reordering of the queue going to cause all kinds of problems? After testing it doesn't seem to, but I'm not sure that there aren't any hidden consequences... -- Andrew Troschinetz Applied Research Laboratories From peter.harris at hummingbird.com Tue Dec 18 14:16:36 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 18 Dec 2007 17:16:36 -0500 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <47681D1B.5090005@hummingbird.com> Message-ID: <476846C4.6070503@hummingbird.com> Andrew Troschinetz wrote: > After trying to use XPeekIfEvent() I had the same problem as before I > moved to XWindowEvent(). > > Bool map_notify_for_window(Display *display, XEvent *e, XPointer > user_data) { > Window window = *reinterpret_cast (user_data); I'm not all that familiar with C++, but it looks like you're dereferencing a user_data (which is a Window, not a pointer to a Window). > XPeekIfEvent (display, &e, map_notify_for_window, > reinterpret_cast (window)); Did you leave out a try/catch around this? I expect your map_notify_for_window to cause a core dump. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From beat.kneubuehl at rega-sense.ch Tue Dec 18 14:24:55 2007 From: beat.kneubuehl at rega-sense.ch (Beat Kneubuehl) Date: Tue, 18 Dec 2007 23:24:55 +0100 Subject: interlace modes support for intel driver In-Reply-To: References: <47659C9A.9020307@rega-sense.ch> Message-ID: <476848B7.80801@rega-sense.ch> > I guess G33 doesn't have 2D video overlay and always uses textured > overlay? > > Interlaced mode support is not a real problem here, I have a patch > which generally works (though may need some additional, probably > trivial work, and I tested only PAL 576i). > you're right: X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) Textured Video" number of ports: 16 port base: 73 > The problem is the lack of frame synchronization between the program > (X client) and the Xserver/hardware. > > Is it now possible to have frame synchronization, using textured Xv? > I mean, Xserver switching active video frames on vertical retrace > or something like that. > don't know about this issue, but maybe you could post your patch to the mailing list, and i could try him with 1080i mode anyway. thanks, beat From mailinglists at who-t.net Tue Dec 18 15:08:06 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 09:38:06 +1030 Subject: [RFC] dix: Re-introduce rescaling on motion events for extended event reporting In-Reply-To: <200712161853.46380.Magnus.Vigerlof@home.se> References: <200712161853.46380.Magnus.Vigerlof@home.se> Message-ID: <476852D6.8030201@who-t.net> Magnus Vigerl?f wrote: > Since the work to correct this is postponed for some time I propose > an interim solution where we get back the scaling so devices can > register any values on X&Y and not be tied to the changing values of > the screen size. > > The patch below is tested with a Wacom tablet and works well with my > Volito 2 both as a pointer on the desktop and as a pressure-sensitive, > high-resolution pen in Gimp. At the same time my synaptic touchpad and > USB mouse worked as before. > > This time I haven't introduced any interface changes. The values that > should be reported for the device are the same as in xserver 1.3, > including the max-values on X&Y. The drivers that has been adapted to > cope with the current situation will continue to work as the max-value > registered by the driver is used in the scaling. one thing: in the proposed patch, pDev->valuator->lastx/lasty are set before the call to miPointerSetPosition. lastx/lasty of the VCP however afterwards. miPSP may change x/y if there was a screen switch. so you may end up with different coordinates here. could this be a problem? I've looked at the code several times but I'm still unsure. aside from that, I'd say its fine. > The only worry I have with this patch is the check for if we should > scale or not. The devices I have in my system that shouldn't scale all > have '-1' as max and this is what's used to detect this situation. Is > that safe? this should be fine. I vaguely remember the server relying on -1 somewhere as well. although I don't know where that was anymore or whether it was just a feverish nightmare. > [1] https://bugs.freedesktop.org/show_bug.cgi?id=10324 > > --- > dix/getevents.c | 54 +++++++++++++++++++++++++++++++++++++++++------------- > 1 files changed, 41 insertions(+), 13 deletions(-) > > diff --git a/dix/getevents.c b/dix/getevents.c > index 6e840d4..d562e18 100644 > --- a/dix/getevents.c > +++ b/dix/getevents.c > @@ -528,6 +528,7 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, > DeviceIntPtr cp = inputInfo.pointer; > int x = 0, y = 0; > Bool coreOnly = (pDev == inputInfo.pointer); > + ScreenPtr scr = miPointerGetScreen(pDev); > > /* Sanity checks. */ > if (type != MotionNotify && type != ButtonPress && type != ButtonRelease) > @@ -593,15 +594,33 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, > valuators); > > if (pDev->coreEvents) { > - if (first_valuator == 0 && num_valuators >= 1) > - x = cp->valuator->lastx + valuators[0]; > + /* Get and convert the core pointer coordinate space into > + * device coordinates. Use the device coords if it translates > + * into the same position as the core to preserve relative sub- > + * pixel movements from the device. */ > + int max = pDev->valuator->axes[0].max_value; > + if(max > 0) { > + x = pDev->valuator->lastx; > + if((int)((float)(x)*scr->width/(max+1)) != cp->valuator->lastx) > + x = (int)((float)(cp->valuator->lastx)*(max+1)/scr->width); > + } > else > x = cp->valuator->lastx; > > - if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) > - y = cp->valuator->lasty + valuators[1 - first_valuator]; > + max = pDev->valuator->axes[1].max_value; > + if(max > 0) { > + y = pDev->valuator->lasty; > + if((int)((float)(y)*scr->height/(max+1)) != cp->valuator->lasty) > + y = (int)((float)(cp->valuator->lasty)*(max+1)/scr->height); > + } > else > y = cp->valuator->lasty; > + > + /* Add relative movement */ > + if (first_valuator == 0 && num_valuators >= 1) > + x += valuators[0]; > + if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) > + y += valuators[1 - first_valuator]; > } > else { > if (first_valuator == 0 && num_valuators >= 1) > @@ -620,11 +639,6 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, > clipAxis(pDev, 0, &x); > clipAxis(pDev, 1, &y); > > - /* This takes care of crossing screens for us, as well as clipping > - * to the current screen. Right now, we only have one history buffer, > - * so we don't set this for both the device and core.*/ > - miPointerSetPosition(pDev, &x, &y, ms); > - > /* Drop x and y back into the valuators list, if they were originally > * present. */ > if (first_valuator == 0 && num_valuators >= 1) > @@ -634,12 +648,26 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, > > updateMotionHistory(pDev, ms, first_valuator, num_valuators, valuators); > > + pDev->valuator->lastx = x; > + pDev->valuator->lasty = y; > + /* Convert the dev coord back to screen coord if we're > + * sending core events */ > + if (pDev->coreEvents) { > + if(pDev->valuator->axes[0].max_value > 0) > + x = (int)((float)(x)*scr->width/(pDev->valuator->axes[0].max_value+1)); > + if(pDev->valuator->axes[1].max_value > 0) > + y = (int)((float)(y)*scr->height/(pDev->valuator->axes[1].max_value+1)); > + } > + > + /* This takes care of crossing screens for us, as well as clipping > + * to the current screen. Right now, we only have one history buffer, > + * so we don't set this for both the device and core.*/ > + miPointerSetPosition(pDev, &x, &y, ms); > + > if (pDev->coreEvents) { > cp->valuator->lastx = x; > cp->valuator->lasty = y; > } > - pDev->valuator->lastx = x; > - pDev->valuator->lasty = y; > > /* for some reason inputInfo.pointer does not have coreEvents set */ > if (coreOnly || pDev->coreEvents) { > @@ -677,8 +705,8 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, > kbp->detail = pDev->button->map[buttons]; > } > > - kbp->root_x = x; > - kbp->root_y = y; > + kbp->root_x = pDev->valuator->lastx; > + kbp->root_y = pDev->valuator->lasty; > > events++; > if (num_valuators) { From ast at arlut.utexas.edu Tue Dec 18 15:31:38 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Tue, 18 Dec 2007 17:31:38 -0600 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <476846C4.6070503@hummingbird.com> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <47681D1B.5090005@hummingbird.com> <476846C4.6070503@hummingbird.com> Message-ID: On Dec 18, 2007, at 4:16 PM, Peter Harris wrote: > Andrew Troschinetz wrote: >> After trying to use XPeekIfEvent() I had the same problem as before I >> moved to XWindowEvent(). >> >> Bool map_notify_for_window(Display *display, XEvent *e, XPointer >> user_data) { >> Window window = *reinterpret_cast (user_data); > > I'm not all that familiar with C++, but it looks like you're > dereferencing a user_data (which is a Window, not a pointer to a > Window). > >> XPeekIfEvent (display, &e, map_notify_for_window, >> reinterpret_cast (window)); Good eye, I must apologize again for having to transcribe my actual code. My only machine here with internet access is a Mac and the program I'm writing/testing is on a classified RHEL4-AS machine so my only option is to transcribe the code as best I can. Sorry. In the actual code I've got XPeekIfEvent (display, &e, map_notify_for_window, reinterpret_cast (&window)); So we've got a Window* being cast to a char* (XPointer) to conform to the required predicate signature for XPeekIfEvent()'s 3rd parameter, then map_notify_for_window() is casting the char* back to a Window* and dereferencing it to get the Window value. I'm pretty sure that's not the problem. > Did you leave out a try/catch around this? I expect your > map_notify_for_window to cause a core dump. There's no exception code in our entire code base here. The problem, as I see it, is that the predicate function I've defined returns True for some case which I just don't understand. Basically I want map_notify_for_window() to return True only for exactly the same event for which this loop will exit upon: // This works as desired, but I have a bad feeling mucking with the event queue will cause me problems later. XEvent e; XMapRaised (display, window); do { XWindowEvent (display, window, StructureNotifyMask, &e); // save the event in a vector } while (e.type != MapNotify); // use the vector to push all collected events back on to the event queue In short: *** I simply want to know when a window I've called XMapRaised() on has been mapped so that I can safely call XSetInputFocus() on it. *** -- Andrew Troschinetz Applied Research Laboratories From peter.harris at hummingbird.com Tue Dec 18 16:10:13 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Tue, 18 Dec 2007 19:10:13 -0500 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <47681D1B.5090005@hummingbird.com> <476846C4.6070503@hummingbird.com> Message-ID: <47686165.6010103@hummingbird.com> Andrew Troschinetz wrote: > The problem, as I see it, is that the predicate function I've defined > returns True for some case which I just don't understand. Basically I > want map_notify_for_window() to return True only for exactly the same > event for which this loop will exit upon: Your code looks good. The only remaining thing I can think of is the return type: Bool. Xlib defines Bool as int. You appear to be using a C++ compiler. If you have redefined Bool to bool (a type that does not exist in C) the compiler may be returning the value differently. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From rjshaw at netspace.net.au Tue Dec 18 16:42:00 2007 From: rjshaw at netspace.net.au (Russell Shaw) Date: Wed, 19 Dec 2007 11:42:00 +1100 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> Message-ID: <476868D8.9090905@netspace.net.au> Andrew Troschinetz wrote: > Hello everyone, > > I'm struggling with xlib here since I've been given a project that > requires a lot of low level window management and I've never really > done any coding with xlib before now. Currently I have an issue with > XSetInputFocus(). > > What I'm trying to do is write a function that will: > 1. Map a window (if it's unmapped) > 2. Raise it > 3. Focus that window > > Here's what I've got thus far: > > void map_raise_focus(Display *display, Window window) { > XEvent e; > XSelectInput (display, windw, ExposureMask); > XMapRaised (display, window); > while (e.type != Expose) { > XNextEvent (display, &e); > } > XSelectInputFocus (display, window, RevertToParent, CurrentTime); > } > > Sometimes (not always) I get a BadMatch error (Details: serial 2738 > error_code 8 request_code 42 minor_code 0) which I'm sure is being > caused by my XSelectInputFocus() call. I have a feeling that I'm doing > something very wrong here but looking at the docs I can't seem to > figure out how one would go about writing a function like > map_raise_focus(). > > Can anyone shed some light on this problem for me please? Make X synchronous and BadMatch errors will be easier to find. XSynchronize http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSynchronize.html From pcpa at mandriva.com.br Tue Dec 18 18:39:51 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Wed, 19 Dec 2007 00:39:51 -0200 Subject: About some git repositories Message-ID: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> Hi, About repository xf86-video-ast, commit 486380cd85cdd2532300905ee588be48480ce1dc seens weird as it was done by root at localhost.localdomain, and it is a big commit, and it is also the commit that bumped the version: 486380cd (root 2007-08-24 21:13:39 +0800 25) 0.84.7, Is there some plan for an "official" version of it soon? Well, I also am building a list of commits that I believe should have a xf86-{video,input}-{name}-{version} tag. Or whatever other name is expected to be used, as that pattern is used by most modules with an "uptodate" tag, but there are some that use other patterns, usually ommiting xf86-{video,input} and using underscores instead of dots. Most of them are after the commit adding .gitignore/.cvsignore and/or adding the a macro to specifiy version, or the change to generate changelogs from git. I will try to post the proper commits once I have this finished, in case someone has interest. Also, is there some consensus, or does people even know :-) that there is alot of broken input modules that won't work with origin/server-1.4-branch currently ? Broken due to unresolved symbols like xf86IsCorePointer, xf86XInputSetSendCoreEvents, (and RRGetRotation in the fpit module), also the fact that the acecad module uses dlopen/dlclose on libsysfs.so for Linux may not be wise, it should just link agains't it, or not, and there is precedence, like several modules "inhering" libm functions from the server. Thanks, Paulo From mailinglists at who-t.net Tue Dec 18 19:06:13 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 13:36:13 +1030 Subject: About some git repositories In-Reply-To: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> References: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> Message-ID: <47688AA5.2090207@who-t.net> pcpa at mandriva.com.br wrote: > Also, is there some consensus, or does people even know :-) that there is > alot of broken input modules that won't work with origin/server-1.4-branch > currently ? IIRC input hotplug was merged into master in november 2006. these modules all broke back then and nobody stepped up to fix them. This is probably a signal that they are not well maintained. Even if the code is fixed to compile correctly, we could not ensure that it actually works. Cheers, Peter From yinglcs at gmail.com Tue Dec 18 19:23:37 2007 From: yinglcs at gmail.com (ying lcs) Date: Tue, 18 Dec 2007 21:23:37 -0600 Subject: How to get XTest to work with xvfb Message-ID: <568e62a40712181923j77084674p27fec09aba68f532@mail.gmail.com> Hi, I have a program which uses XTest to simulate a mouse click to my program. It works if my program is running in a visible display. But when I setup xvfb and set my program to display there, the mouse click simulation does not work. Can you please tell me how to get XTest to work with xvfb? Thank you. XTestFakeMotionEvent( xdisplay, gdk_x11_get_default_screen(), x, y, 0 ); XTestFakeButtonEvent( xdisplay, 1, TRUE, 0 ); XTestFakeButtonEvent( xdisplay, 1, FALSE, 0 ); From pcpa at mandriva.com.br Tue Dec 18 20:19:26 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Wed, 19 Dec 2007 02:19:26 -0200 Subject: More about x-packages Message-ID: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> Hi, I posted to @x-packagers and @xorg some tim ago about a "buildsystem" for x packages, and a way to possibly use git to simplify package management. Besides I still don't have it fully finished, did not receive any feedback other than local (at Mandriva) feedback *when* I finally started implmenting it, I will try to describe it again, but first, I will point some problems that I noticed, that may be of interest of packagers, but I still don't have a formal description of all problems, because I still did not finish the sytem. Problems that may be of interest of "x-packagers" (if your package already have patches for the problems, please disconsider): (Also, to add a point, I did not work with "X Packages" for quite some years, so forgive me if I am being stupid or something :-) With "default" build at X Server 1.3 time (i.e. most distros out there): There are several broken modules, due to things like ramdac symbols not available, what breaks several video drivers (fixed in 1.4). There are some modules that have undefined functions, that when inspecting the sources, I found out that they are actually macros :-o that were compiled as missing functions (fixed in 1.4). I think a lot of distros shipped sun/sparc video modules, just because they compile in x86, and/or made default installs for hardware that "should" work on x86, but is usually used on other platforms. libxf4bpp.so has a lot of missing symbols, so it is unlikely the vga driver for example, will work, libxf1bpp.so has basically the same missing symbols, but this is fixed in 1.4. With current 1.4 branch: A large amount of input drivers are broken, and I posted some more details on another email, this is basically due to symbols no longer available on the X Server. The i2c builtin module is really ugly with those macros in the format: #define I2C_WriteRead ((Bool (*)(I2CDevPtr, I2CByte *, int, I2CByte *, int))LoaderSymbol("xf86I2CWriteRead")) Someone can post more details if this is broken or not, but a huge amount of symbols with the same name are available in libcfb.so and libmfb.so, but probably it is ok, unless there is some case both can be loaded (and I think there is no such case). There are a few instances of C source code with things like: extern some function(some args); and calls to the function, that doesn't exist anymore. I am writing this email from memory, I remember now only about the savage driver, savage_vbe.c call to vbeModeInit, the others I patched locally when finding them). At least libxf8_32bpp.so is currently broken, due to unresolved symbols, but those are also "ugly" files with lots of symbols generated by macros, and reincluding source files with different macro definitions. Now, about the system I am working on: I am using a git mirror of freedesktop, where I use 3 main branches, and modules also have branches with the same name. mandriva Code that should be ok to add to mainstream mandriva+custom Work in progress patches, or things that are not considered mainstream quality, but fix some issue in the distro mandriva+gpl The distinction is due to the fact that GPL code currently isn't accepted in main Xorg, and branch created to allow easier integration of such patches/mods, and still keep the repository in a format that allows easy pulling for other people that want to make sure only a permissive license is used. Currently, I am experimenting with git-archive to generate a tarball, and git-format-patch to generate the patches. The benefit is that it can be automatized, and there is no need to store huge binary files, and only files under version control enter the tarball. The bad side is that it is something new, and you can find people that dislike it. I generate tarball/patches to submit to a ``standard rpm build system''. I also done a set of macros, so most configure.ac's and Makefile.am's of modules can be simplifield, instead of everyone having something like a cut&paste of the same code to check for --disable-dri, --enable-exa, and the like. Actually, there is a problem with --disable-dri, that XF86DRI is actually defined in xorg-server.h, so if the X Server was compiled with dri enabled, there isn't a standard way to "force" a module to compile without dri support, but fixing this detail is in the aesthetic/logic side. I hope to analize the output of the compilation of all modules, as I am compiling all of the them with lots of warnings enabled, that hopefully can catch other problems. Also, I have basically finished a build where almost everything (but mesa and libraries) is compiled with -fvisibility=hidden, and symbols used by different modules are properly "exported" using _X_EXPORT. I also wish to possibily post more information about it soon, but most of the data is collected by a perl script that analyzes the output of objdump and cross references the data so that, while it doesn't point out about symbols that should be exported (but then, there isn't really a well defined API for developing modules/drivers), it will detect missing symbols, symbol clashes, warn about symbols that are hidden but required by some module, etc. Thanks, Paulo From pcpa at mandriva.com.br Tue Dec 18 20:31:01 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Wed, 19 Dec 2007 02:31:01 -0200 Subject: About some git repositories In-Reply-To: <47688AA5.2090207@who-t.net> References: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> <47688AA5.2090207@who-t.net> Message-ID: <20071219023101.hrl1ku0w5wgk8kw0@webmail.conectiva.com.br> Quoting Peter Hutterer : > pcpa at mandriva.com.br wrote: >> Also, is there some consensus, or does people even know :-) that there is >> alot of broken input modules that won't work with origin/server-1.4-branch >> currently ? > > IIRC input hotplug was merged into master in november 2006. these > modules all broke back then and nobody stepped up to fix them. This > is probably a signal that they are not well maintained. Even if the > code is fixed to compile correctly, we could not ensure that it > actually works. Well, I cannot say if it works, but at least there are no undefined symbols in the 1.3 server. But yes, just making them compile may not be the proper fix, i.e. doing things like assuming xf86IsCorePointer always returns true, or that xf86XInputSetSendCoreEvents is a noop. I presume this may be the case, but I would like to know from someone with more knowledge if this is the case. But I suspect there are more serious issues with "motion events" handling and the like. > Cheers, > Peter Paulo From mailinglists at who-t.net Tue Dec 18 20:39:38 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 15:09:38 +1030 Subject: Adding xinput to apps Message-ID: <4768A08A.7070300@who-t.net> Unless anyone opposes I will add the xinput tool to the suite of apps tomorrow. I tried contacting Frederic Lepied, the original author with no success. I since created a git repository in my personal directory [0], autotooled the lot and applied a few patches. Most of the stuff I did with it was mpx related but I cherry-picked most of it back to the master branch. (some of the ordering got mixed up, but the current state of master is ok) Philip Langdale stepped up to maintain it. [1] Philip, are you still up for it? If not, I can do it. Cheers, Peter [0] git://people.freedesktop.org/~whot/xinput.git [1] http://lists.freedesktop.org/archives/xorg/2007-October/029744.html From pcpa at mandriva.com.br Tue Dec 18 21:06:12 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Wed, 19 Dec 2007 03:06:12 -0200 Subject: Adding xinput to apps In-Reply-To: <4768A08A.7070300@who-t.net> References: <4768A08A.7070300@who-t.net> Message-ID: <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> Quoting Peter Hutterer : > Unless anyone opposes I will add the xinput tool to the suite of apps > tomorrow. Can you post a git url for dummies? :-) Otherwise I can wait until tomorrow if it will go to xorg/apps. I have basically nil knowledge about the internals of xinput, but I have interest on knowing it is working, so I want at least to see what is being worked on :-) > I tried contacting Frederic Lepied, the original author with no success. > I since created a git repository in my personal directory [0], > autotooled the lot and applied a few patches. I left Conectiva before the merge with Mandrake, and came back a few month ago, I can at least try to check if someone knows if he is still on earth... > Most of the stuff I did with it was mpx related but I cherry-picked most > of it back to the master branch. (some of the ordering got mixed up, but > the current state of master is ok) > > Philip Langdale stepped up to maintain it. [1] Philip, are you still up > for it? If not, I can do it. > > Cheers, > Peter > > [0] git://people.freedesktop.org/~whot/xinput.git > [1] http://lists.freedesktop.org/archives/xorg/2007-October/029744.html Paulo From mailinglists at who-t.net Tue Dec 18 21:21:21 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 15:51:21 +1030 Subject: About some git repositories In-Reply-To: <20071219023101.hrl1ku0w5wgk8kw0@webmail.conectiva.com.br> References: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> <47688AA5.2090207@who-t.net> <20071219023101.hrl1ku0w5wgk8kw0@webmail.conectiva.com.br> Message-ID: <4768AA51.4070602@who-t.net> pcpa at mandriva.com.br wrote: > Well, I cannot say if it works, but at least there are no undefined > symbols in the 1.3 server. server 1.3 did not have the input hotplug rework. event generation between 1.3 and 1.4 is significantly different. But yes, just making them compile may not be > the proper fix, i.e. doing things like assuming xf86IsCorePointer always > returns true, or that xf86XInputSetSendCoreEvents is a noop. well, the thing is it's been broken for over a year and we don't even know if anybody is using it. This may mean we're dragging code along that is past its expiry date. Maintaining it for no other reason that that we've always maintained it is IMO pointless. we have modular releases, so we can very quickly update a driver and release it if somebody steps up and actually complains (and does the testing :) Cheers, Peter From mailinglists at who-t.net Tue Dec 18 21:24:39 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 15:54:39 +1030 Subject: Adding xinput to apps In-Reply-To: <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> References: <4768A08A.7070300@who-t.net> <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> Message-ID: <4768AB17.7090400@who-t.net> pcpa at mandriva.com.br wrote: > Quoting Peter Hutterer : > Can you post a git url for dummies? :-) Otherwise I can wait until > tomorrow if it will go to xorg/apps. git://people.freedesktop.org/~whot/xinput.git > I have basically nil knowledge about the internals of xinput, but > I have interest on knowing it is working, so I want at least to > see what is being worked on :-) it's a fairly straightforward codebase. xinput is nothing more than a commandline wrapper for parts of libXi. >> I tried contacting Frederic Lepied, the original author with no success. >> I since created a git repository in my personal directory [0], >> autotooled the lot and applied a few patches. > > I left Conectiva before the merge with Mandrake, and came back a few > month ago, I can at least try to check if someone knows if he is still > on earth... cool. thanks. From tapojoychatterjee at yahoo.co.in Tue Dec 18 21:45:08 2007 From: tapojoychatterjee at yahoo.co.in (Tapojoy chatterjee) Date: Wed, 19 Dec 2007 11:15:08 +0530 (IST) Subject: Xephyr crashes Message-ID: <108798.37253.qm@web7908.mail.in.yahoo.com> Hi when we use the command u specified it works ..only when we ask it connect it to XDM( provide an ip it crashes) u may try this to verify Xephyr :1 -ac -query localhost -once -screen 800x600x8 -fp /usr/share/X11/fonts/misc we are using Xorg -1.4 (7.3) and Xephyr is made from it....When we use a 7.2 based Xephyr it works on all systems..but it has that CAPSLOCK bug.. Strace log is attached to this mail Tapojoy Chatterjee Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 145539 bytes Desc: not available URL: From pcpa at mandriva.com.br Tue Dec 18 22:12:23 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Wed, 19 Dec 2007 04:12:23 -0200 Subject: Adding xinput to apps In-Reply-To: <4768AB17.7090400@who-t.net> References: <4768A08A.7070300@who-t.net> <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> <4768AB17.7090400@who-t.net> Message-ID: <20071219041223.pm8945c26cbo4w8s@webmail.conectiva.com.br> Quoting Peter Hutterer : >> Quoting Peter Hutterer : >> Can you post a git url for dummies? :-) Otherwise I can wait until >> tomorrow if it will go to xorg/apps. > > git://people.freedesktop.org/~whot/xinput.git Thanks, weird, in my first attempt to "clone" I got an error about non existant repository, maybe I messed up things here. >> I have basically nil knowledge about the internals of xinput, but >> I have interest on knowing it is working, so I want at least to >> see what is being worked on :-) > > it's a fairly straightforward codebase. xinput is nothing more than a > commandline wrapper for parts of libXi. Well, by changing BOOL to Bool and #if 0'ing list.c "if (daemon)..." I could compile it and make some tests, i.e. list devices and use the test option to map to the extended devices and actually map to my normal mouse. The daemon variable is also not initialized, so I think you are still working on it :-) As I said, I have pretty much nil knowledge about XInput, but from a quick view of the source, it may be a good idea to have it available, unless it is choosen to do something like you said, and remove the modules broken in branch 1.4, but again, after some "overview" on the code of some input modules, this doesn't look like a wise idea as it looks like code that used to work for several years, so maybe there is some magic that can be done to make 1.4 work as 1.3, or earlier regarding to extended input devices, i.e. some kind of compat mode. Paulo From mailinglists at who-t.net Tue Dec 18 22:25:12 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 16:55:12 +1030 Subject: Adding xinput to apps In-Reply-To: <20071219041223.pm8945c26cbo4w8s@webmail.conectiva.com.br> References: <4768A08A.7070300@who-t.net> <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> <4768AB17.7090400@who-t.net> <20071219041223.pm8945c26cbo4w8s@webmail.conectiva.com.br> Message-ID: <4768B948.10204@who-t.net> pcpa at mandriva.com.br wrote: > Well, by changing BOOL to Bool and #if 0'ing list.c "if (daemon)..." I > could compile it and make some tests, i.e. list devices and use the test > option to map to the extended devices and actually map to my normal mouse. > The daemon variable is also not initialized, so I think you are still > working on it :-) I had a cherry-pick gone rogue. Should be fixed now. Before I move it to apps tomorrow, I'll revert all the cherry picks and make sure that the history in the master branch isn't as messed up as it is now. > As I said, I have pretty much nil knowledge about XInput, but from > a quick view of the source, it may be a good idea to have it available, > unless it is choosen to do something like you said, and remove the > modules broken in branch 1.4, but again, after some "overview" on the > code of some input modules, this doesn't look like a wise idea as it looks > like code that used to work for several years, so maybe there is some > magic that can be done to make 1.4 work as 1.3, or earlier regarding to > extended input devices, i.e. some kind of compat mode. less commas and more periods please. I'm not sure if I understood this sentence ;) the xinput tool does not have anything to do with the input modules. It is basically just a runtime configuration tool. btw. "used to work" is not the same as "nobody complained" :) Cheers, Peter From dodji at seketeli.org Wed Dec 19 00:13:09 2007 From: dodji at seketeli.org (Dodji Seketeli) Date: Wed, 19 Dec 2007 09:13:09 +0100 Subject: Xephyr crashes In-Reply-To: <108798.37253.qm@web7908.mail.in.yahoo.com> References: <108798.37253.qm@web7908.mail.in.yahoo.com> Message-ID: <20071219081309.GA4062@coin> On Wed, Dec 19, 2007 at 11:15:08AM +0530, Tapojoy chatterjee wrote: > Hi > when we use the command u specified it works .. Okay. > only when we ask it connect it to XDM( provide an ip it crashes) > u may try this to verify > Xephyr :1 -ac -query localhost -once -screen 800x600x8 -fp /usr/share/X11/fonts/misc Okay. Could you please file a bug for this ? To file a bug, you have to go to http://bugs.freedesktop.org. It is important to do this so that I don't loose track of the bug report. Thanks. > > we are using Xorg -1.4 (7.3) and Xephyr is made from it....When we use > a 7.2 based Xephyr it works on all systems..but it has that CAPSLOCK > bug.. Which capslock bug ? Again, this is a bug to file into bugzilla I guess. > > Strace log is attached to this mail Thanks. Would be nice to this strace log to the bug. Cheers. -- Dodji Seketeli http://www.seketeli.org/dodji From mailinglists at who-t.net Wed Dec 19 00:48:09 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 19 Dec 2007 19:18:09 +1030 Subject: possible bug In-Reply-To: <47668E2D.7010408@gmx.de> References: <474AF85B.7030608@gmx.de> <474B877F.8070507@who-t.net> <47668E2D.7010408@gmx.de> Message-ID: <4768DAC9.60302@who-t.net> Simon Thum wrote: > Hi Peter, > > I think I've found a followup: > Again in getdctl.c, l. 300: > case DEVICE_CORE: > total_length = sizeof(xDeviceCoreCtl); > > Shouldn't that, if only for consitency, refer to xDevice*State? I don't > think those stuctures are actually diffently sized, but they differ for > sure. pushed, thanks. Cheers, Peter From jm at orangeandbronze.com Wed Dec 19 01:10:49 2007 From: jm at orangeandbronze.com (JM Ibanez) Date: Wed, 19 Dec 2007 17:10:49 +0800 Subject: Best way of determining multiple monitor config? In-Reply-To: <200712181108.32775.hamish@travellingkiwi.com> (hamish@travellingkiwi.com's message of "Tue\, 18 Dec 2007 11\:08\:32 +0000") References: <200712172203.52352.hamish@travellingkiwi.com> <87hcigts2d.fsf@adler.orangeandbronze.com> <200712181108.32775.hamish@travellingkiwi.com> Message-ID: <877ijbcana.fsf@adler.orangeandbronze.com> Hamish writes: > On Tuesday 18 December 2007 06:50:18 you wrote: >> Hamie writes: >> > Hi. >> > >> > What's the current recommended method of an application determining the >> > configuration of (Possibly) multiple monitor setup? Should I still use >> > the libXinerama calls? Or are there 'better' calls to use nowadays? >> >> As I understand it, the recommended way is via XRandR 1.2; although the >> XRandR 1.2 extension does have Xinerama legacy support, XRandR 1.2 has >> the added ability to detect runtime changes to the configuration (and >> more accurate detection of monitor placement, etc.). > > > Hmm... That's what I thought. But although I can get the screens & sizes with > Xinerama no problems, I couldn't find anything in RandR that gave the szes of > individual screens... Just the total size (Apart from XRRGetScreenInfo which > says returns XRRScreenConfiguration, which looks perfect until I read the bit > about opaque data type for internal use only...). > > maybe I'm looking at the wrong place in RandR? Check out the changes to RandR in 1.2; be sure to read randrproto.txt in the protocol's tree. Clone it from git://anongit.freedesktop.org/git/xorg/proto/randrproto Additionally, you may want to study the source for the xrandr(1) CLI utility, which does implement the querying of the configuration of all outputs. -- JM Ibanez Software Architect Orange & Bronze Software Labs, Ltd. Co. jm at orangeandbronze.com http://software.orangeandbronze.com/ From fjuers at sii.fr Wed Dec 19 02:00:39 2007 From: fjuers at sii.fr (Franck Juers) Date: Wed, 19 Dec 2007 11:00:39 +0100 Subject: display video from an other PC / Replace background of an application Message-ID: <7215bb460712190200v6993e271if95ebbf67ea8340c@mail.gmail.com> Hello, I have to replace the background (made of one single color) of an application (which I cannot modify) by the video from an other PC. I can acquire the video from the other PC with a frame grabber card (UFG-03 from Unigraf), but I'm not able to change the background of the application by hardware overlay because this card doesn't do it... I'd like to know if there's a way to access the frame Buffer of X11 to change the background of the application or to set the black color of this application transparent... The video from the other PC isn't static... so i have to make a loop like: - grab a frame from the PC video - replace the color background with the frame maybe there is a way to do a kind of software overlay ?? An other idea I had is to launch the application I cannot modify somewhere i won't see it, capture the display of this application and merge it with the frame from the PC, then I do the final display in my application or maybe i have to do it an other way but i have no more idea... thanks for your help, Franck -------------- next part -------------- An HTML attachment was scrubbed... URL: From xorg.the.jokluge at recursor.net Wed Dec 19 04:03:00 2007 From: xorg.the.jokluge at recursor.net (Joachim Kluge) Date: Wed, 19 Dec 2007 13:03:00 +0100 Subject: [intel] wrong white and black levels in xv In-Reply-To: <20071122124451.6a3bb811@host> References: <20071122124451.6a3bb811@host> Message-ID: <20071219130300.79986c01@host> On Thu, 22 Nov 2007 12:44:51 +0100 Joachim Kluge wrote: > I have an issue with correct black and white levels with > the intel driver. The most visible symptom is a greyish black in > movies. Unfortunately nobody answered. So I'll bring up the topic once more since I'm affected by greyish movies every day. There must be someone reading who knows something about intel, XV and color levels! Joachim Kluge (quoted message at http://lists.freedesktop.org/archives/xorg/2007-November/030417.html) From maciej.lozinski at impessa.com Wed Dec 19 08:34:12 2007 From: maciej.lozinski at impessa.com (=?UTF-8?B?TWFjaWVqIMWBb3ppxYRza2k=?=) Date: Wed, 19 Dec 2007 17:34:12 +0100 Subject: Problem with intel driver on laptop with 945GM chipset Message-ID: <47694804.9030302@impessa.com> Hello all. I have a problem with setting up "intel" driver properly on my laptop. I'm using: Compaq nx7400 (EY611EA#AKD) laptop, 945GM chipset, GMA 950 graphics, Debian testing with kernel 2.6.22, xorg 7.2, Xfce 4.1, intel driver module version 2.2.0 The problem is that when I enable "intel" driver instead of "vesa" which was auto-detected during installation, and restart X, colors on my screen start to appear very strange, while in vesa they look ok. See how it looks like: http://picasaweb.google.com/loziniak/BrokenColorsInX I was searching google, mailing list archives, wikis, bug reports, but found no solution to this problem. Here is some information that could be useful to you, I'm not xorg hacker so these logs don't clear anything to me: Xorg.0.log (intel): http://pastebin.com/m42ea768d Xorg.0.log (vesa): http://pastebin.com/m59a84ee5 xorg.conf: http://rafb.net/p/DlCU6C43.html Do you have any ideas what could be done with it? thanks in advance Maciek From ast at arlut.utexas.edu Wed Dec 19 07:55:53 2007 From: ast at arlut.utexas.edu (Andrew Troschinetz) Date: Wed, 19 Dec 2007 09:55:53 -0600 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: <476868D8.9090905@netspace.net.au> References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <476868D8.9090905@netspace.net.au> Message-ID: On Dec 18, 2007, at 6:42 PM, Russell Shaw wrote: > Make X synchronous and BadMatch errors will be easier to find. Interestingly, using XPeekIfEvent() wrapped in XSynchronize(True/ False) calls makes the BadMatch sometimes less likely to occur. To reproduce the error I've been minimizing (manually, I'm in Gnome) and then un-minimizing via a call to my map_raise_focus() function. Without the XSynchronize() calls this gives the error on either the first or second attempt to un-minimize. With XSynchronize() calls it sometimes (though sometimes not) takes about 10 tries, but the error always does eventually happen. I've looked over the code that is being executed in its entirety to check if any other Xlib function could have caused a BadMatch error and it appears XSetInputFocus() is the only culprit. Just for reference, in the code that's being executed I've only got these functions: XPeekIfEvent() XSelectInput() XGetWindowAttributes() XMapRaised() XSetInputFocus() XGetWindowProperty() XGetWMName() XFree() Even assuming I'm not using one of those correctly, none of them but the XSetInputFocus() can cause a BadMatch, or is there a way I can get BadMatch some other way? Incidentally, since XSynchronize() was able to give me sometimes more stability I thought that maybe the solution that uses XWindowEvent() is also only exhibiting sometimes more stability as well. So I tried as hard as I could to crash the program that's using XWindowEvent() but I just can't do it, it appears to work all the time whereas the XPeekIfEvent() fails very quickly. I also printed out the values of the XEvent that causes the do-while- XWindowEvent() loop to exit and the XEvent returned by XPeekIfEvent() and they're the same --- So XPeekIfEvent() and XWindowEvent() are returning the same event exactly how I want them to, but one fails and the other doesn't. So yeah, I'm completely clueless now. Maybe I _DO_ want to remove the XEvent from the event queue? On Dec 18, 2007, at 6:10 PM, Peter Harris wrote: > The only remaining thing I can think of is the return type: Bool. The only includes I've got are X11 headers, stl headers, and ctime which makes errors like this less likely. I just checked that I didn't typedef of #define Bool/True/False to be sure but nope that's not the problem either. I even changed all True to 1, False to 0, and Bool to int just to be extra double for sure ;) No luck. -- Andrew Troschinetz Applied Research Laboratories -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcpa at mandriva.com.br Wed Dec 19 07:59:58 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Wed, 19 Dec 2007 13:59:58 -0200 Subject: Adding xinput to apps In-Reply-To: <4768B948.10204@who-t.net> References: <4768A08A.7070300@who-t.net> <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> <4768AB17.7090400@who-t.net> <20071219041223.pm8945c26cbo4w8s@webmail.conectiva.com.br> <4768B948.10204@who-t.net> Message-ID: <47693FFE.7020502@mandriva.com.br> Peter Hutterer wrote: >> As I said, I have pretty much nil knowledge about XInput, but from >> a quick view of the source, it may be a good idea to have it available, >> unless it is choosen to do something like you said, and remove the >> modules broken in branch 1.4, but again, after some "overview" on the >> code of some input modules, this doesn't look like a wise idea as it >> looks >> like code that used to work for several years, so maybe there is some >> magic that can be done to make 1.4 work as 1.3, or earlier regarding to >> extended input devices, i.e. some kind of compat mode. > > less commas and more periods please. I'm not sure if I understood this > sentence ;) I think I did not understand that sentence myself :-). Anyways, while I am actually in favor of having people updating the system and having freedom for developers experimenting, I believe some special precautions should be made before breaking this kind of code. Anyway, probably nobody would care we Xorg dropped more than half of the video drivers in the git repository, (that are supposed to work, but I have my doubts...) as well as most of the *fb* modules. > > the xinput tool does not have anything to do with the input modules. > It is basically just a runtime configuration tool. > > btw. "used to work" is not the same as "nobody complained" :) > Yes :-), but I think it used to work in some timeframe. But I cannot guess since when it is broken, I only know that now it doesn't even load. > Cheers, > Peter Paulo From joerg at britannica.bec.de Wed Dec 19 08:03:28 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Wed, 19 Dec 2007 17:03:28 +0100 Subject: Adding xinput to apps In-Reply-To: <47693FFE.7020502@mandriva.com.br> References: <4768A08A.7070300@who-t.net> <20071219030612.ewlx7gas2qrk00ws@webmail.conectiva.com.br> <4768AB17.7090400@who-t.net> <20071219041223.pm8945c26cbo4w8s@webmail.conectiva.com.br> <4768B948.10204@who-t.net> <47693FFE.7020502@mandriva.com.br> Message-ID: <20071219160328.GA11454@britannica.bec.de> On Wed, Dec 19, 2007 at 01:59:58PM -0200, Paulo Cesar Pereira de Andrade wrote: > Anyway, probably nobody would care we Xorg dropped more than half of the > video drivers in the git repository, (that are supposed to work, but I have > my doubts...) as well as most of the *fb* modules. NetBSD would care. We have already quite a large number of drivers for the older code base of XFree 4.5 and increases that makes the job to move to modular Xorg not exactly easier. Joerg From cworth at cworth.org Wed Dec 19 08:12:02 2007 From: cworth at cworth.org (Carl Worth) Date: Wed, 19 Dec 2007 08:12:02 -0800 Subject: Initial attempts at i965 text batching In-Reply-To: <87y7byawz3.wl%cworth@cworth.org> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> Message-ID: <87ir2uzmst.wl%cworth@cworth.org> So a long time ago I reported that with my i965 I could get about 290,000 glyphs/sec. from "x11perf -aa10text" by using the NoAccel option to the X server, and similar performance with XAA, but only 95,000 glyphs./sec with EXA due to the synchronous compositing bug in the driver. Since then, Dave Airlie rewrote the driver to use batch buffers, which completely eliminated all of the syncs. By design, his work was "functional, not performant" as it would go through all the effort of allocating a new batch buffer, initializing all device state, and emitting the batch for every compositing operation. Needless to say, that's more work than we really want to do, and it showed by getting performance in the range of 1000 - 10,000 glyphs/sec. Since then, I've rewritten parts of the driver to attempt to take advantage of the batch buffers by actually batching up as much as possible. General device state is only initialized once, then surface-specific state is initialized in a batch basis within a buffer object. My work is available in the master branch of my personal xf86-video-intel repository: http://cgit.freedesktop.org/~cworth/xf86-video-intel/log/ This work required some changes to the drm interface which Dave kindly provided here, (in a hacked form---a cleaner version merged together with Keith's recent work will come soon): http://cgit.freedesktop.org/~airlied/drm/log/?h=i965-hack-drm So both of those are required for anyone that wants to experiment with this. As for performance, initially batching seems to help a lot, but we hit a ceiling sooner than I would like to: Ops/batch Glyphs/sec. ---------- ----------- 1 10,000 2 20,000 4 37,000 8 67,000 16 110,000 32 120,000 64 120,000 128 120,000 For people that saw an earlier version of this table, I should explain two differences: * Earlier, it stopped at 64 since it started crashing after that. This was easy to workaround by increasing the BATCH_SZ value. Clearly there's some missing error-checking around that value. * Previously, it looked like things kept improving all the way to 64 ops./sec. That was because that version was unconditionally allocating a maximally larger buffer object for the surface state, (so the allocation overheard hit every case). Here, the surface state buffer object is allocated at the appropriate size, so the smaller batching cases improve and we hit the 120,000 glyphs/sec. ceiling earlier. I'll be looking into why things aren't faster than this, but first I'll need to get oprofile working on my system again.[*] -Carl [*] Right now opreport is complaining with: opreport: error while loading shared libraries: libbfd-2.18.so: cannot open shared object file: No such file or directory Does that mean anything to anybody? I'm doing a general system upgrade now to see if that helps. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From krh at bitplanet.net Wed Dec 19 08:41:04 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 19 Dec 2007 11:41:04 -0500 Subject: Initial attempts at i965 text batching In-Reply-To: <87ir2uzmst.wl%cworth@cworth.org> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> <87ir2uzmst.wl%cworth@cworth.org> Message-ID: <59ad55d30712190841o2693666m8e5ee66223560bfe@mail.gmail.com> On Dec 19, 2007 11:12 AM, Carl Worth wrote: > So a long time ago I reported that with my i965 I could get about > 290,000 glyphs/sec. from "x11perf -aa10text" by using the NoAccel > option to the X server, and similar performance with XAA, but only > 95,000 glyphs./sec with EXA due to the synchronous compositing bug in > the driver. > > Since then, Dave Airlie rewrote the driver to use batch buffers, > which completely eliminated all of the syncs. By design, his work was > "functional, not performant" as it would go through all the effort of > allocating a new batch buffer, initializing all device state, and > emitting the batch for every compositing operation. > > Needless to say, that's more work than we really want to do, and it > showed by getting performance in the range of 1000 - 10,000 > glyphs/sec. > > Since then, I've rewritten parts of the driver to attempt to take > advantage of the batch buffers by actually batching up as much as > possible. General device state is only initialized once, then > surface-specific state is initialized in a batch basis within a buffer > object. Which reminds me, I did a couple of DRM patches to use MI_SET_CONTEXT that I promised to send out. I've not benchmarked them, and there is still work to do to finish them (they leak memory) but if there's a lot of overhead in emitting the invariant state, these patches might help. cheers, Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-the-idr-for-acutally-tracking-the-drm_context_t.patch Type: text/x-patch Size: 9798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Emit-MI_SET_CONTEXT-before-executing-a-batch-buffer.patch Type: text/x-patch Size: 5247 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ddx-mi-set-context.patch Type: text/x-patch Size: 411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mesa-mi-set-context.patch Type: text/x-patch Size: 482 bytes Desc: not available URL: From michel at tungstengraphics.com Wed Dec 19 09:00:31 2007 From: michel at tungstengraphics.com (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Wed, 19 Dec 2007 18:00:31 +0100 Subject: Initial attempts at i965 text batching In-Reply-To: <87ir2uzmst.wl%cworth@cworth.org> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> <87ir2uzmst.wl%cworth@cworth.org> Message-ID: <1198083631.8928.216.camel@thor.sulgenrain.local> On Wed, 2007-12-19 at 08:12 -0800, Carl Worth wrote: > > opreport: error while loading shared libraries: libbfd-2.18.so: cannot > open shared object file: No such file or directory > > Does that mean anything to anybody? I'm doing a general system upgrade > now to see if that helps. It means you no longer have the same version of binutils that opreport was built against, and you need to rebuild it. (It should really link against the static libbfd to avoid this) -- Earthling Michel D?nzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer From roger at jikos.cz Wed Dec 19 08:27:28 2007 From: roger at jikos.cz (Roger) Date: Wed, 19 Dec 2007 17:27:28 +0100 (CET) Subject: Oprofile (re: Initial attempts at i965 text batching) Message-ID: Hi! Maybe this helps: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446360 Bye Roger From plangdale at vmware.com Wed Dec 19 09:37:19 2007 From: plangdale at vmware.com (Philip Langdale) Date: Wed, 19 Dec 2007 09:37:19 -0800 Subject: Adding xinput to apps In-Reply-To: <4768A08A.7070300@who-t.net> References: <4768A08A.7070300@who-t.net> Message-ID: <476956CF.9080503@vmware.com> Peter Hutterer wrote: > > Philip Langdale stepped up to maintain it. [1] Philip, are you still up > for it? If not, I can do it. Yep, I'm still up for it. I'd like to push out a new official release soon but right now I'm still having problems with server 1.4. If input hotplug is disabled, then it seems to work correctly, but with hotplug enabled, it seems to be ignoring any attempts at altering mouse acceleration or button maps. As far as I can tell, the app is doing the right thing (when you query state it reflects your changes) but the server is not respecting the settings. I'd like to get to the root of the problem before doing a release - in case updates to the app are required. --phil From glynn at gclements.plus.com Wed Dec 19 10:36:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed, 19 Dec 2007 18:36:20 +0000 Subject: Raise/Map and Focus a window: BadMatch error In-Reply-To: References: <84751C48-A9EC-44FC-B57C-C2B2B8AB944B@arlut.utexas.edu> <476868D8.9090905@netspace.net.au> Message-ID: <18281.25764.985232.596290@cerise.gclements.plus.com> Andrew Troschinetz wrote: > I also printed out the values of the XEvent that causes the do-while- > XWindowEvent() loop to exit and the XEvent returned by XPeekIfEvent() > and they're the same --- So XPeekIfEvent() and XWindowEvent() are > returning the same event exactly how I want them to, but one fails and > the other doesn't. So yeah, I'm completely clueless now. Maybe I _DO_ > want to remove the XEvent from the event queue? It needs to get removed at some point; otherwise, once XPeekIfEvent() returns true once, it will always return true thereafter, even if the window is subsequently unmapped. The issue is whether or not you need to remove it in this particular section of code. If you have a generic main loop which will remove it anyhow, you probably shouldn't be removing it yourself (particularly if you are using a toolkit which wants that event for its own purposes). But what happens if the window gets unmapped before main loop gets around to removing that event? Maybe you should remove it then put it back onto the head of the queue? Ultimately, there's always the possibility of spurious errors occurring due to race conditions. -- Glynn Clements From jbarnes at virtuousgeek.org Wed Dec 19 09:50:59 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 19 Dec 2007 09:50:59 -0800 Subject: [intel] wrong white and black levels in xv In-Reply-To: <20071219130300.79986c01@host> References: <20071122124451.6a3bb811@host> <20071219130300.79986c01@host> Message-ID: <200712190950.59907.jbarnes@virtuousgeek.org> On Wednesday, December 19, 2007 4:03 am Joachim Kluge wrote: > On Thu, 22 Nov 2007 12:44:51 +0100 > > Joachim Kluge wrote: > > I have an issue with correct black and white levels with > > the intel driver. The most visible symptom is a greyish black in > > movies. > > Unfortunately nobody answered. So I'll bring up the topic once more > since I'm affected by greyish movies every day. There must be someone > reading who knows something about intel, XV and color levels! Sorry Joachim, your message got lost in my forest of inboxes. :) There have been a few reports of TV problems with different configurations, can you be sure there's a bug filed for yours? There's also a patch floating around that will let you adjust the various TV output properties that you could try; if it works at least it'll give us a clue what the problem might be. Thanks, Jesse From jbarnes at virtuousgeek.org Wed Dec 19 09:53:56 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 19 Dec 2007 09:53:56 -0800 Subject: Problem with intel driver on laptop with 945GM chipset In-Reply-To: <47694804.9030302@impessa.com> References: <47694804.9030302@impessa.com> Message-ID: <200712190953.56768.jbarnes@virtuousgeek.org> On Wednesday, December 19, 2007 8:34 am Maciej ?ozi?ski wrote: > Hello all. > > I have a problem with setting up "intel" driver properly on my laptop. > I'm using: > Compaq nx7400 (EY611EA#AKD) laptop, > 945GM chipset, > GMA 950 graphics, > Debian testing with kernel 2.6.22, > xorg 7.2, > Xfce 4.1, > intel driver module version 2.2.0 > > The problem is that when I enable "intel" driver instead of "vesa" which > was auto-detected during installation, and restart X, colors on my > screen start to appear very strange, while in vesa they look ok. See how > it looks like: > http://picasaweb.google.com/loziniak/BrokenColorsInX Well the version on the intel side definitely doesn't look right... What's your configuration? Is this output on a TV? Is the program generating the test images using OpenGL to do it? Jesse From cworth at cworth.org Wed Dec 19 09:54:36 2007 From: cworth at cworth.org (Carl Worth) Date: Wed, 19 Dec 2007 09:54:36 -0800 Subject: Initial attempts at i965 text batching In-Reply-To: <59ad55d30712190841o2693666m8e5ee66223560bfe@mail.gmail.com> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> <87ir2uzmst.wl%cworth@cworth.org> <59ad55d30712190841o2693666m8e5ee66223560bfe@mail.gmail.com> Message-ID: <87fxxyzi1v.wl%cworth@cworth.org> On Wed, 19 Dec 2007 11:41:04 -0500, "=?UTF-8?Q?Kristian_H=C3=B8gsberg?=" wrote: > Which reminds me, I did a couple of DRM patches to use MI_SET_CONTEXT > that I promised to send out. I've not benchmarked them, and there is > still work to do to finish them (they leak memory) but if there's a > lot of overhead in emitting the invariant state, these patches might > help. Thanks for the starting point. And thanks, Michel, for pointing out how I can fix opreport. Even without opreport though, it's obvious that there's still tons of stuff being emitted in every prepare_composite uselessly. One piece is the "invariant" state Kristian mentions. This is followed by a "long sequence" of commands most of which are the same for all composite operations. So it should be a fairly simple matter to simply emit those at the beginning of each batch rather than with every composite operation within the batch. (In fact, Keith and I have even done that work once or twice before on earlier branches.) That will still leave some per-batch overhead of course, but we should be able to amortize most of that with increasing the number of operations in each batch. And then as an optimization, as Kristian mentions, we should be able to eliminate these from all but the first batch by taking advantage of MI_SET_CONTEXT. So the plan seems quite clear here. I'll keep the list posted on progress. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Magnus.Vigerlof at home.se Wed Dec 19 10:20:12 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-1?q?Vigerl=F6f?=) Date: Wed, 19 Dec 2007 19:20:12 +0100 Subject: [RFC] dix: Re-introduce rescaling on motion events for extended =?iso-8859-1?q?event=09reporting?= In-Reply-To: <476852D6.8030201@who-t.net> References: <200712161853.46380.Magnus.Vigerlof@home.se> <476852D6.8030201@who-t.net> Message-ID: <200712191920.12653.Magnus.Vigerlof@home.se> On onsdag 19 december 2007, Peter Hutterer wrote: [...] > > This time I haven't introduced any interface changes. The values that > > should be reported for the device are the same as in xserver 1.3, > > including the max-values on X&Y. The drivers that has been adapted to > > cope with the current situation will continue to work as the max-value > > registered by the driver is used in the scaling. > > one thing: in the proposed patch, pDev->valuator->lastx/lasty are set > before the call to miPointerSetPosition. lastx/lasty of the VCP however > afterwards. > miPSP may change x/y if there was a screen switch. so you may end up > with different coordinates here. > > could this be a problem? I've looked at the code several times but I'm > still unsure. When I read miPSP I get the impression that devices with well defined axis that are suitable for absolute reporting will never trigger a screen switch.. So I'd say that they will be untouched. With or without the patch, clipAxis will be called and for those devices with a defined min/max and everything outside the range will be trimmed. This value will then be used (with patch, after scaling to the screen size) for screen coords which are well within limits already. Maybe this behaviour is a fault in itself and relative movements should perhaps never call clipAxis? (which, btw, doesn't always clip to max but always to min) That would be a different patch tough. If we remove those calls from the relative reporting then, for the two events to be in sync, they must be scaled again into the device coordinate system. At the moment it would work as it does in xserver 1.3 (the extension event is generated before the core and the call to miPointerAbsoluteCursor/miPointerPosition). I just realised that I missed to take into account the min-value of the axis, so I'll have to redo the patch and test with that adjustment too. > aside from that, I'd say its fine. Thanks for the comments! Cheers Magnus From daniel.naughton at gmail.com Wed Dec 19 10:30:44 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Wed, 19 Dec 2007 12:30:44 -0600 Subject: 3d hardware acceleration in 945GM chipset - is there any? Message-ID: I think I have a line on what's screwing up dri. You were correct - something was hanging on to it. I shut the computer off (in frustration) and when it powered back up, dri was working. So I ran the "tremulous test program" and the Xserver hung. Ctrl-alt-backspace to kill it. Then when I restarted the xserver, dri was gone. The lsof command found what grabbed it. So I think I got it. I'll have to try a few things. Getting fullscreen apps to run in multihead mode with dri looks like it gonna take a little more monkeying around. But at least the hardware is working. So far, the 945GM chip looks like it can do pretty cool things. Thanks all! # /usr/sbin/lsof /dev/dri/card0 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME tremulous 3193 testguy mem CHR 226,0 19459 /dev/dri/card0 tremulous 3193 testguy 15u CHR 226,0 19459 /dev/dri/card0 # ps aux | grep trem testguy 3193 111 6.7 256012 69232 ? Sl 13:39 4:28 tremulous root 3505 0.0 0.0 4044 664 pts/1 R+ 13:43 0:00 grep trem From keith at tungstengraphics.com Wed Dec 19 10:47:41 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Wed, 19 Dec 2007 18:47:41 +0000 Subject: Initial attempts at i965 text batching In-Reply-To: <87fxxyzi1v.wl%cworth@cworth.org> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> <87ir2uzmst.wl%cworth@cworth.org> <59ad55d30712190841o2693666m8e5ee66223560bfe@mail.gmail.com> <87fxxyzi1v.wl%cworth@cworth.org> Message-ID: <4769674D.5030501@tungstengraphics.com> Carl Worth wrote: > On Wed, 19 Dec 2007 11:41:04 -0500, "=?UTF-8?Q?Kristian_H=C3=B8gsberg?=" wrote: >> Which reminds me, I did a couple of DRM patches to use MI_SET_CONTEXT >> that I promised to send out. I've not benchmarked them, and there is >> still work to do to finish them (they leak memory) but if there's a >> lot of overhead in emitting the invariant state, these patches might >> help. > > Thanks for the starting point. > > And thanks, Michel, for pointing out how I can fix opreport. > > Even without opreport though, it's obvious that there's still tons of > stuff being emitted in every prepare_composite uselessly. One piece is > the "invariant" state Kristian mentions. This is followed by a "long > sequence" of commands most of which are the same for all composite > operations. > > So it should be a fairly simple matter to simply emit those at the > beginning of each batch rather than with every composite operation > within the batch. (In fact, Keith and I have even done that work once > or twice before on earlier branches.) > > That will still leave some per-batch overhead of course, but we should > be able to amortize most of that with increasing the number of > operations in each batch. Indeed -- even if you only have two operations per batch, you get 50% of the theoretical best-possible optimization of this state emit by just removing one of them. Keith From daniel.naughton at gmail.com Wed Dec 19 12:30:15 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Wed, 19 Dec 2007 14:30:15 -0600 Subject: xorg.conf - setting a specific resolution for monitor gets ignored (945GM) Message-ID: I'm working on getting the dual head thing working, but dri won't work if the virtual size is > 2048 - so I have make sure the combined monitors don't exceed that (At least I'm pretty sure that's the approach). I've been trying to fix the resolution of the monitor (I'm starting with 800x600), but the xserver won't cooperate. Section "Screen" Identifier "Screen0" Monitor "Monitor0" SubSection "Display" Depth 16 Modes "myVGA" EndSubSection Section "Monitor" Identifier "Monitor0" Modeline "myVGA" 38.22 800 832 912 1024 600 601 604 622 -HSync +Vsync I got the Modeline from gtf # gtf 800 600 60 # 800x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 38.22 MHz Modeline "800x600_60.00" 38.22 800 832 912 1024 600 601 604 622 -HSync +Vsync inside .gonf there is a preference for screen resolutions. the desktop is either overriding what's in xorg.conf or the xsever is ignoring the Modeline part because I'm doing it wrong. xorg.conf attached -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: From reed at reedmedia.net Wed Dec 19 14:05:34 2007 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 19 Dec 2007 16:05:34 -0600 (CST) Subject: About some git repositories In-Reply-To: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> References: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> Message-ID: On Wed, 19 Dec 2007, pcpa at mandriva.com.br wrote: > About repository xf86-video-ast, commit > 486380cd85cdd2532300905ee588be48480ce1dc > seens weird as it was done by root at localhost.localdomain, and it is a big > commit, and it is also the commit that bumped the version: > 486380cd (root 2007-08-24 21:13:39 +0800 25) 0.84.7, How is this fixed in git history to show the correct person's name and email address? (It is in the ChangeLog.) And does git have some configuration to disallow an Author named "root"? I read that another popular open source project was compromised by an attacker who used a committer's compromised account. Jeremy C. Reed From creder at digitalcpt.com Wed Dec 19 14:16:08 2007 From: creder at digitalcpt.com (christopher reder) Date: Wed, 19 Dec 2007 16:16:08 -0600 Subject: xserver-kdrive, mouse, motion issues In-Reply-To: <1197997118.14968.27.camel@linuxserver.digital> References: <1197997118.14968.27.camel@linuxserver.digital> Message-ID: <1198102568.3447.20.camel@linuxserver.digital> On Tue, 2007-12-18 at 10:58 -0600, christopher reder wrote: > All - > I have an embedded system running a AT91RM9200 with Kdrive 1.3.0 . With > it, we have a 16 bit framebuffer setup through linux running 2.6.21. > > When I use a mouse pointer and drag it along the screen, it will change > the background color such that I can see the 'box' that it redraws for > the mouse pointer and at the edges, it changes the value of the color > behind it. > > I also have a program that has some motion with it where a golfer takes > a swing, The same phenomenon happens. > > I am trying to figure out if there is a way to force kdrive to access a > routine in the framebuffer code for reads and writes so I can figure out > what is messing up in the interaction with the framebuffer and the > ARM9. > > Are there functions in the X library that do the mouse 'read modify > write' and can I have access to them via the framebuffer code to see > what may be going wrong (for example, trying to access as a 24 bit vs a > 16 bit, bad mask, or anything else?) > > Does anyone have a suggestion or a way to do this so I can debug it > better/further? > > Thanks > Christopher > Perhaps an easier question would be if anyone could tell me where the read/modify/write is done for things like a mouse pointer and if it is possible to force that read/modify/write to be executed through a function in the kernel. Thanks From vignatti at c3sl.ufpr.br Wed Dec 19 14:45:53 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Wed, 19 Dec 2007 20:45:53 -0200 Subject: VGA arbiter: removing RAC Message-ID: <47699F21.8000001@c3sl.ufpr.br> Hi guys, The Resource Access Control inside Xorg is the guy responsible to take care of the various resources of memory and to share them in a wise manner when two or more graphics devices are active (think multi-head). As an alternative from RAC we can rely on VGA arbiter. So me and Paulo Zanoni spent the last days implementing "the glue" of Xorg to use the arbiter code with this purpose. Now we're trying to do some experiments to see what's the performance difference using the RAC and the arbiter. We thought in two tests: (a) a multi-head X with RAC and other with the arbiter. And (b), test a single-head X using the arbiter and other not using. In the (a), we can evaluate if the usage of the arbiter overloads the X server and (b) if there's some difference in use RAC or arbiter in a multi-head environment. So we ran the x11perf tool and reported a very tiny worthless gap in both tests (used with -comppixwin500, -move and -rect500 options). All the experiments you can see here: http://people.freedesktop.org/~vignatti/logs-between-rac-arb_19Dez2007.tar.gz Am I missing something about how I did these results or everything seems fine? (I made the mistake to test this things using CFLAGS='-g3 -O0'. Anyone knows if this will result in different conclusions between the two test cases? I'm using the git upstream code of server-1.4-branch and nv driver) Anyway, we will keep our working and the next challenge will be to think about DRI, xv and GL. my regards, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From xhejtman at ics.muni.cz Wed Dec 19 14:50:26 2007 From: xhejtman at ics.muni.cz (Lukas Hejtmanek) Date: Wed, 19 Dec 2007 23:50:26 +0100 Subject: Initial attempts at i965 text batching In-Reply-To: <87ir2uzmst.wl%cworth@cworth.org> References: <1197536605.9879.14.camel@optimus> <87y7byawz3.wl%cworth@cworth.org> <87ir2uzmst.wl%cworth@cworth.org> Message-ID: <20071219225026.GB4275@ics.muni.cz> On Wed, Dec 19, 2007 at 08:12:02AM -0800, Carl Worth wrote: > So a long time ago I reported that with my i965 I could get about > 290,000 glyphs/sec. from "x11perf -aa10text" by using the NoAccel > option to the X server, and similar performance with XAA, but only > 95,000 glyphs./sec with EXA due to the synchronous compositing bug in > the driver. If interested, right now, I'm able to get 215000 glyphs/sec on my i965GM box with EXA enabled. I use MigrationHeuristics Greedy. -- Luk?? Hejtm?nek From dparsons at debian.org Wed Dec 19 15:10:01 2007 From: dparsons at debian.org (Drew Parsons) Date: Thu, 20 Dec 2007 10:10:01 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <200712180913.32212.jbarnes@virtuousgeek.org> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> Message-ID: <1198105801.6348.9.camel@localhost.localdomain> On Tue, 2007-12-18 at 09:13 -0800, Jesse Barnes wrote: > On Monday, December 17, 2007 10:08 pm Drew Parsons wrote: > > On Mon, 2007-12-17 at 15:13 -0800, Jesse Barnes wrote: > > > On Sunday, December 16, 2007 4:12 Drew Parsons wrote: > > > > S3 resume simply doesn't restore the display. Resume works fine, > > > > that is I can get to the virtual consoles with [Ctrl-]Alt-Fn and > > > > login. > > > > > > This may be an EXA bug (we moved to EXA by default in 2.2). Zhenyu > > > recently fixed an EXA suspend/resume bug in the git tree, can you give > > > it a try and see if you still see problems? > > > > > > Thanks, > > > Jesse > > > > Do you mean the rendering fix in intel, commit > > 13ec9c8141a9f794258869a04a6bab59dac5eefa ? > > Yeah, that's the one. I cherry-picked this commit, but it didn't help. Same result with the half-painted windows after resume. So I then tried Option "AccelMethod" "XAA". With XAA, upon resume I got the ghosted windows, reported at bug #7834. I thought this must mean we had a clear regression in intel 2.2, since I reported the ghosting problem had been fixed in 2.1. But I checked, and distressingly that problem is back again, even after downgrading back to intel 2.1.1 and linux 2.6.22. I didn't downgrade mesa or xserver, which are now slightly higher versions than on 6 Nov when I had S3 success. I'm not sure which phase of the moon my computer was running under that one day when S3 resume worked. I guess we'll have to reopen bug #7834 again :( Sorry for the bad news, Drew From joerg at britannica.bec.de Wed Dec 19 15:12:39 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Thu, 20 Dec 2007 00:12:39 +0100 Subject: VGA arbiter: removing RAC In-Reply-To: <47699F21.8000001@c3sl.ufpr.br> References: <47699F21.8000001@c3sl.ufpr.br> Message-ID: <20071219231239.GF29049@britannica.bec.de> On Wed, Dec 19, 2007 at 08:45:53PM -0200, Tiago Vignatti wrote: > The Resource Access Control inside Xorg is the guy responsible to take > care of the various resources of memory and to share them in a wise > manner when two or more graphics devices are active (think multi-head). > As an alternative from RAC we can rely on VGA arbiter. How much work is the kernel part of the arbiter? You know, the Xserver is not only used on Linux :-) Joerg From rglowery at exemail.com.au Wed Dec 19 16:14:16 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Thu, 20 Dec 2007 11:14:16 +1100 (EST) Subject: [intel] wrong white and black levels in xv In-Reply-To: <20071219130300.79986c01@host> References: <20071122124451.6a3bb811@host> <20071219130300.79986c01@host> Message-ID: <47175.64.213.30.2.1198109656.squirrel@webmail.exetel.com.au> > On Thu, 22 Nov 2007 12:44:51 +0100 > Joachim Kluge wrote: > >> I have an issue with correct black and white levels with >> the intel driver. The most visible symptom is a greyish black in >> movies. > > Unfortunately nobody answered. So I'll bring up the topic once more > since I'm affected by greyish movies every day. There must be someone > reading who knows something about intel, XV and color levels! version 2.2.0 of the intel driver contains commit 6eecef4fed8a21dfdabef42eb69fd150b96167b2 which reverts the TV out brightness from 0x10 back to 0x00, fixing this washed out issue for me. (In fact I also change the contrast and saturation from 0x60 to 0x40 for even better results). You can hack the 2.1.0 driver with a hex editor to get the same results :) Are you only seeing this issue with TV out? > > Joachim Kluge > > (quoted message at > http://lists.freedesktop.org/archives/xorg/2007-November/030417.html) > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From vignatti at c3sl.ufpr.br Wed Dec 19 16:43:58 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Wed, 19 Dec 2007 22:43:58 -0200 Subject: VGA arbiter: removing RAC In-Reply-To: <20071219231239.GF29049@britannica.bec.de> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> Message-ID: <4769BACE.7090307@c3sl.ufpr.br> Joerg Sonnenberger escreveu: > On Wed, Dec 19, 2007 at 08:45:53PM -0200, Tiago Vignatti wrote: >> The Resource Access Control inside Xorg is the guy responsible to take >> care of the various resources of memory and to share them in a wise >> manner when two or more graphics devices are active (think multi-head). >> As an alternative from RAC we can rely on VGA arbiter. > > How much work is the kernel part of the arbiter? You know, the Xserver > is not only used on Linux :-) git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git for more info about the code, please see http://lists.freedesktop.org/archives/xorg/2007-November/030420.html And yes, unfortunately we will need to keep the RAC module together with the VGA arbiter inside Xorg for some time due the portability of Xorg. Probably let autoconf set if Xorg needs RAC or the arbiter depending the OS would be fine and easy to do. Cheers, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From libv at skynet.be Wed Dec 19 17:48:26 2007 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 20 Dec 2007 02:48:26 +0100 Subject: VGA arbiter: removing RAC In-Reply-To: <4769BACE.7090307@c3sl.ufpr.br> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> Message-ID: <20071220014826.GA13238@skynet.be> On Wed, Dec 19, 2007 at 10:43:58PM -0200, Tiago Vignatti wrote: > Joerg Sonnenberger escreveu: > > On Wed, Dec 19, 2007 at 08:45:53PM -0200, Tiago Vignatti wrote: > >> The Resource Access Control inside Xorg is the guy responsible to take > >> care of the various resources of memory and to share them in a wise > >> manner when two or more graphics devices are active (think multi-head). > >> As an alternative from RAC we can rely on VGA arbiter. > > > > How much work is the kernel part of the arbiter? You know, the Xserver > > is not only used on Linux :-) > > git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git > > for more info about the code, please see > http://lists.freedesktop.org/archives/xorg/2007-November/030420.html > > And yes, unfortunately we will need to keep the RAC module together with > the VGA arbiter inside Xorg for some time due the portability of Xorg. > Probably let autoconf set if Xorg needs RAC or the arbiter depending the > OS would be fine and easy to do. > > > Cheers, > > -- > Tiago Vignatti How compatible is this module? Against which kernels is it known to build and work? How hard is it to switch between this and RAC when the X server is started? At least for the time being. This because i fear that going for build time only immediately is too big a leap. After most of the initial pain is over, buildtime seems like the way to go. Luc Verhaegen. SUSE/Novell X Driver Developer. From vignatti at c3sl.ufpr.br Wed Dec 19 18:14:51 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Thu, 20 Dec 2007 00:14:51 -0200 Subject: VGA arbiter: removing RAC In-Reply-To: <20071220014826.GA13238@skynet.be> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> <20071220014826.GA13238@skynet.be> Message-ID: <4769D01B.7040302@c3sl.ufpr.br> Hi Luc, Luc Verhaegen escreveu: > How compatible is this module? Against which kernels is it known to > build and work? Currently the arbiter itself is a module and I'm building it using Linux 2.6.22.7. As I said in other email, the idea now is to see how DRI will fit when the arbiter is active. Probably some hang ups will occur due interruption things. After this, we'll post into lkml for a review of the people there. For now you can see the code here: git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git > > How hard is it to switch between this and RAC when the X server is > started? At least for the time being. This because i fear that going > for build time only immediately is too big a leap. After most of the > initial pain is over, buildtime seems like the way to go. I can't imagine in the top of my head how we can set a hook telling the server that we want this or that function when the server is running. Any hints here? regards, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From sergio at sergiomb.no-ip.org Wed Dec 19 18:40:46 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Thu, 20 Dec 2007 02:40:46 +0000 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1198105801.6348.9.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> <1198105801.6348.9.camel@localhost.localdomain> Message-ID: <1198118446.2887.5.camel@monteirov> On Thu, 2007-12-20 at 10:10 +1100, Drew Parsons wrote: > > > Do you mean the rendering fix in intel, commit > > > 13ec9c8141a9f794258869a04a6bab59dac5eefa ? > > > > Yeah, that's the one. > > I cherry-picked this commit, but it didn't help. Same result with the > half-painted windows after resume. > > So I then tried Option "AccelMethod" "XAA". With XAA, upon resume I > got > the ghosted windows, reported at bug #7834. > > I thought this must mean we had a clear regression in intel 2.2, since > I > reported the ghosting problem had been fixed in 2.1. But I checked, > and > distressingly that problem is back again, even after downgrading back > to > intel 2.1.1 and linux 2.6.22. I didn't downgrade mesa or xserver, > which > are now slightly higher versions than on 6 Nov when I had S3 success. > 2.6.22. > I'm not sure which phase of the moon my computer was running under > that > one day when S3 resume worked. I guess we'll have to reopen bug #7834 > again :( > > Sorry for the bad news, Hey , I ( talk by me ) , or you use xserver 1.4 branch, with mesa 7_0 branch , and libdrm 2.3.0 released with kernel>= 2.6.22 ( or 21) which means xserver 1.4.0.90 and mesa 7.0.2 , or we can't talk about Intel drives issues , but Xorg issues. Using Xserver git => using Mesa git which => using libdrm git which => update drm kernel modules > > Drew -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From libv at skynet.be Wed Dec 19 18:47:48 2007 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 20 Dec 2007 03:47:48 +0100 Subject: VGA arbiter: removing RAC In-Reply-To: <4769D01B.7040302@c3sl.ufpr.br> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> <20071220014826.GA13238@skynet.be> <4769D01B.7040302@c3sl.ufpr.br> Message-ID: <20071220024748.GA13942@skynet.be> On Thu, Dec 20, 2007 at 12:14:51AM -0200, Tiago Vignatti wrote: > Hi Luc, > > Luc Verhaegen escreveu: > >How compatible is this module? Against which kernels is it known to > >build and work? > > Currently the arbiter itself is a module and I'm building it using Linux > 2.6.22.7. As I said in other email, the idea now is to see how DRI will > fit when the arbiter is active. Probably some hang ups will occur due > interruption things. After this, we'll post into lkml for a review of > the people there. For now you can see the code here: > > git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git Have you tried building it against a few kernels on machines you have access to or are in your vicinity? On the quick git-clone and make (on openSUSE 10.2) i did before i wrote the previous email (given, without reading up on anything), the build was missing some defines already. I quickly scrolled through the readme and nothing came to my attention that explained how portable this was within even x86 linux kernels. > >How hard is it to switch between this and RAC when the X server is > >started? At least for the time being. This because i fear that going > >for build time only immediately is too big a leap. After most of the > >initial pain is over, buildtime seems like the way to go. > > I can't imagine in the top of my head how we can set a hook telling the > server that we want this or that function when the server is running. > Any hints here? Oh, i meant s/started/starting/, as in, before going into driver probing. Trying to switch between two different io arbitration systems any later doesn't make too much sense for me :) Luc Verhaegen. SUSE/Novell X Driver Developer. From airlied at gmail.com Wed Dec 19 19:13:33 2007 From: airlied at gmail.com (Dave Airlie) Date: Thu, 20 Dec 2007 13:13:33 +1000 Subject: VGA arbiter: removing RAC In-Reply-To: <20071220024748.GA13942@skynet.be> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> <20071220014826.GA13238@skynet.be> <4769D01B.7040302@c3sl.ufpr.br> <20071220024748.GA13942@skynet.be> Message-ID: <21d7e9970712191913q3490681dm4d5dffbd3470d7f2@mail.gmail.com> On Dec 20, 2007 12:47 PM, Luc Verhaegen wrote: > On Thu, Dec 20, 2007 at 12:14:51AM -0200, Tiago Vignatti wrote: > > Hi Luc, > > > > Luc Verhaegen escreveu: > > >How compatible is this module? Against which kernels is it known to > > >build and work? > > > > Currently the arbiter itself is a module and I'm building it using Linux > > 2.6.22.7. As I said in other email, the idea now is to see how DRI will > > fit when the arbiter is active. Probably some hang ups will occur due > > interruption things. After this, we'll post into lkml for a review of > > the people there. For now you can see the code here: > > > > git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git > > Have you tried building it against a few kernels on machines you have > access to or are in your vicinity? > > On the quick git-clone and make (on openSUSE 10.2) i did before i wrote > the previous email (given, without reading up on anything), the build > was missing some defines already. I quickly scrolled through the readme > and nothing came to my attention that explained how portable this was > within even x86 linux kernels. > I wouldn't bother with backwards compat for this type of feature, it'll need modifications to kernel side drivers as well.. This should only be targetted at upstream kernels and if later distros need to backport it then they should do so.. Dave. From daniel.naughton at gmail.com Wed Dec 19 19:26:00 2007 From: daniel.naughton at gmail.com (Dan Naughton) Date: Wed, 19 Dec 2007 21:26:00 -0600 Subject: xorg.conf - setting a specific resolution for monitor gets ignored (945GM) Message-ID: I think I found the answer to why the resolution settings in xorg.conf were getting ignored - they were getting changed by the desktop. I'm not sure where all the changing happens, but the fedora gnome desktop System=>Preferences=>Hardware=>Screen Resolution writes a file under ~/.gconfd/screen (I forget the exact name - I deleted it). Anyway, that resolution setting is used to change the resolution from what it was set for in the xorg.conf. That was a nasty thing to chase down. I guess that's fine until you pick one that puts you over the 2048 limit in DRI and breaks it with no warning. "Warning, this screen resolution will break your graphics acceleration and you games will run dog slow - click Okay to proceed". Also, the Power Management section has a timer set to shut off the monitor. When it shuts off, it never comes back. You need to Ctrl-Alt-Backspace to kill it and restart it. Anyway - I got the dual head working with dri at 1024x768 resolution per monitor. Looks nice. Final xorg.conf attached -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorg.conf.txt URL: From pcpa at mandriva.com.br Wed Dec 19 19:23:06 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Thu, 20 Dec 2007 01:23:06 -0200 Subject: Possible problem in repository xf86-video-savage Message-ID: <20071220012306.93ov7q32mrk48wgw@webmail.conectiva.com.br> Hi, Just possibly showing my "dumbness" about git, but this was the only case so far I found this kind or problem, so trying to describe it in the repository I found the possible problem: $ git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-savage xf86-video-savage at freedesktop $ cd xf86-video-savage at freedesktop $ git-archive --format=tar --prefix=xf86-video-savage-2.1.3/ xf86-video-savage-2.1.3 > xf86-video-savage-2.1.3.tar Now assume for some reason we want to generate patches from tag xf86-video-savage-2.1.3 up to commit ffc5ba7f0b1cdefdcecf6bd47018b6a4924bfc44 $ git format-patch xf86-video-savage-2.1.3..ffc5ba7f0b1cdefdcecf6bd47018b6a4924bfc44 That should generate the files: 0001-Minimal-change-set-to-convert-driver-to-the-new-PCI.patch 0002-Include-unistd.h-to-get-a-declaration-for-usleep.patch 0003-dos2unix.patch 0004-Merge-PCI-rework-support-and-classic-PCI-interface.patch Now testing: $ tar xf xf86-video-savage-2.1.3.tar $ cd xf86-video-savage-2.1.3 $ patch -p1 < ../0001-Minimal-change-set-to-convert-driver-to-the-new-PCI.patch patching file configure.ac patching file src/savage_dri.c Hunk #1 succeeded at 467 (offset 7 lines). Hunk #2 succeeded at 882 (offset 7 lines). patching file src/savage_driver.c Hunk #4 succeeded at 273 (offset 2 lines). Hunk #5 succeeded at 792 (offset 2 lines). Hunk #6 succeeded at 1378 (offset 67 lines). Hunk #7 succeeded at 1386 (offset 67 lines). Hunk #8 succeeded at 1396 (offset 67 lines). Hunk #9 succeeded at 1409 (offset 67 lines). Hunk #10 succeeded at 1418 (offset 67 lines). Hunk #11 succeeded at 2822 (offset 71 lines). Hunk #12 succeeded at 2859 (offset 71 lines). Hunk #13 succeeded at 2874 (offset 71 lines). Hunk #14 succeeded at 2905 with fuzz 2 (offset 68 lines). Hunk #15 succeeded at 2927 (offset 68 lines). patching file src/savage_driver.h Hunk #1 FAILED at 33. Hunk #2 FAILED at 365. 2 out of 2 hunks FAILED -- saving rejects to file src/savage_driver.h.rej ------------------- So it fails here. A possible culprit is: -- commit 68ceead721aeb75b9faed6297407a320a83499e4 Merge: da23218... bf5e2a5... Author: Ian Romanick Date: Wed Aug 22 11:45:43 2007 -0700 Merge branch 'master' into pci-rework Conflicts: src/savage_driver.h -- The ``Conflicts:'' sounds suspect. Another possible culprit I can see is the commit: -- commit da23218b067d9b1808fc1168737c79b3349af09e Author: Ian Romanick Date: Wed Aug 22 11:42:47 2007 -0700 dos2unix -- That does what the message says, i.e. converts a file with lines ending in ^M's to unix format, and src/savage_driver.h.rej is suspicious as it includes a lot of ^M's. Well, I tried to build a test case but could not repeat it, maybe need to create the test case with several overlaping changes... Or maybe there is a real problem in the repository that was caused by some merge, and may need some git-reset or the like to fix. The git version being used is 1.5.3.5 without any patches or modifications. If we have an outdated version of git in Mandriva, or I am just being dumb, fell free to tell me. I am still somewhat new to git... :-) Thanks, Paulo From mailinglists at who-t.net Wed Dec 19 20:24:00 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Thu, 20 Dec 2007 14:54:00 +1030 Subject: Adding xinput to apps In-Reply-To: <476956CF.9080503@vmware.com> References: <4768A08A.7070300@who-t.net> <476956CF.9080503@vmware.com> Message-ID: <4769EE60.4020300@who-t.net> Philip Langdale wrote: > Peter Hutterer wrote: >> Philip Langdale stepped up to maintain it. [1] Philip, are you still up >> for it? If not, I can do it. > > Yep, I'm still up for it. I'd like to push out a new official release soon > but right now I'm still having problems with server 1.4. If input hotplug is > disabled, then it seems to work correctly, but with hotplug enabled, it seems > to be ignoring any attempts at altering mouse acceleration or button maps. As > far as I can tell, the app is doing the right thing (when you query state it > reflects your changes) but the server is not respecting the settings. I'd like > to get to the root of the problem before doing a release - in case updates to > the app are required. xinput is up. I added it to the build script etc. Please add yourself to docs/xorg-docs/MAINTAINERS. git://anongit.freedesktop.org/git/xorg/app/xinput Cheers, Peter From dberkholz at gentoo.org Wed Dec 19 21:58:20 2007 From: dberkholz at gentoo.org (Donnie Berkholz) Date: Wed, 19 Dec 2007 21:58:20 -0800 Subject: More about x-packages In-Reply-To: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> Message-ID: <20071220055820.GO24034@supernova> On 02:19 Wed 19 Dec , pcpa at mandriva.com.br wrote: > Now, about the system I am working on: > I am using a git mirror of freedesktop, where I use 3 main branches, and > modules also have branches with the same name. > mandriva Code that should be ok to add to mainstream > mandriva+custom Work in progress patches, or things that are not > considered mainstream quality, but fix some issue > in the distro > mandriva+gpl The distinction is due to the fact that GPL code currently > isn't accepted in main Xorg, and branch created to allow > easier integration of such patches/mods, and still keep > the repository in a format that allows easy pulling > for other people that want to make sure only a permissive > license is used. > Currently, I am experimenting with git-archive to generate a tarball, > and git-format-patch to generate the patches. The benefit is that it can > be automatized, and there is no need to store huge binary files, and only > files under version control enter the tarball. The bad side is that it is > something new, and you can find people that dislike it. I generate > tarball/patches to submit to a ``standard rpm build system''. In Gentoo, we use the upstream tarballs, verified by MD5/SHA1/etc, and add a set of patches, independently maintained in CVS. An improvement to our setup might store the patches with stgit or similar to ensure they're automatically ported across releases. I'm not (yet) convinced that maintaining our own repos and generating our own tarballs would lower the maintenance burden, since the number of patches we have against modular X is dramatically lower than the number we had with the old monolithic X (~10 vs 100+). Furthermore, almost all our patches make it upstream each release so there is no porting between releases. Thanks, Donnie From maciej.lozinski at impessa.com Thu Dec 20 02:59:12 2007 From: maciej.lozinski at impessa.com (=?UTF-8?B?TWFjaWVqIMWBb3ppxYRza2k=?=) Date: Thu, 20 Dec 2007 11:59:12 +0100 Subject: Problem with intel driver on laptop with 945GM chipset In-Reply-To: <200712190953.56768.jbarnes@virtuousgeek.org> References: <47694804.9030302@impessa.com> <200712190953.56768.jbarnes@virtuousgeek.org> Message-ID: <476A4B00.4090701@impessa.com> Jesse Barnes wrote: > On Wednesday, December 19, 2007 8:34 am Maciej ?ozi?ski wrote: > >> Hello all. >> >> I have a problem with setting up "intel" driver properly on my laptop. >> I'm using: >> Compaq nx7400 (EY611EA#AKD) laptop, >> 945GM chipset, >> GMA 950 graphics, >> Debian testing with kernel 2.6.22, >> xorg 7.2, >> Xfce 4.1, >> intel driver module version 2.2.0 >> >> The problem is that when I enable "intel" driver instead of "vesa" which >> was auto-detected during installation, and restart X, colors on my >> screen start to appear very strange, while in vesa they look ok. See how >> it looks like: >> http://picasaweb.google.com/loziniak/BrokenColorsInX >> > > Well the version on the intel side definitely doesn't look right... > > What's your configuration? Is this output on a TV? Is the program generating > the test images using OpenGL to do it? > > Jess I have no TV output. Pictures are taken from my laptop's LCD screen. They were generated from screenshots of gimp's color picker set on green, blue and red - not using opengl or something like this. Just plain jpg displayed fullscreen in gimp. From libv at skynet.be Thu Dec 20 02:08:19 2007 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 20 Dec 2007 11:08:19 +0100 Subject: VGA arbiter: removing RAC In-Reply-To: <21d7e9970712191913q3490681dm4d5dffbd3470d7f2@mail.gmail.com> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> <20071220014826.GA13238@skynet.be> <4769D01B.7040302@c3sl.ufpr.br> <20071220024748.GA13942@skynet.be> <21d7e9970712191913q3490681dm4d5dffbd3470d7f2@mail.gmail.com> Message-ID: <20071220100819.GA15652@skynet.be> On Thu, Dec 20, 2007 at 01:13:33PM +1000, Dave Airlie wrote: > > I wouldn't bother with backwards compat for this type of feature, > it'll need modifications to kernel side drivers as well.. > > This should only be targetted at upstream kernels and if later distros > need to backport it then they should do so.. > > Dave. Ok, so it is a feature, and no backwards compatibility is planned inside the module... This means that there will be runtime support for RAC for a long time still. Luc Verhaegen. SUSE/Novell X Driver Developer. From daniel at fooishbar.org Thu Dec 20 05:21:09 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 20 Dec 2007 15:21:09 +0200 Subject: xserver-kdrive, mouse, motion issues In-Reply-To: <1198102568.3447.20.camel@linuxserver.digital> References: <1197997118.14968.27.camel@linuxserver.digital> <1198102568.3447.20.camel@linuxserver.digital> Message-ID: <20071220132109.GJ2846@fooishbar.org> On Wed, Dec 19, 2007 at 04:16:08PM -0600, christopher reder wrote: > Perhaps an easier question would be if anyone could tell me where the > read/modify/write is done for things like a mouse pointer and if it is > possible to force that read/modify/write to be executed through a > function in the kernel. You can use libwfb to have a custom function called every time a read from or write to the framebuffer is made. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From daniel at fooishbar.org Thu Dec 20 05:22:11 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 20 Dec 2007 15:22:11 +0200 Subject: About some git repositories In-Reply-To: References: <20071219003951.44gq2rvgejdcssog@webmail.conectiva.com.br> Message-ID: <20071220132211.GK2846@fooishbar.org> On Wed, Dec 19, 2007 at 04:05:34PM -0600, Jeremy C. Reed wrote: > How is this fixed in git history to show the correct person's name and > email address? (It is in the ChangeLog.) It isn't. You don't rewrite history, full stop. > And does git have some configuration to disallow an Author named "root"? Yes, the hook could be pretty trivially fixed. > I read that another popular open source project was compromised by an > attacker who used a committer's compromised account. This is nothing to do with a compromise. It's just people who, for some reason, do _everything_ as root. Including coding and committing. I believe the evdev driver has some commits as root, too. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From eich at suse.de Thu Dec 20 05:38:45 2007 From: eich at suse.de (Egbert Eich) Date: Thu, 20 Dec 2007 14:38:45 +0100 Subject: VGA arbiter: removing RAC In-Reply-To: vignatti@c3sl.ufpr.br wrote on Wednesday, 19 December 2007 at 22:43:58 -0200 References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> Message-ID: <18282.28773.32601.996308@hermes.suse.de> Tiago Vignatti writes: > Joerg Sonnenberger escreveu: > > On Wed, Dec 19, 2007 at 08:45:53PM -0200, Tiago Vignatti wrote: > >> The Resource Access Control inside Xorg is the guy responsible to take > >> care of the various resources of memory and to share them in a wise > >> manner when two or more graphics devices are active (think multi-head). > >> As an alternative from RAC we can rely on VGA arbiter. > > > > How much work is the kernel part of the arbiter? You know, the Xserver > > is not only used on Linux :-) > > git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git > > for more info about the code, please see > http://lists.freedesktop.org/archives/xorg/2007-November/030420.html > > And yes, unfortunately we will need to keep the RAC module together with > the VGA arbiter inside Xorg for some time due the portability of Xorg. > Probably let autoconf set if Xorg needs RAC or the arbiter depending the > OS would be fine and easy to do. Why unfortunately? I would think it should be possible to share a lot of code between the DDX part that deals with the arbiter and RAC itself. A lot of ideas that went into RAC have not been implemented in the arbiter. The arbiter takes care of resource enabling and disabling and acts as a broker between different processes - the latter is something the broker inside the Xserver cannot do. This however is not all of RAC. The code in the Xserver decides which resources actually need to be disabled depending on if the device actually decodes VGA or not. VGA decoding can be disabled on some devices while they will still identify themselves as VGA devices in PCI config space - so this is something the driver has to set. Furthermore it decides if VGA resources are actually needed for a specific operation. This provides the opportunity for a lot of optimization. For platforms that don't provide an arbiter inside the kernel a comparable functionality could be put into a user land broker. I may have missed where the DDX bits of this VGA arbiter are developed. Cheers, Egbert. From remi at gentoo.org Thu Dec 20 05:55:27 2007 From: remi at gentoo.org (=?ISO-8859-1?Q?R=E9mi_Cardona?=) Date: Thu, 20 Dec 2007 14:55:27 +0100 Subject: More about x-packages In-Reply-To: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> Message-ID: <476A744F.6000202@gentoo.org> pcpa at mandriva.com.br a ?crit : > Currently, I am experimenting with git-archive to generate a tarball, > and git-format-patch to generate the patches. What's wrong with using make distcheck? To me it's one of the major benefits of using autotools in the first place. Cheers, R?mi From pcpa at mandriva.com.br Thu Dec 20 06:35:46 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Thu, 20 Dec 2007 12:35:46 -0200 Subject: More about x-packages In-Reply-To: <476A744F.6000202@gentoo.org> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> Message-ID: <476A7DC2.4020306@mandriva.com.br> R?mi Cardona wrote: > pcpa at mandriva.com.br a ?crit : > >> Currently, I am experimenting with git-archive to generate a tarball, >> and git-format-patch to generate the patches. > > What's wrong with using make distcheck? To me it's one of the major > benefits of using autotools in the first place. I have nothing agains't distcheck. But at the moment, it is also adding some generated files to the tarball, the X Server packages increases, after bz2'ed by around 2MB, but still this isn't the major issue, as I believe it could be fixed, if considered wrong, in "make distcheck" itself. I am experiencing with managing releases by adding local tags, and having local patches in local git branches. So, using git-archive and git-format-patch seens a natural/automatable approach to generate data that is submited to a build system. The major drawback is that usually tarballs from trusted sites come with a mdsum/sha/whatever authentication, and I experienced some oposition here, so this is still an experiment, and I may still move back to storing binary tarballs, but I still want to have local patches in git, instead of generating and mantaining them "by hand". > > Cheers, > > R?mi > Paulo From dparsons at debian.org Thu Dec 20 06:51:38 2007 From: dparsons at debian.org (Drew Parsons) Date: Fri, 21 Dec 2007 01:51:38 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1198118446.2887.5.camel@monteirov> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> <1198105801.6348.9.camel@localhost.localdomain> <1198118446.2887.5.camel@monteirov> Message-ID: <1198162298.6348.15.camel@localhost.localdomain> On Thu, 2007-12-20 at 02:40 +0000, Sergio Monteiro Basto wrote: > On Thu, 2007-12-20 at 10:10 +1100, Drew Parsons wrote: > > I thought this must mean we had a clear regression in intel 2.2, since > > I > > reported the ghosting problem had been fixed in 2.1. But I checked, > > and > > distressingly that problem is back again, even after downgrading back > > to > > intel 2.1.1 and linux 2.6.22. I didn't downgrade mesa or xserver, > > which > > are now slightly higher versions than on 6 Nov when I had S3 success. > > 2.6.22. > > Hey , I ( talk by me ) , or you use xserver 1.4 branch, with mesa 7_0 > branch , and libdrm 2.3.0 released with kernel>= 2.6.22 ( or 21) > which means xserver 1.4.0.90 and mesa 7.0.2 , or we can't talk about > Intel drives issues , but Xorg issues. > Using Xserver git => using Mesa git which => using libdrm git which => > update drm kernel modules Hi Sergio, do you mean that, when using git for everything, you have a consistently successful suspend/resume on an intel 855 chip? Drew From pcpa at mandriva.com.br Thu Dec 20 07:02:32 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Thu, 20 Dec 2007 13:02:32 -0200 Subject: More about x-packages In-Reply-To: <20071220055820.GO24034@supernova> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <20071220055820.GO24034@supernova> Message-ID: <476A8408.805@mandriva.com.br> Donnie Berkholz wrote: > On 02:19 Wed 19 Dec , pcpa at mandriva.com.br wrote: >> Now, about the system I am working on: >> I am using a git mirror of freedesktop, where I use 3 main branches, and >> modules also have branches with the same name. >> mandriva Code that should be ok to add to mainstream >> mandriva+custom Work in progress patches, or things that are not >> considered mainstream quality, but fix some issue >> in the distro >> mandriva+gpl The distinction is due to the fact that GPL code currently >> isn't accepted in main Xorg, and branch created to allow >> easier integration of such patches/mods, and still keep >> the repository in a format that allows easy pulling >> for other people that want to make sure only a permissive >> license is used. >> Currently, I am experimenting with git-archive to generate a tarball, >> and git-format-patch to generate the patches. The benefit is that it can >> be automatized, and there is no need to store huge binary files, and only >> files under version control enter the tarball. The bad side is that it is >> something new, and you can find people that dislike it. I generate >> tarball/patches to submit to a ``standard rpm build system''. > > In Gentoo, we use the upstream tarballs, verified by MD5/SHA1/etc, and > add a set of patches, independently maintained in CVS. An improvement to > our setup might store the patches with stgit or similar to ensure > they're automatically ported across releases. I expect to have everything easy to adapt all the time, and if I get conflicts, should be minimal, so I could fix it in my computer before pushing to another "pseudo master" repository here. For example, in the mandriva+gpl branch, I have integrated the vnc patches, and a few other patches/scripts from Debian that are licensed under GPL, and soon, should have more GPL licensed code. While most of them are trivial, the vnc patch, currently is over 24K lines of patches, so keeping this integrated may avoid future headaches by needing to either drop it, or fix all the conflicts. Also of course, an easy way to "cherry-pick" patches from master to the stable branch, or any other cool git feature :-) > I'm not (yet) convinced that maintaining our own repos and generating > our own tarballs would lower the maintenance burden, since the number of > patches we have against modular X is dramatically lower than the number > we had with the old monolithic X (~10 vs 100+). Furthermore, almost all > our patches make it upstream each release so there is no porting between > releases. > Well, I don't have it fully implemented yet, neither "several month" of experience with this approach to tell about my experiences :-). This method requires some "baby sitting" by knowing what is going on, and updating the local git mirror, potentially fixing conflicts. But, unless a "0% maintenaince" approach of only donwloading/building upstram tarballs is used, I believe having git to store local modifications or confliciting ones like the GPL licensed code, will require a lot less work to maintain, and allow having almost everything automatized. > Thanks, > Donnie Paulo From ross at burtonini.com Thu Dec 20 06:52:54 2007 From: ross at burtonini.com (Ross Burton) Date: Thu, 20 Dec 2007 14:52:54 +0000 Subject: More about x-packages In-Reply-To: <476A7DC2.4020306@mandriva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> Message-ID: <1198162373.25977.14.camel@blackadder> On Thu, 2007-12-20 at 12:35 -0200, Paulo Cesar Pereira de Andrade wrote: > > What's wrong with using make distcheck? To me it's one of the major > > benefits of using autotools in the first place. > > I have nothing agains't distcheck. But at the moment, it is also adding > some generated files to the tarball, the X Server packages increases, after > bz2'ed by around 2MB, but still this isn't the major issue, as I believe > it could be fixed, if considered wrong, in "make distcheck" itself. By "generated files" do you mean configure, Makefile.in, and so on? If so, that is by design: if you don't include those you require that the person building the software has automake/autoconf/libtool installed. A tarball built with "make distcheck" can be installed with just sh and make, that's the entire point of autotools. ;) Ross -- Ross Burton mail: ross at burtonini.com jabber: ross at burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF From pcpa at mandriva.com.br Thu Dec 20 07:23:28 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Thu, 20 Dec 2007 13:23:28 -0200 Subject: More about x-packages In-Reply-To: <1198162373.25977.14.camel@blackadder> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> Message-ID: <476A88F0.40104@mandriva.com.br> Ross Burton wrote: > On Thu, 2007-12-20 at 12:35 -0200, Paulo Cesar Pereira de Andrade wrote: >>> What's wrong with using make distcheck? To me it's one of the major >>> benefits of using autotools in the first place. >> I have nothing agains't distcheck. But at the moment, it is also adding >> some generated files to the tarball, the X Server packages increases, after >> bz2'ed by around 2MB, but still this isn't the major issue, as I believe >> it could be fixed, if considered wrong, in "make distcheck" itself. > > By "generated files" do you mean configure, Makefile.in, and so on? If Yes, and I understand the concept of "auto" tools (well, understand a bit :-) > so, that is by design: if you don't include those you require that the > person building the software has automake/autoconf/libtool installed. A > tarball built with "make distcheck" can be installed with just sh and Unfortunatelly, at least for the moment, I am also regenerating some other files, so just after running configure, the x11-server.spec also runs: pushd include && make xorg-server.h dix-config.h xorg-config.h && popd But this is due to a patch I wrote, that is still not considered upstream quality, and allows killing clients/server if it is in an infinite loop somewhere, as it will handle keyboard events like mouse events, i.e. using sigio, but I may try to find another way to have the proper setup in the "xorg sdk". > make, that's the entire point of autotools. ;) > > Ross :-) Well, I expect that people that generate binaries from sources will care to install autotools, but I see the point of having the generated files, as it may take significant time to regenerate them, due to the extensive tests. For example, monolithic X Free86 would build everything in less than 20 minutes on an average P4, while modular Xorg will take a few hours, and most of the time is spent on autotools scripts. Paulo From macslow at bangang.de Thu Dec 20 08:03:36 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Thu, 20 Dec 2007 17:03:36 +0100 Subject: Using GLX_EXT_texture_from_pixmap for redirected rendering of widgets/windows. Message-ID: <1198166616.5726.36.camel@HAL9000> Greetings xorg/gtk+-crowd! I finally got that "gtk+-widgets _ontop_ of a GL-context" working and would like to get some input from anybody interested in the topic. Apart from toolkit-level input-redirection not working, which is likely another big chunk of work to design and implement, I am mainly interested in solving any possible GLXFBConfig-selection issues, people might run into. Sofar I've only successfully tested it under metacity/compiz on a GeForce-card and still battle to get it working on an i965. On the side of rendering-performance I feel that I am still missing some optimization in the way I do draw the widgets on quads, because of a slight CPU-hit I experience here (mapping such a small texture at a refresh of 20Hz or 60Hz should not be noticeable at all). The general approach used to get it going, is to stuff the widget(s), which are loaded in from a glade-description, in a GtkEventBox, use gdk_window_set_composited() on the GtkEventBox to redirect it to an offscreen pixmap, select a matching GLXFBConfig derived from the top-level GtkWindow and use GLX_EXT_texture_from_pixmap to finally obtain a GL-texture from the widgets pixmap. All this is then drawn with GL right into the top-level GtkWindow. A screenshot of the examples running... http://macslow.thepimp.net/shots/gtk-examples-1.png The source to the examples can be grabbed with... bzr branch http://bazaar.launchpad.net/~macslow/gtk-offscreen-1/trunk gtk-offscreen-1 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-1/trunk gtk-gl-offscreen-1 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-2/trunk gtk-gl-offscreen-2 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-rgba-1/trunk gtk-gl-rgba-1 Thanks in advance! Best regards... Mirco "MacSlow" M?ller From harryrat at postnuklear.de Thu Dec 20 08:15:20 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Thu, 20 Dec 2007 17:15:20 +0100 Subject: kdrive rotation problems Message-ID: <200712201715.20642.harryrat@postnuklear.de> >Using X11R7.3 X.org release, I experienced the following issue. >Everything works fine if I run the server with: >Xfbdev -keybd keyboard,device=/dev/input/event1 -mouse >tslib,,device=/dev/input/event0 >Instead, when I rotate the screen with: >Xfbdev -screen 240x320 at 90 -keybd keyboard,device=/dev/input/event1 >-mouse tslib,,device=/dev/input/event0 >The Y coordinate is correctly managed, while the X remains stuck at >0... Same problem here (Xorg-1.4.0 kdrive server Xfbdev) ... I had a quick look into the code, I think this happens in src/kinput.c KdEnqueuePointerEvent(). Here, the transformation matrix is applied to the coords, swapping coords if necessary (depending on rotation) and then basically queued as events. In case of a rotation of 90 degs -> x = -ry, which I guess is clipped to 0 later on in GetPointerEvents() (dix/getevents.c), thus resulting in zeroing the x-axis.... Basically I guess besides applying the matrix on the coords, depending on coords < 0 the max axis values have to be added to yield correctly transformed coords I just started to look into xserver code, so apologies if I am totally wrong! Greez, Harry PS: first posting here, plz be gentle with an old newbie (: From remi at gentoo.org Thu Dec 20 08:24:39 2007 From: remi at gentoo.org (=?UTF-8?B?UsOpbWkgQ2FyZG9uYQ==?=) Date: Thu, 20 Dec 2007 17:24:39 +0100 Subject: Using GLX_EXT_texture_from_pixmap for redirected rendering of widgets/windows. In-Reply-To: <1198166616.5726.36.camel@HAL9000> References: <1198166616.5726.36.camel@HAL9000> Message-ID: <476A9747.1040105@gentoo.org> Mirco M?ller a ?crit : > Greetings xorg/gtk+-crowd! > > I finally got that "gtk+-widgets _ontop_ of a GL-context" working and > would like to get some input from anybody interested in the topic. I saw your blog post this morning, it's very cool :) > Apart from toolkit-level input-redirection not working, which is likely > another big chunk of work to design and implement, I am mainly > interested in solving any possible GLXFBConfig-selection issues, people > might run into. Sofar I've only successfully tested it under > metacity/compiz on a GeForce-card and still battle to get it working on > an i965. I'm also interested in this. I'm working on making Metisse work with XComposite and GLX_EXT_texture_from_pixmap and so far, I'm having trouble find simple code that actually works. Your examples come at the perfect time :) I'll let you know if I find anything that could help. Cheers -- R?mi Cardona LRI, Universit? Paris-Sud remi.cardona at lri.fr remi at gentoo.org From harryrat at postnuklear.de Thu Dec 20 08:34:48 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Thu, 20 Dec 2007 17:34:48 +0100 Subject: kdrive rotation problems In-Reply-To: <200712201715.20642.harryrat@postnuklear.de> References: <200712201715.20642.harryrat@postnuklear.de> Message-ID: <200712201734.49119.harryrat@postnuklear.de> > > Basically I guess besides applying the matrix on the coords, depending on > coords < 0 the max axis values have to be added to yield correctly > transformed coords concrete: in hw/kdrive/src/kinput.c KdEnqueuePointerEvent(KdPointerInfo *pi, unsigned long flags, int rx, int ry, int rz) Adding: if (x < 0) x += matrix[0][2]; if (y < 0) y += matrix[1][2]; right after: z=rz; corrected the prob for me Greez, Harry From harryrat at postnuklear.de Thu Dec 20 09:38:12 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Thu, 20 Dec 2007 18:38:12 +0100 Subject: Kdrive - touchscreen - long touch == button 3? Message-ID: <200712201838.13133.harryrat@postnuklear.de> Hi! Is there no support for "long touch" as button 3 events in the current kdrive version? I googled a bit and found a posting from 2004 but couldn't find any reference in the 1.4.0 sources Thx for any hints Harry From irwin at beluga.phys.uvic.ca Thu Dec 20 10:06:53 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 20 Dec 2007 10:06:53 -0800 (PST) Subject: CMake (was More about x-packages) In-Reply-To: <476A88F0.40104@mandriva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> Message-ID: On 2007-12-20 13:23-0200 Paulo Cesar Pereira de Andrade wrote: > :-) Well, I expect that people that generate binaries from sources will > care to install autotools, but I see the point of having the generated > files, as it may take significant time to regenerate them, due to the > extensive tests. For example, monolithic X Free86 would build everything > in less than 20 minutes on an average P4, while modular Xorg will take > a few hours, and most of the time is spent on autotools scripts. You will get some substantial speed improvements if you move to a different build system. At least that is what KDE experienced when they moved from autotools to CMake, and that was the PLplot developer's experience as as well when we moved PLplot from autotools to CMake. The configuration speed improvements are because cmake is a fast executable that takes the place of the relatively slow configure script. There are also build speed improvements which I ascribe to the cmake executable setting up straightforward Makefile rules to do compiling and linking while autotools uses libtool, a ~220K (!) script that must be run for every compile or link step. Another advantage of CMake is it is quite easy to understand so that build-system support tends to be more widespread within a software project rather than relying on one or two gurus to actually understand autotools. That was a big deal for me because in the past I did spend a lot of time implementing autotools support for new PLplot features or attempting to debug autotools build problems for PLplot. I was tired of that effort. I am well aware that X changed to the autotools build system not that long in the past, and most X developers are probably not immediately ready for yet another such transition. In fact, if the PLplot experience can be generalized there will be a tremendous amount of initial nay-saying with virtually all of it based on no experience with CMake! However, if just one forward-thinking X developer is concerned enough about the slow autotools configure and build speeds or the amount of autotools "magic" that is required to support new X features, then I suggest they try developing a CMake-based build system for just part of X (at first) to see how they like it for their own builds. From such a start it is relatively easy to go the rest of the way to a full-blown CMake-based build system that everybody can use. CMake-based build systems can be developed in parallel with autotools because there are no filename name clashes between the two build systems. When we tried that approach for PLplot there was only one downside; our team of developers (despite the initial nay-saying) caught on so fast to using CMake that all our new features over the last year have only been implemented in our CMake-based build system. That was the death knell of our autotools-based build system, and we have just now completely removed it as a result. The PLplot developers have collected links at http://www.miscdebris.net/plplot_wiki/index.php?title=General_CMake_documentation_links which we have found useful during the development of our new CMake-based build system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From daniel at fooishbar.org Thu Dec 20 10:33:38 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 20 Dec 2007 20:33:38 +0200 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <200712201838.13133.harryrat@postnuklear.de> References: <200712201838.13133.harryrat@postnuklear.de> Message-ID: <20071220183338.GM2846@fooishbar.org> On Thu, Dec 20, 2007 at 06:38:12PM +0100, Harald Radke wrote: > Is there no support for "long touch" as button 3 events in the current kdrive > version? I googled a bit and found a posting from 2004 but couldn't find any > reference in the 1.4.0 sources No -- you'll really have to implement this in your toolkit, cf. Maemo GTK's tap and hold. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ross at burtonini.com Thu Dec 20 10:17:07 2007 From: ross at burtonini.com (Ross Burton) Date: Thu, 20 Dec 2007 18:17:07 +0000 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <200712201838.13133.harryrat@postnuklear.de> References: <200712201838.13133.harryrat@postnuklear.de> Message-ID: <1198174627.6426.2.camel@blackadder> On Thu, 2007-12-20 at 18:38 +0100, Harald Radke wrote: > Is there no support for "long touch" as button 3 events in the current kdrive > version? I googled a bit and found a posting from 2004 but couldn't find any > reference in the 1.4.0 sources No. If you use GTK+, then maemo's GTK+ has support for something similar (it emits a signal) so you can steal their patch (I believe they are being integrated currently, so you'll want to check GTK+ bugzilla for patches first), and OpenEmbedded/Poky contain "libgtkstylus" which can will intercept long presses and turn them into button 3. Ross -- Ross Burton mail: ross at burtonini.com jabber: ross at burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF From harryrat at postnuklear.de Thu Dec 20 10:44:55 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Thu, 20 Dec 2007 19:44:55 +0100 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <1198174627.6426.2.camel@blackadder> References: <200712201838.13133.harryrat@postnuklear.de> <1198174627.6426.2.camel@blackadder> Message-ID: <200712201944.55285.harryrat@postnuklear.de> Thx for ur quick answers... hm, I guess I will rather patch kdrive to support it since it makes more sense to implement this low level than doin this over and over again for every GUI toolkit, just as it is for emulate 3 buttons for mouse Harry From ajax at nwnk.net Thu Dec 20 12:03:34 2007 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 20 Dec 2007 15:03:34 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping In-Reply-To: <200712181351.01176.peter.harris@hummingbird.com> References: <200712181351.01176.peter.harris@hummingbird.com> Message-ID: <1198181014.30771.290.camel@localhost.localdomain> On Tue, 2007-12-18 at 13:51 -0500, Peter Harris wrote: > From a4600733ef46585df5481923b8eedffe922c23dc Mon Sep 17 00:00:00 2001 > From: Peter Harris > Date: Tue, 18 Dec 2007 13:14:07 -0500 > Subject: [PATCH] Fix panoramiX request and reply swapping > > --- > > Resending, this time with the correct subject line. > > My previous patch missed replies, and also missed the RandR panoramiX > emulation layer. This patch fixes those omissions. > > I noticed while creating this patch that the reference server does not set > rep.window anywhere. Should I send another patch to fix that omission (or > amend this patch)? Amend this patch would be best. Patch looks good otherwise, nice catch. - ajax -------------- 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 peter.harris at hummingbird.com Thu Dec 20 13:44:37 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Thu, 20 Dec 2007 16:44:37 -0500 Subject: [PATCH 0/2] Fix panoramiX request and reply swapping Message-ID: <200712201644.37317.peter.harris@hummingbird.com> Here is the updated patch to fix panoramiX swapping. Patch 1/2 replaces the patch I sent to this list on Dec 18, 2007. It now also sets rep.window and rep.screen. While I was creating the patch, I noticed that the RandR Xinerama emulation layer returns funny values in GetScreenSize. Patch 2/2 changes the values returned by ProcRRXineramaGetScreenSize. Because I am not using the new RandR yet, I have not been able to test this change. Since it is less obvious than 1/1, in addition to being untested, I have left it as a separate patch to make it easier for you to ignore. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From peter.harris at hummingbird.com Thu Dec 20 13:44:39 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Thu, 20 Dec 2007 16:44:39 -0500 Subject: [PATCH 1/2] Fix panoramiX request and reply swapping Message-ID: <200712201644.39205.peter.harris@hummingbird.com> From 2188de17e8dea5141d9af4fda3176a8c97bf7ac6 Mon Sep 17 00:00:00 2001 From: Peter Harris Date: Thu, 20 Dec 2007 15:58:01 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping Fix panoramiX request and reply swapping Set window and screen values in panoramix replies Prevent buffer overrun in ProcPanoramiXGetScreenSize --- Xext/panoramiX.c | 17 +++++++++++++---- randr/rrxinerama.c | 18 ++++++++++++++---- 2 files changed, 27 insertions(+), 8 deletions(-) diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c index 311a8e7..1e25a5a 100644 --- a/Xext/panoramiX.c +++ b/Xext/panoramiX.c @@ -917,10 +917,11 @@ ProcPanoramiXGetState(ClientPtr client) rep.length = 0; rep.sequenceNumber = client->sequence; rep.state = !noPanoramiXExtension; + rep.window = stuff->window; if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetStateReply), (char *) &rep); return client->noClientException; @@ -944,10 +945,11 @@ ProcPanoramiXGetScreenCount(ClientPtr client) rep.length = 0; rep.sequenceNumber = client->sequence; rep.ScreenCount = PanoramiXNumScreens; + rep.window = stuff->window; if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.ScreenCount, n); + swapl (&rep.window, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenCountReply), (char *) &rep); return client->noClientException; @@ -961,6 +963,9 @@ ProcPanoramiXGetScreenSize(ClientPtr client) xPanoramiXGetScreenSizeReply rep; register int n, rc; + if (stuff->screen >= PanoramiXNumScreens) + return BadMatch; + REQUEST_SIZE_MATCH(xPanoramiXGetScreenSizeReq); rc = dixLookupWindow(&pWin, stuff->window, client, DixUnknownAccess); if (rc != Success) @@ -972,11 +977,15 @@ ProcPanoramiXGetScreenSize(ClientPtr client) /* screen dimensions */ rep.width = panoramiXdataPtr[stuff->screen].width; rep.height = panoramiXdataPtr[stuff->screen].height; + rep.window = stuff->window; + rep.screen = stuff->screen; if (client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.width, n); - swaps (&rep.height, n); + swapl (&rep.width, n); + swapl (&rep.height, n); + swapl (&rep.window, n); + swapl (&rep.screen, n); } WriteToClient (client, sizeof (xPanoramiXGetScreenSizeReply), (char *) &rep); return client->noClientException; diff --git a/randr/rrxinerama.c b/randr/rrxinerama.c index 896f61f..16028fe 100644 --- a/randr/rrxinerama.c +++ b/randr/rrxinerama.c @@ -138,10 +138,11 @@ ProcRRXineramaGetState(ClientPtr client) rep.length = 0; rep.sequenceNumber = client->sequence; rep.state = active; + rep.window = stuff->window; if(client->swapped) { swaps (&rep.sequenceNumber, n); swapl (&rep.length, n); - swaps (&rep.state, n); + swapl (&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetStateReply), (char *)&rep); return client->noClientException; @@ -192,10 +193,11 @@ ProcRRXineramaGetScreenCount(ClientPtr client) rep.length = 0; rep.sequenceNumber = client->sequence; rep.ScreenCount = RRXineramaScreenCount (pWin->drawable.pScreen); + rep.window = stuff->window; if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.ScreenCount, n); + swapl(&rep.window, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenCountReply), (char *)&rep); return client->noClientException; @@ -223,11 +225,15 @@ ProcRRXineramaGetScreenSize(ClientPtr client) rep.sequenceNumber = client->sequence; rep.width = pRoot->drawable.width; rep.height = pRoot->drawable.height; + rep.window = stuff->window; + rep.screen = stuff->screen; if(client->swapped) { swaps(&rep.sequenceNumber, n); swapl(&rep.length, n); - swaps(&rep.width, n); - swaps(&rep.height, n); + swapl(&rep.width, n); + swapl(&rep.height, n); + swapl(&rep.window, n); + swapl(&rep.screen, n); } WriteToClient(client, sizeof(xPanoramiXGetScreenSizeReply), (char *)&rep); return client->noClientException; @@ -351,6 +357,7 @@ SProcRRXineramaGetState(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetStateReq); + swapl (&stuff->window, n); return ProcRRXineramaGetState(client); } @@ -361,6 +368,7 @@ SProcRRXineramaGetScreenCount(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenCountReq); + swapl (&stuff->window, n); return ProcRRXineramaGetScreenCount(client); } @@ -371,6 +379,8 @@ SProcRRXineramaGetScreenSize(ClientPtr client) register int n; swaps (&stuff->length, n); REQUEST_SIZE_MATCH(xPanoramiXGetScreenSizeReq); + swapl (&stuff->window, n); + swapl (&stuff->screen, n); return ProcRRXineramaGetScreenSize(client); } -- 1.5.3.7 -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From peter.harris at hummingbird.com Thu Dec 20 13:44:40 2007 From: peter.harris at hummingbird.com (Peter Harris) Date: Thu, 20 Dec 2007 16:44:40 -0500 Subject: [PATCH 2/2] Fix panoramiX request and reply swapping Message-ID: <200712201644.40785.peter.harris@hummingbird.com> From 66190149a51cd1925ce88dabe32fdd49c45924c8 Mon Sep 17 00:00:00 2001 From: Peter Harris Date: Thu, 20 Dec 2007 16:25:54 -0500 Subject: [PATCH] Fix panoramiX request and reply swapping Fix ProcRRXineramaGetScreenSize to be more like ProcRRXineramaQueryScreens --- I have not tested this patch. Please do not apply before testing, or at least reviewing in detail. randr/rrxinerama.c | 29 +++++++++++++++++++++++++---- 1 files changed, 25 insertions(+), 4 deletions(-) diff --git a/randr/rrxinerama.c b/randr/rrxinerama.c index 16028fe..2c7e1ed 100644 --- a/randr/rrxinerama.c +++ b/randr/rrxinerama.c @@ -207,7 +207,7 @@ int ProcRRXineramaGetScreenSize(ClientPtr client) { REQUEST(xPanoramiXGetScreenSizeReq); - WindowPtr pWin, pRoot; + WindowPtr pWin; ScreenPtr pScreen; xPanoramiXGetScreenSizeReply rep; register int n, rc; @@ -218,13 +218,34 @@ ProcRRXineramaGetScreenSize(ClientPtr client) return rc; pScreen = pWin->drawable.pScreen; - pRoot = WindowTable[pScreen->myNum]; + if (RRXineramaScreenActive (pScreen)) + { + rrScrPriv(pScreen); + if (pScrPriv->numCrtcs == 0 || pScrPriv->numOutputs == 0) + RRGetInfo (pScreen); + } + if (stuff->screen >= RRXineramaScreenCount (pScreen)) + return BadMatch; + rep.type = X_Reply; rep.length = 0; rep.sequenceNumber = client->sequence; - rep.width = pRoot->drawable.width; - rep.height = pRoot->drawable.height; + rep.width = 0; + rep.height = 0; + { + RRCrtcPtr crtc; + rrScrPriv(pScreen); + crtc = pScrPriv->crtcs[stuff->screen]; + + if (RRXineramaCrtcActive (crtc)) + { + int width, height; + RRCrtcGetScanoutSize (crtc, &width, &height); + rep.width = width; + rep.height = height; + } + } rep.window = stuff->window; rep.screen = stuff->screen; if(client->swapped) { -- 1.5.3.7 -- Hummingbird Connectivity - A Division of Open Text Peter Harris http://connectivity.hummingbird.com Research and Development Phone: +1 905 762 6001 peter.harris at hummingbird.com Toll Free: 1 877 359 4866 From alexdeucher at gmail.com Thu Dec 20 15:24:53 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Thu, 20 Dec 2007 18:24:53 -0500 Subject: [ANNOUNCE] xf86-video-ati 6.7.197 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another RC release. Lots of stuff fixed and new features. See the changelog for more. Highlights: - - improved pll handling - - better lid support on Linux via acpi - - EXA transforms are fixed so rotation is fast with EXA on r1xx/r2xx - - improved Mac support for more cards - - cursor rotation problem are fixed - - better rn50 mode handling - - lots of bug fixes Adam Jackson (2): radeon: fix openoffice/render bug on r100 chips Fix RN50 mode filtering. Alex Deucher (26): Revert "Portability fix from netbsd" RADEON: Make sure we set the MT properly for connected status unknown RADEON: set proper defaults for tv dac BGADJ/DACADJ RADEON: fix typo in man page RADEON: only return status unknown for XPRESS chips RADEON: add MacModel "mini-internal" for minis with internal TMDS RADEON: rework MacModel option RADEON: add options for force TV out as detected and to set TV standard RADEON: add MacModel imac-g5-isight for iMac G5 iSight RADEON: bios PLL cleanup RADEON: only update crtc values when RMX is active RADEON: rewrite PLL computation RADEON: fix cursors when using rotation RADEON: use /proc/acpi to determine lid status RADEON: only enable vblanks if we want them RADEON: select fb_div0 for LVDS on RV410 (x700) mobility RADEON: Fix PLL set up on certain notebooks RADEON: Make sure LVDS_EN bit is set when enabling LVDS RADEON: more PLL fixes RADEON: whitespace clean-ups RADEON: add output enable masks RADEON: typo from last commit RADEON: add support for legacy radeons with DVI and no connector table RADEON: skip empty connectors when creating outputs RADEON: check for xf86_crtc_clip_video_helper() in configure.ac Bump for RC release Arkadiusz Miskiewicz (5): RADEON: fix backlight control on some laptops sparse fixes and cleanups from arekm RADEON: driver cleanups, warning fixes RADEON: more cleanups and warning fixes RADEON: fix fd leak in lid detect code Dave Airlie (2): radeon: restructure pci ids to avoid effort later Revert "Disable RENDER acceleration by default on some RV200 chips." Fredrik H?glund (1): RADEON: Fix the vertex coordinates for transformed pictures James Cloos (1): Add missing PHONY line for automatic ChangeLog generation Kusanagi Kouichi (1): radeon: Fix crash with XVideo 24bit RGB images. LisaWu (1): radeon: Use %u instead of %d for unsigned value. Michel D?nzer (5): Fix build against xserver master. radeon: Further XVideo fixes. radeon: Use gettimeofday instead of xf86getsecs. radeon: Warning fixes. radeon: Default to 1x again with non-v3 AGP cards. Roland Scheidegger (2): ignore sometime bogus agp_mode bit from chip (bug #13190) really do not set up surface regs for depth buf on r100-class igps (bug #13080) Stefan Dirsch (1): Disable RENDER acceleration by default on some RV200 chips. ?tienne Bersac (1): RADEON: fix typo git tag: xf86-video-ati-6.7.197 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.7.197.tar.bz2 MD5: 7bd53945ce6d0b48b7fd558039e82aa2 xf86-video-ati-6.7.197.tar.bz2 SHA1: 9ad752b5c6d7c6a708ce9e6b829e04cebda18203 xf86-video-ati-6.7.197.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.7.197.tar.gz MD5: 1f148527c334e8e3e134551a229c6a54 xf86-video-ati-6.7.197.tar.gz SHA1: e4e45ee1b7767e04284adcda691f503c563c4d7b xf86-video-ati-6.7.197.tar.gz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHavmKm07k+YR03kARAs4DAJ48aALlBzMUWVYGzrRQo9mMuEZ3yQCfcz7L z6UkbU+AodUvqaDA7DGvoWA= =aG1S -----END PGP SIGNATURE----- From joeprogrammer70 at gmail.com Thu Dec 20 16:52:21 2007 From: joeprogrammer70 at gmail.com (Joseph Alten) Date: Thu, 20 Dec 2007 16:52:21 -0800 Subject: Errors compiling xf86-video-intel on Debian 4.0 Message-ID: Hi, I'm trying to transfer my setup from a Gentoo system to a Debian one. My main problem at the moment is trying to get the xf86-video-intel driver to compile; it has a number of errors which I need help with. I've been following the guide here: http://ubuntuforums.org/showpost.php?p=2399695&postcount=102 When I try to actually compile xf86-video-intel, I get the following error: modes/xf86Modes.c: In function 'xf86ValidateModesBandwidth': modes/xf86Modes.c:512: error: 'MODE_BANDWIDTH' undeclared (first use in this function) The actual code it's choking on is this: for (mode = modeList; mode != NULL; mode = mode->next) { if (xf86ModeBandwidth(mode, depth) > bandwidth) mode->status = MODE_BANDWIDTH; } After a bit of grepping, it appears that MODE_BANDWIDTH is defined in xf86str.h, and so I tried (I can't remember the exact path) #include'ing the absolute path, but that didn't seem to help. Finally I just commented out the if() statement to see if it would compile, but then I got further errors. modes/xf86Cursors.c: In function 'xf86_set_cursor_colors': modes/xf86Cursors.c:229: warning: implicit declaration of function 'dixLookupPri vate' modes/xf86Cursors.c:229: warning: nested extern declaration of 'dixLookupPrivate ' modes/xf86Cursors.c:229: error: 'struct _Cursor' has no member named 'devPrivate s' modes/xf86Cursors.c:230: warning: pointer/integer type mismatch in conditional e xpression modes/xf86Cursors.c: In function 'intel_xf86_reload_cursors': modes/xf86Cursors.c:616: error: 'struct _Cursor' has no member named 'devPrivate s' modes/xf86Cursors.c:616: warning: passing argument 2 of 'cursor_info- >LoadCursor Image' makes pointer from integer without a cast Thanks for helping. --Joe From ewalsh at tycho.nsa.gov Thu Dec 20 18:01:00 2007 From: ewalsh at tycho.nsa.gov (Eamon Walsh) Date: Thu, 20 Dec 2007 21:01:00 -0500 Subject: Errors compiling xf86-video-intel on Debian 4.0 In-Reply-To: References: Message-ID: <476B1E5C.3070009@tycho.nsa.gov> Joseph Alten wrote: > Hi, > > I'm trying to transfer my setup from a Gentoo system to a Debian one. > My main problem at the moment is trying to get the xf86-video-intel > driver to compile; it has a number of errors which I need help with. > I've been following the guide here: > http://ubuntuforums.org/showpost.php?p=2399695&postcount=102 > > When I try to actually compile xf86-video-intel, I get the following > error: > > modes/xf86Modes.c: In function 'xf86ValidateModesBandwidth': > modes/xf86Modes.c:512: error: 'MODE_BANDWIDTH' undeclared (first use > in this function) > > The actual code it's choking on is this: > > for (mode = modeList; mode != NULL; mode = mode->next) { > if (xf86ModeBandwidth(mode, depth) > bandwidth) > mode->status = MODE_BANDWIDTH; > } > > After a bit of grepping, it appears that MODE_BANDWIDTH is defined in > xf86str.h, and so I tried (I can't remember the exact path) > #include'ing the absolute path, but that didn't seem to help. Finally > I just commented out the if() statement to see if it would compile, > but then I got further errors. > I see xf86Modes.c including xf86Priv.h which includes xf86Privstr.h which includes xf86str.h. The MODE_BANDWIDTH constant was just introduced on Dec 13. The intel driver symlinks to a bunch of stuff in the X server, including xf86Modes.c and xf86Cursors.c and it looks like you have copies of those files that are more recent than the X server header files they are including. If you haven't built and installed the xserver package from git, I would recommend doing that. This step doesn't seem to be in the instructions you linked to. Hope this helps! > modes/xf86Cursors.c: In function 'xf86_set_cursor_colors': > modes/xf86Cursors.c:229: warning: implicit declaration of function > 'dixLookupPri vate' > modes/xf86Cursors.c:229: warning: nested extern declaration of > 'dixLookupPrivate ' > modes/xf86Cursors.c:229: error: 'struct _Cursor' has no member named > 'devPrivate s' > modes/xf86Cursors.c:230: warning: pointer/integer type mismatch in > conditional e xpression > modes/xf86Cursors.c: In function 'intel_xf86_reload_cursors': > modes/xf86Cursors.c:616: error: 'struct _Cursor' has no member named > 'devPrivate s' > modes/xf86Cursors.c:616: warning: passing argument 2 of 'cursor_info- > >LoadCursor Image' makes pointer from integer without a cast > > Thanks for helping. > > --Joe > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > > -- Eamon Walsh National Security Agency From sergio at sergiomb.no-ip.org Thu Dec 20 18:01:44 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Fri, 21 Dec 2007 02:01:44 +0000 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1198162298.6348.15.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> <1198105801.6348.9.camel@localhost.localdomain> <1198118446.2887.5.camel@monteirov> <1198162298.6348.15.camel@localhost.localdomain> Message-ID: <1198202504.4986.13.camel@monteirov> On Fri, 2007-12-21 at 01:51 +1100, Drew Parsons wrote: > Hi Sergio, do you mean that, when using git for everything, you have a > consistently successful suspend/resume on an intel 855 chip? No, I mean when we talking about: "Major stability issues with xf86-video-intel 2.2.0" , we should talk about compile video-drv with stable branch of xserver. and I mean if you are trying xserver from git, you need many thing from gits like Mesa and drm. About suspend/resume,I don't need a new drm or libdrm. I had some problem with kernel-2.6.22 that was fix on 2.6.23, but with 2.6.23 I had a regression on black-light. - hibernation works well. - suspend to ram, after resume, I had to go to console (ctrl+alt+F1) and return to X (ctrl+alt+F7), to get back the screen. My laptop is one hp-compaq nx6110, what is yours ? Regards, -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From wsun013 at gmail.com Thu Dec 20 18:36:44 2007 From: wsun013 at gmail.com (Wei-Tsun Sun) Date: Fri, 21 Dec 2007 15:36:44 +1300 Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today In-Reply-To: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> Message-ID: <20071221153644.64091709@KNIGHT> Any particular filed bug known ? Willie On Thu, 13 Dec 2007 14:40:37 +0100 (CET) Nicolas Mailhot wrote: > A lot of people seem to be hitting this bug with recent Xorg, > including with other video drivers (nv in my case) > > -- > Nicolas Mailhot From dparsons at debian.org Thu Dec 20 19:27:06 2007 From: dparsons at debian.org (Drew Parsons) Date: Fri, 21 Dec 2007 14:27:06 +1100 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1198202504.4986.13.camel@monteirov> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> <1198105801.6348.9.camel@localhost.localdomain> <1198118446.2887.5.camel@monteirov> <1198162298.6348.15.camel@localhost.localdomain> <1198202504.4986.13.camel@monteirov> Message-ID: <1198207626.6348.33.camel@localhost.localdomain> On Fri, 2007-12-21 at 02:01 +0000, Sergio Monteiro Basto wrote: > On Fri, 2007-12-21 at 01:51 +1100, Drew Parsons wrote: > > Hi Sergio, do you mean that, when using git for everything, you have a > > consistently successful suspend/resume on an intel 855 chip? > > No, I mean when we talking about: "Major stability issues with > xf86-video-intel 2.2.0" , we should talk about compile video-drv with > stable branch of xserver. > and I mean if you are trying xserver from git, you need many thing from > gits like Mesa and drm. > Ah OK. I'm using mostly-stable versions too (apart from specific commits cherry-picked from git), so we're doing the same thing there. For me mesa is way too scary to build straight from git ;) > About suspend/resume,I don't need a new drm or libdrm. I had some > problem with kernel-2.6.22 that was fix on 2.6.23, but with 2.6.23 I had > a regression on black-light. > - hibernation works well. > - suspend to ram, after resume, I had to go to console (ctrl+alt+F1) and > return to X (ctrl+alt+F7), to get back the screen. I haven't checked the backlight in detail so I don't know about that. Hibernation (S4 suspend-to-disk) works flawlessly for me too. S3 suspend-to-ram is the one I have problems with, going to console and back does not fix it for me. > My laptop is one hp-compaq nx6110, what is yours ? Mine is an IBM R51 Thinkpad with Intel(R) 855GME. Drew From rich at wittyname.com Thu Dec 20 19:58:38 2007 From: rich at wittyname.com (Rich Aycock) Date: Thu, 20 Dec 2007 19:58:38 -0800 Subject: Noisy picture with intel driver and DVI ADD2 card In-Reply-To: References: Message-ID: Alan W. Irwin wrote: > On 2007-12-16 19:05-0800 Rich Aycock wrote: > >> I've got an Intel G33 that I'm trying to hook up to my 720p DLP TV. I'm using >> an ADD2 card to output DVI to my Toshiba 42HM66 HDMI input. The picture >> comes up but there is a lot of noise (speckles bouncing around all over the >> TV) and occasional flickering. In the Xorg log I see this line: >> >> (EE) intel(0): First SDVO output reported failure to sync >> >> which I think is the source of the problem. When I use 640x480 intead of >> 1280x720 (720p) the picture is fine and I don't get that error above. I also >> hooked an LCD monitor up to it via DVI and it worked fine. I've used the DVI >> out on my cable box with this TV without problems. Any ideas of how to fix >> this, or is it just a buggy TV? >> >> I'm using v2.2.0 of the intel driver from Debian Unstable. I've attached my >> xorg.conf and Xorg.0.log. > > This issue may be related to bug 13399. There I reported a problem with my > g33 chipset without ADD2 card. I couldn't get the Debian unstable driver to > work at all (keyboard lockup + monitor in extreme power save mode) unless I > applied the i830-restore-pipeconf-fix.patch from bug #13196 to version > 2.2.0. So you might want to try that patch yourself. Thanks for the suggestion. I haven't had a lot of time the past few days, but I finally got around to testing this patch out and unfortunately it doesn't fix my problem. Rich From pcpa at mandriva.com.br Thu Dec 20 21:17:35 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Fri, 21 Dec 2007 03:17:35 -0200 Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> Message-ID: <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> Quoting "Alan W. Irwin" : [ Sorry, for quoting everything bellow, but it may be helpful for some people, as I find the information very valuable ] I have nothing agains't autotools, and maybe I had exagerated on "few hours" as I measured it only 2 or 3 times, but I know it is around 2 hours to rebuild all modules/xserver/apps/etc (i.e. around 6 times slower). I am not sure if people would want to switch to cmake at this point, maybe have some optimized setup so that most scripts are run only once, I believe someone was working on it (sorry for not even knowing all the details before this reply). Or maybe, switch back to imake, what may be considered a step backwards. And this is the kind of thing that will not make some people happy, i.e. people working on different projects that depend on the build system adopted by Xorg. Well, talking a bit more about "x packages", what I am considering (still without stoping to "think hard" about it :-) to generate dependencies, is a script that will evaluate the .deps/*.Po files, and store gathered information in a "x packager devel" package. But this is just about considering special cases like updating the X Server package and knowing if modules need to be rebuilt, i.e. if a new functionality is added only to the X Server, modules don't need to be repackaged; this ofcourse assumes modules need headers to know about symbols, but there are few things left that use some other method like "type punning", using something like LoaderSymbol("some-string"), etc. A possibly proper implementation would be to create some kind of type sign for every symbol, but this would mean running a parser with the same arguments as the compiler and that interprets them identically, what probably would be impractical and/or require way too much work. >> :-) Well, I expect that people that generate binaries from sources will >> care to install autotools, but I see the point of having the generated >> files, as it may take significant time to regenerate them, due to the >> extensive tests. For example, monolithic X Free86 would build everything >> in less than 20 minutes on an average P4, while modular Xorg will take >> a few hours, and most of the time is spent on autotools scripts. > > You will get some substantial speed improvements if you move to a different > build system. At least that is what KDE experienced when they moved from > autotools to CMake, and that was the PLplot developer's experience as as > well when we moved PLplot from autotools to CMake. The configuration speed > improvements are because cmake is a fast executable that takes the place of > the relatively slow configure script. There are also build speed > improvements which I ascribe to the cmake executable setting up > straightforward Makefile rules to do compiling and linking while autotools > uses libtool, a ~220K (!) script that must be run for every compile or link > step. > > Another advantage of CMake is it is quite easy to understand so that > build-system support tends to be more widespread within a software project > rather than relying on one or two gurus to actually understand autotools. > That was a big deal for me because in the past I did spend a lot of time > implementing autotools support for new PLplot features or attempting to > debug autotools build problems for PLplot. I was tired of that effort. > > I am well aware that X changed to the autotools build system not that long > in the past, and most X developers are probably not immediately ready for > yet another such transition. In fact, if the PLplot experience can be > generalized there will be a tremendous amount of initial nay-saying with > virtually all of it based on no experience with CMake! However, if just one > forward-thinking X developer is concerned enough about the slow autotools > configure and build speeds or the amount of autotools "magic" that is > required to support new X features, then I suggest they try developing a > CMake-based build system for just part of X (at first) to see how they like > it for their own builds. From such a start it is relatively easy to go the > rest of the way to a full-blown CMake-based build system that everybody can > use. > > CMake-based build systems can be developed in parallel with autotools > because there are no filename name clashes between the two build systems. > When we tried that approach for PLplot there was only one downside; our team > of developers (despite the initial nay-saying) caught on so fast to using > CMake that all our new features over the last year have only been > implemented in our CMake-based build system. That was the death knell of our > autotools-based build system, and we have just now completely removed it as > a result. > > The PLplot developers have collected links at > http://www.miscdebris.net/plplot_wiki/index.php?title=General_CMake_documentation_links > which we have found useful during the development of our new CMake-based > build system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > From rglowery at exemail.com.au Thu Dec 20 23:49:10 2007 From: rglowery at exemail.com.au (Robert Lowery) Date: Fri, 21 Dec 2007 18:49:10 +1100 (EST) Subject: intel TVOut default margins Message-ID: <56373.220.233.174.242.1198223350.squirrel@webmail.exetel.com.au> The default margins in i830_tv.c give me a lot of black borders, particularly at the bottom of the screen. Is there any reason these values in particular were chosen as defaults? /* BIOS margin values */ dev_priv->margin[TV_MARGIN_LEFT] = 54; dev_priv->margin[TV_MARGIN_TOP] = 36; dev_priv->margin[TV_MARGIN_RIGHT] = 46; dev_priv->margin[TV_MARGIN_BOTTOM] = 37; I know xrandr can change them, the above values just seem a little strange to have as defaults. From nicolas.mailhot at laposte.net Fri Dec 21 01:21:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Dec 2007 10:21:07 +0100 Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today In-Reply-To: <20071221153644.64091709@KNIGHT> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> <20071221153644.64091709@KNIGHT> Message-ID: <1198228867.3126.48.camel@rousalka.dyndns.org> Le vendredi 21 d?cembre 2007 ? 15:36 +1300, Wei-Tsun Sun a ?crit : > Any particular filed bug known ? There is probably one somewhere, but I don't know it. I've seen the bug discussed several times in non-xorg technical irc channels, and didn't understood WTF people were talking about till I started hitting it too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From shrek at rescom.ru Fri Dec 21 03:56:55 2007 From: shrek at rescom.ru (Valery V. Inozemtsev) Date: Fri, 21 Dec 2007 14:56:55 +0300 Subject: [ANNOUNCE] xf86-video-ati 6.7.197 In-Reply-To: References: Message-ID: <200712211456.59656.shrek@rescom.ru> ? ????????? ?? 21 ??????? 2007 Alex Deucher ???????(a): > gpgkeys: key 9B4EE4F98474DE40 not found on keyserver > > Another RC release. Radeon Mobility M7 LW, ColorDepth = 16, Xv not work xorg-server-1.4.0.90 -- Valery V. Inozemtsev -------------- next part -------------- Section "ServerFlags" AllowMouseOpenFail Option "DontZap" Option "AIGLX" "true" Option "NoPM" "true" EndSection Section "InputDevice" Identifier "ThinkPad" Driver "kbd" # Driver "evdev" # Option "Device" "/dev/input/by-path/platform-i8042-serio-1-event-kbd" Option "AutoRepeat" "350 35" Option "XkbModel" "thinkpad" # Option "XkbModel" "evdev" Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys" Option "XkbOptions" "grp:caps_toggle,grp:switch" EndSection Section "InputDevice" Identifier "TrackPoint" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "EmulateWheel" "true" Option "EmulateWheelButton" "3" Option "EmulateWheelInertia" "10" Option "EmulateWheelTimeout" "200" EndSection Section "Module" Load "glx" Load "dri" SubSection "extmod" Option "omit xfree86-dga" EndSubSection EndSection Section "Monitor" Identifier "Flat Panel 1024x768" VendorName "IBM" ModelName "TP X24" DisplaySize 284 214 Option "DPMS" "on" EndSection Section "Device" Identifier "Radeon 7500" VendorName "ATI" BoardName "Radeon Mobility M7 LW" BusID "PCI:1:0:0" Option "BusType" "AGP" Driver "ati" Option "AGPMode" "4" # Option "AGPFastWrite" "true" Option "AccelMethod" "XAA" EndSection Section "Extensions" Option "Composite" "true" EndSection Section "DRI" Group "xgrp" Mode 0660 EndSection Section "Screen" Identifier "IBM" Device "Radeon 7500" Option "XaaNoOffscreenPixmaps" "true" # Option "XaaNoPixmapCache" "true" Monitor "Flat Panel 1024x768" DefaultColorDepth 16 Subsection "Display" Depth 32 Modes "1024x768" "800x600" "640x480" ViewPort 0 0 EndSubsection Subsection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" ViewPort 0 0 EndSubsection Subsection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" ViewPort 0 0 EndSubsection EndSection Section "ServerLayout" Identifier "ThinkPad T41" Screen "IBM" InputDevice "TrackPoint" "CorePointer" InputDevice "ThinkPad" "CoreKeyboard" EndSection -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mhopf at suse.de Fri Dec 21 08:22:20 2007 From: mhopf at suse.de (Matthias Hopf) Date: Fri, 21 Dec 2007 17:22:20 +0100 Subject: [ANNOUNCE] xf86-video-radeonhd 1.1.0 'Holiday Release' Message-ID: <20071221162219.GA13466@suse.de> Announcing the 'Holiday Release' of the xf86-video-radeonhd driver. RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx chipsets. The development is driven by Novell at the time of writing, together with a community of open source developers around this driver. AMD provides free documentation for the chipsets. Note the wiki on http://wiki.x.org/wiki/radeonhd Version 1.1.0 improvements: - Added Support for RS600, preliminary RV670. - Allows panning in RandR mode. - Preliminary (read: untested) support for HDMI connectors. - Now builds against the latest upstream X.Org code in git. - Lots of bugfixes, e.g. - Better monitor detection. - Gamma + palette fixes. - Mode stability + textmode restore. - RandR mode selection fixes. http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.1.0.tar.gz MD5: db0a1da9513aa9f3c3138966f2d75cf0 xf86-video-radeonhd-1.1.0.tar.gz SHA1: 63cde5afd0864b7bd7eb4151577e0fa620b3fe79 xf86-video-radeonhd-1.1.0.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.1.0.tar.bz2 MD5: ec31f738afd18da374e032e23ad08e21 xf86-video-radeonhd-1.1.0.tar.bz2 SHA1: 5553bbceafd80714c03a6c60479bd9bc9eacb63e xf86-video-radeonhd-1.1.0.tar.bz2 Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From alexdeucher at gmail.com Fri Dec 21 08:47:26 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 21 Dec 2007 11:47:26 -0500 Subject: [ANNOUNCE] xf86-video-ati 6.7.197 In-Reply-To: <200712211456.59656.shrek@rescom.ru> References: <200712211456.59656.shrek@rescom.ru> Message-ID: On Dec 21, 2007 6:56 AM, Valery V. Inozemtsev wrote: > ? ????????? ?? 21 ??????? 2007 Alex Deucher ???????(a): > > gpgkeys: key 9B4EE4F98474DE40 not found on keyserver > > > > Another RC release. > > Radeon Mobility M7 LW, ColorDepth = 16, Xv not work > xorg-server-1.4.0.90 Please file a bug (https://bugs.freedesktop.org) and attach your xorg config and log. Alex From jcristau at debian.org Fri Dec 21 09:28:17 2007 From: jcristau at debian.org (Julien Cristau) Date: Fri, 21 Dec 2007 18:28:17 +0100 Subject: More about x-packages In-Reply-To: <476A8408.805@mandriva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <20071220055820.GO24034@supernova> <476A8408.805@mandriva.com.br> Message-ID: <20071221172815.GA8689@patate.is-a-geek.org> On Thu, Dec 20, 2007 at 13:02:32 -0200, Paulo Cesar Pereira de Andrade wrote: > For example, in the mandriva+gpl branch, I have integrated the vnc > patches, > and a few other patches/scripts from Debian that are licensed under GPL, and > soon, should have more GPL licensed code. Hi, OOI, which ones of our patches are GPLed? Cheers, Julien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From irwin at beluga.phys.uvic.ca Fri Dec 21 10:29:26 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Dec 2007 10:29:26 -0800 (PST) Subject: CMake (was More about x-packages) In-Reply-To: <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> Message-ID: On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote: > I am not sure if people would want to switch to cmake at this point. I can assure you that at first most will not. :-) Developers tend to be scared of changes to the build system for their software. But worrying about that is premature. What you first need is a proof of concept. IOW, some motivated individual who builds X a lot could try CMake for himself to build some essential part of X to see how suitable it is for their own private X build needs. It is easy to try such proofs of concept because (a) CMake syntax is dead easy to understand, and (b) CMake and autotools files can peacefully coexist in the same source tree since there are no name clashes between them. If the proof of concept shows big promise (and I suspect it will), then others will want to join that developer in using and developing a CMake-based build system. That's exactly what happened in the PLplot case. After reading about the KDE success with CMake, I tried such a proof of concept for PLplot (just building our core plotting library and nothing else) out of curiosity. The proof of concept verified everything claimed for the KDE case; it gave a faster build with a much easier to understand build system compared to the equivalent autotools build. Therefore, I started expanding that proof of concept even though I was one of the autotools "gurus" for PLplot. Soon, other Plplot developers started helping me. PLplot has a relatively complex build with many internal components (various computer language bindings to our core C library, a complete test example suite for each computer language, many plot device dynamically loaded plug-ins, and a docbook-based documentation system) and many external library dependencies of those internal components. Despite this build complexity, within a relatively short time we had a complete CMake-based build system for PLplot that worked on Linux. Mac OS X, and windows (Cygwin, MinGW, and "bare" windows) success soon followed. (We have received no complaints from the *BSD packagers of PLplot so I assume it works there as well.) That build system peacefully coexisted with our autotools-based build system for a year and a half until we killed off the latter due to lack of interest. Our only big regret about the whole business was we didn't switch PLplot to CMake sooner. My only interest in X is as (an appreciative) user and bug reporter, and I have no deep understanding of the current X build. So I am not the guy to put together a CMake-based build system for X. However, if some X developer is interested, I have a lot of CMake experience I would be willing to share to help them get started or to overcome any problems they encounter. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From joerg at britannica.bec.de Fri Dec 21 10:48:18 2007 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Fri, 21 Dec 2007 19:48:18 +0100 Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> Message-ID: <20071221184818.GA29416@britannica.bec.de> On Fri, Dec 21, 2007 at 10:29:26AM -0800, Alan W. Irwin wrote: > On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote: > > > I am not sure if people would want to switch to cmake at this point. > > I can assure you that at first most will not. :-) Developers tend to be > scared of changes to the build system for their software. I am worried about requiring a huge piece of C++ software to build Xorg. Period. Joerg From daniel at fooishbar.org Fri Dec 21 12:09:40 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Fri, 21 Dec 2007 20:09:40 +0000 Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> Message-ID: <20071221200940.GA14359@fooishbar.org> On Fri, Dec 21, 2007 at 10:29:26AM -0800, Alan W. Irwin wrote: > On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote: > > I am not sure if people would want to switch to cmake at this point. > > I can assure you that at first most will not. :-) Developers tend to be > scared of changes to the build system for their software. But worrying > about that is premature. What you first need is a proof of concept. Personally (as the person who was the only one running a modular Xorg server for quite a while), I'm not scared -- I just fail to see any benefit. Can someone please explain it to me, beyond the libtool thing? I mean, if we're going to expend that much effort just to avoid libtool, we could instead fix it once and for all upstream. What am I missing? Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bart at cs.pdx.edu Fri Dec 21 12:36:22 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Fri, 21 Dec 2007 12:36:22 -0800 Subject: Election of X.Org Foundation Board Members is now open Message-ID: <200712212036.lBLKaMwU007910@wezen.cs.pdx.edu> I am happy to announce that the election for year 2008 positions on the X.Org Foundation Board of Directors is now officially open, and will remain open through 11:59 UTC Monday, December 31 2007. Only current X.Org Foundation Members in good standing are permitted to vote in this election; all such Members are encouraged to do so. You can vote by logging into https://members.x.org and selecting the button marked "cast" in the middle of the page. (If you don't see the "cast" button, try the "Ballot" button up top first.) Once a ballot is presented to you, you will be asked to rank the six candidates in the order 1 (most preferred) to 6 (least preferred). You do not have to place all six votes. You may select a given ranking only once (e.g., only place one vote of '2'). When you then press the vote button, your vote will then be permanently recorded---no change to a recorded ballot will be permitted. I would strongly urge you to complete your voting a few days before the election deadline if at all possible. It's the holidays, so responses to problems may take a little longer. If you have any problem voting, please send email to elections at x.org with a copy to me, bart at cs.pdx.edu, as soon as possible so that we can try to resolve the difficulty. There are six candidates for four positions this time around. I have attached information about each candidate, listing them in alphabetical order since that is the order in which they appear on the ballot. For each candidate, I have given their name, the "X.Org Member statement" indicating their involvement in X.Org and the X Window System, and the "Candidate statement" indicating their platform as a Board Member of the X.Org Foundation. If you have further questions for the candidates, please ask them on the members at x.org email list so that others can benefit from the responses. Thank you for your support of the X.Org Foundation and its work with the X Window System. Sincerely, Bart Massey Election Committee X.Org Foundation Board bart at cs.pdx.edu -------------- next part -------------- Stuart Anderson Member Statement: Multiple contributions to X11R6/XFree86. Current Board member. Candidate Statement: It's official. I've become one of those old guys. This year marked the 20th anniversary of the first time I hacked on the X Window System. Fortunately, though, I'm still writing code on a daily basis. When I haven't been hacking on code, I've had the opportunity to be gaining experience in other areas, like how to run a business (and sometimes how not to run one), and how to build consesus among competitors, etc. It's this balance of skills that I have been bringing to the Board during my past terms. Philosophicaly, I believe that X.Org exists to support the community, and not control it. X.Org should be looking for ways to help facilitate progress on advancing the X Window System, and staying out of the way when it doesn't have anything to contribute. We have made a lot of progress over the past few years since the creation of the X.Org Foundation, but there are still a few things that we need to continue to improve upon. If elected for another term, I will continue to focus on making the changes and implementing the processes that will ensure the long term viability of the X.Org Foundation so that it can continue to support the community that is advancing the technology. ---- Eric Anholt Member Statement: My role in X.Org has largely been as a developer, including contributions to the EXA acceleration architecture, RandR 1.2 development, and developing native Intel modesetting. Candidate Statement: I have been pleased with the relatively minor, supportive role that the X.Org Board has taken since X.Org's rebirth in 2004. Continuing to allow X.Org technical direction to be led by the active developers is key to our success. On the X.Org board, my goal would be to encourage the use of X.Org board funds for appropriate activities. Our latest XDS and XDC conferences have been great successes at improving communication between the developers and promoting cooperation. I want to see that continue, with increased encouragement of student and other developers without supporting corporations to apply for travel assistance, to ensure that the relevant developers can all show up. Within the scope of the board, the primary area for improvement I see is in increased efficiency and follow-through on commitments. The board could also increase its role in ensuring that desired improvements to our hosting cluster occur. ---- Matthieu Herrb Member Statement: Long time X contributor. Started active work with porting X11R6 to XFree86 on BSD. Current focus: Security, OpenBSD support. Candidate Statement: My goals, if I'm elected to the BoD, will be to continue to help the X community by making sure that the X.Org foundation make everything possible to: - keep the X.Org code available under a BSD/MIT style license. - keep the X.Org code portable on a vast range of architectures and systems. Among others, I'm going to help the X.Org foundation to continue to organise and facilitate developers meetings. Some kind of X server's internals tutorials should also be setup to help new developers to get started faster. Together with participations to actions like Google's Summer of Code, this has the opportunity of boosting X.Org developer's community. ---- Adam Jackson Member Statement: I work on X, for Red Hat and recreationally. Candidate Statement: The X Window System is one of the most successful free software projects in history, and it has been my privilege to work on it for the past three years. I believe that we at X.org have accomplished many great things in that time, revitalizing a stagnating community, and bringing a compelling modern display system to users around the world, on systems from large-scale visualisation to desktops to servers to consumer electronics. I also believe that there is a long, hard road ahead of us. The technical work we need to do to continue to compete and innovate is daunting. The political work we need to do to evangelize the importance of free software graphics is intimidating. The social work we need to do to continue to grow the community of contributors, testers, documenters and promoters is monumental, and absolutely essential to our continued success. My time working on X has been a challenge and a pleasure. I believe that my experience has given me insight into the challenges we face, and I hope to have the privilege of serving the community and the foundation as a board member as well as a contributor. ---- Stuart Kreitman Member Statement: Xorg promoter to the Open Solaris community, hacker, DevConf organizer, biodieseler, commuter scientist. Candidate Statement: The board has plenty of unfinished business in organization, bookkeeping, membership, and outreach. I want to stay involved and help move this stuff along. My X hacking these days is not open; its inside of Sun, but it will be opened in the near future. For example, we are porting the Sunray thin client to Xorg, and the mandate is to open license it. Most all of my work at Sun is conducive to the the health and proliferation of X.Org, if you consider the populations of Solaris x86 desksides and laptops which are running the Xorg code base, as well as large numbers of SunRays and cheap/free sparc workstations which will soon be moved from Xsun to Xorg. Also, I've been able to use my X.Org identity to help request resources like money and hardware and conferencing facilities for the Foundation. Thanks for the opportunity to serve in the past and the potential to continue service to this organization. ---- Carl Worth Member Statement: I'm the maintainer of the cairo graphics library, which is a significant user of the Render extension. I've also contributed implementations to the Render software fallbacks, and participated in XCB development. Candidate Statement: The X Window System has an essential role in an increasing number of mobile and desktop platforms built with Free Software. Of course, the X.Org Foundation has no technical role in the development of the system. But the foundation does have a unique position to be able to facilitate the workings of the community. Examples of foundation activities include hosting developers' summits and attracting new developers by funding students. I would be happy to contribute of my time and effort to help with these and other appropriate foundation activities. From pcpa at mandriva.com.br Fri Dec 21 12:57:24 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Fri, 21 Dec 2007 18:57:24 -0200 Subject: More about x-packages In-Reply-To: <20071221172815.GA8689@patate.is-a-geek.org> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <20071220055820.GO24034@supernova> <476A8408.805@mandriva.com.br> <20071221172815.GA8689@patate.is-a-geek.org> Message-ID: <476C28B4.2090904@mandriva.com.br> Julien Cristau wrote: > On Thu, Dec 20, 2007 at 13:02:32 -0200, Paulo Cesar Pereira de Andrade wrote: > >> For example, in the mandriva+gpl branch, I have integrated the vnc >> patches, >> and a few other patches/scripts from Debian that are licensed under GPL, and >> soon, should have more GPL licensed code. > > Hi, > > OOI, which ones of our patches are GPLed? Oi :-) If you have patience to wait, I can "grep GPL" on your sources to check them, but I am sorry I am not used to Debian -- Just kidding :-)) > Cheers, > Julien Unless I have a very outdated xvfb-run script, it is licensed under GPL. I don't have a vnc patch coming directly from Debian, neither know if/how it is built on Debian X Server (or if some alternative patch is used). Paulo From cworth at cworth.org Fri Dec 21 13:21:10 2007 From: cworth at cworth.org (Carl Worth) Date: Fri, 21 Dec 2007 13:21:10 -0800 Subject: Election of X.Org Foundation Board Members is now open In-Reply-To: <200712212036.lBLKaMwU007910@wezen.cs.pdx.edu> References: <200712212036.lBLKaMwU007910@wezen.cs.pdx.edu> Message-ID: <87wsr7ycah.wl%cworth@cworth.org> On Fri, 21 Dec 2007 12:36:22 -0800, Barton C Massey wrote: > button up top first.) Once a ballot is presented to you, > you will be asked to rank the six candidates in the order 1 > (most preferred) to 6 (least preferred). You do not have to > place all six votes. You may select a given ranking only > once (e.g., only place one vote of '2'). The actual ballot also adds the following text: The 4 candidates who receive the highest vote totals will serve for 2 years. And I'm thoroughly confused. What does "highest vote total" mean? How does the voting system treat a "no vote", (as compared to a 6, say). Would one or the other of these two choices express a stronger non-desire for a particular candidate to serve on the board? I'm guessing there isn't some sort of Condorcet method used to evaluate the rankings, correct? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sears at cs.berkeley.edu Fri Dec 21 14:06:05 2007 From: sears at cs.berkeley.edu (Russell Sears) Date: Fri, 21 Dec 2007 14:06:05 -0800 Subject: CMake (was More about x-packages) In-Reply-To: <20071221200940.GA14359@fooishbar.org> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> Message-ID: <476C38CD.50305@cs.berkeley.edu> After doing some work on a cmake-based project, I'm considering moving a non-trivial automake project to cmake. Here's why, in order: 1) CMake files are written in one language (not m4 + sh + make), so they're much easier to debug / write than configure.in and Makefile.am. After two ~4 hour sessions dealing with CMake, I feel about as comfortable with it as I was after spending years writing and maintaining a build system that uses autoconf/automake. 2) Build performance. "make clean ; make" is much faster under cmake than automake. 3) The recommended cmake configuration keeps all the autogenerated makefiles / binary objects, etc out of the source directories. On large projects, this is particularly nice if you have the foresight to have a build-opt/ and build-dbg/ directory. Then you don't need to do "make clean" (or mess with patches) to switch between optimized and debug builds. (I would be surprised if there is no way to get automake/autoconf to do this too...) 4) I've dealt with both, and I think libtool is harder to use than CMake's library handling. 5) CMake supports native windows builds. 6) CMake output tends to be a bit more readable than automake's The "% complete" meter it prints during builds is pretty neat. ;) Here are some unknowns / disadvantages that have kept me from switching, again in order: 1) Effort required to make the switch. 2) I've heard that cmake uses simpler dependency tracking than automake; I wonder if they get all the corner cases right, or if they rebuild more than they have to. (Compilation performance in cmake seems to have a large constant factor advantage over automake, so rebuilding a little extra might be OK.) 3) Maybe automake/conf is so slow because I need to perform some minor tweak to my build scripts. 4) CMake files only contain code that's executed during the "cmake" phase of building; it seems to be difficult (or at least "not the cmake way") to insert snippets of shell code into the generated makefiles. (This is partially because cmake supports native Windows builds, where /bin/sh isn't available.) 5) I've heard that automake and friends can simplify binary package generation. I don't know if cmake is any better or worse on this front. I am not an expert with (or even well informed about) either system, but I have dealt with building shared libraries and arranged for installed library detection / conditional compilation with both systems. -Rusty Daniel Stone wrote: > On Fri, Dec 21, 2007 at 10:29:26AM -0800, Alan W. Irwin wrote: >> On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote: >>> I am not sure if people would want to switch to cmake at this point. >> I can assure you that at first most will not. :-) Developers tend to be >> scared of changes to the build system for their software. But worrying >> about that is premature. What you first need is a proof of concept. > > Personally (as the person who was the only one running a modular Xorg > server for quite a while), I'm not scared -- I just fail to see any > benefit. Can someone please explain it to me, beyond the libtool thing? > I mean, if we're going to expend that much effort just to avoid libtool, > we could instead fix it once and for all upstream. > > What am I missing? > > Cheers, > Daniel > > > ------------------------------------------------------------------------ > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From irwin at beluga.phys.uvic.ca Fri Dec 21 14:37:57 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Dec 2007 14:37:57 -0800 (PST) Subject: CMake (was More about x-packages) In-Reply-To: <20071221200940.GA14359@fooishbar.org> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> Message-ID: On 2007-12-21 20:09-0000 Daniel Stone wrote: > On Fri, Dec 21, 2007 at 10:29:26AM -0800, Alan W. Irwin wrote: >> On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote: >>> I am not sure if people would want to switch to cmake at this point. >> >> I can assure you that at first most will not. :-) Developers tend to be >> scared of changes to the build system for their software. But worrying >> about that is premature. What you first need is a proof of concept. > > Personally (as the person who was the only one running a modular Xorg > server for quite a while), I'm not scared -- I just fail to see any > benefit. Can someone please explain it to me, beyond the libtool thing? > I mean, if we're going to expend that much effort just to avoid libtool, > we could instead fix it once and for all upstream. > > What am I missing? >From the developer point of view there is a big speed gain at the configuration stage. For autotools, as a one-time cost (unless you are using a tarball where somebody has done this for you) you normally have to run a bootstrap script with appropriate invocations of automake autoconf, etc., just to create the Makefile.in files and configure script that will be used to configure your system. Then you actually run the ./configure script to do that configuration. If there are any further changes in your autotools support files, then automake and autoconf are automatically (if you have the correct magic autotools recipe in place which I have now forgot) reinvoked as needed. CMake replaces all these autoconf, automake, and configured configure script complications with just one cmake executable (or various GUI front ends to it which I do not bother with). The CMake language syntax is really simple (much higher level than shell scripts and focussed completely on building software). Thus, in practice it has a large speed advantage compared to the configure script. This speed gain was slightly less than an order of magnitude as reported for Scribus in a sidebar to the KDE/CMake article at http://lwn.net/Articles/188693/. We confirmed similar configuration speed gains for the PLplot case. Of course, the resulting Makefiles are automatically set up to reinvoke cmake if any of the CMakeLists.txt files that are used to define the CMake-based build system are changed, but that reinvocation is also at least an order of magnitude faster than the equivalent autotools process. Of course, the order of magnitude speed advantage for configuration is diluted because developers spend only a fraction of their time doing configuration. But reduction of that configuration latency is most welcome, and there also appears to be a speed advantage to the actual running of the make command configured in the CMake case that I alluded to before because the libtool script does not have to be invoked. In sum, autotools relies on shell scripts both at the configuration and build (make) stages while CMake does not. Shell scripts are just slow compared to more specialized tools such as CMake and the MakeFiles that it configures that don't rely on a further (libtool) shell script to get compilation and linking done. Of course, once you are hooked by the CMake speed advantage, then the other important advantages (immediately understandable syntax which makes it easy to maintain your build system and great cross-platform support) kick in, but those are different stories. Daniel, if you have further interest start with the KDE/CMake story URL above. I was a bit skeptical when I first read that story, but it's all been true for the PLplot case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bart at cs.pdx.edu Fri Dec 21 15:10:52 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Fri, 21 Dec 2007 15:10:52 -0800 Subject: Election of X.Org Foundation Board Members is now open In-Reply-To: Your message of "Fri, 21 Dec 2007 13:21:10 PST." <87wsr7ycah.wl%cworth@cworth.org> References: <87wsr7ycah.wl%cworth@cworth.org> <200712212036.lBLKaMwU007910@wezen.cs.pdx.edu> Message-ID: <200712212310.lBLNAqJf022450@murzim.cs.pdx.edu> In message <87wsr7ycah.wl%cworth at cworth.org> you wrote: > On Fri, 21 Dec 2007 12:36:22 -0800, Barton C Massey wrote: > > button up top first.) Once a ballot is presented to you, > > you will be asked to rank the six candidates in the order 1 > > (most preferred) to 6 (least preferred). You do not have to > > place all six votes. You may select a given ranking only > > once (e.g., only place one vote of '2'). > > The actual ballot also adds the following text: > > The 4 candidates who receive the highest vote totals will > serve for 2 years. > > And I'm thoroughly confused. What does "highest vote > total" mean? How does the voting system treat a "no vote", > (as compared to a 6, say). Would one or the other of these > two choices express a stronger non-desire for a particular > candidate to serve on the board? Yes, we gave quite a confusing description. In particular, the phrase "highest vote total" is highly misleading---see below. Our apologies. > I'm guessing there isn't some sort of Condorcet method > used to evaluate the rankings, correct? In a way. The method we are using is known as the simple Borda Count method (http://en.wikipedia.org/wiki/Borda_count). The winners in the current election will be the four candidates with the highest point totals, where the rankings are scored as follows: rank points 1 6 2 5 3 4 4 3 5 2 6 1 none 0 Thus, refusing to rank someone denies them any points at all. Of course each rank can be assigned to at most one candidate. Thanks much for reminding me to clarify this. Bart Massey Election Committee X.Org Foundation Board bart at cs.pdx.edu From david.delaharpe.golden at gmail.com Fri Dec 21 15:51:46 2007 From: david.delaharpe.golden at gmail.com (David De La Harpe Golden) Date: Fri, 21 Dec 2007 23:51:46 +0000 Subject: Adding xinput to apps In-Reply-To: <4769EE60.4020300@who-t.net> References: <4768A08A.7070300@who-t.net> <476956CF.9080503@vmware.com> <4769EE60.4020300@who-t.net> Message-ID: <8e24944a0712211551p690703c5w6589fc8b9d00cf9b@mail.gmail.com> Just to note in passing, there's a "xidump" CLI tool bundled with linuxwacom with overlapping functionality to the xinput CLI tool. From irwin at beluga.phys.uvic.ca Fri Dec 21 19:29:07 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Dec 2007 19:29:07 -0800 (PST) Subject: CMake (was More about x-packages) In-Reply-To: <476C38CD.50305@cs.berkeley.edu> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On 2007-12-21 14:06-0800 Russell Sears wrote: > After doing some work on a cmake-based project, I'm considering moving a > non-trivial automake project to cmake. Here's why, in order: Hi Russell: I agree on all of your 6 "pro" counts. More comments in context folow below. > Here are some unknowns / disadvantages that have kept me from switching, > again in order: > > 1) Effort required to make the switch. No question. However, from my experience as the chief assistant to the guy who earlier created the autotools-based build system for PLplot and leader of the group that created the later CMake-based build system for PLplot, putting together a CMake-based build system from scratch is substantially easier than doing the same for autotools. > > 2) I've heard that cmake uses simpler dependency tracking than automake; I > wonder if they get all the corner cases right, or if they rebuild more than > they have to. (Compilation performance in cmake seems to have a large > constant factor advantage over automake, so rebuilding a little extra might > be OK.) CMake has two kinds of dependency tracking. It takes a bit of effort to figure out which kind of dependency (file or target) should be used in a given situation and the rules that should be followed when you are mixing them. I am no fan of this aspect of CMake, but the CMake developers claim these two kinds of dependencies makes their life much easier, and they further claim the two kinds of dependencies do not add that big a burden for developers of CMake-based build systems (which I mostly agree with). Anyhow, once you have followed the rules, you can run "make" twice in succession for a complicated software project like PLplot, and the second time absolutely nothing is built, and it takes the "make" command less than a second to figure that out as it checks every one of our complicated chains of dependencies. > > 3) Maybe automake/conf is so slow because I need to perform some minor tweak > to my build scripts. The default CMake compiler optimization is no optimization at all so that gives a huge apparent CMake build speed advantage compared to default autotools which uses -O2. However, you can easily ask autotools to use no optimization in a build or you can easily ask CMake to use -O2 optimization in a build to get an "apples-to-apples" build speed comparison between the two build systems. CMake wins that fair battle by varying amounts depending on how many different files your source code is split into. The larger the number of source files, the greater the latency caused by the libtool shell script. > > 4) CMake files only contain code that's executed during the "cmake" phase of > building; it seems to be difficult (or at least "not the cmake way") to > insert snippets of shell code into the generated makefiles. (This is > partially because cmake supports native Windows builds, where /bin/sh isn't > available.) It is straightforward with CMake to create Makefile rules which run combinations of shell commands including running shell scripts (if you want). Cygwin and MinGW/MSYS are okay, but you normally do lose the bare (ie without Cygwin or MinGW) windows platform in this case since it is rare (although completely possible) for windows users to install bash. > > 5) I've heard that automake and friends can simplify binary package > generation. I don't know if cmake is any better or worse on this front. We used cmake/cpack to generate our latest PLplot source release tarball so we know generating source packages works fine. The same cmake/cpack combination is also okay for generating binary packages (essentially a tarball of all the installed files) or you can do that directly with the "make install" and "tar" commands. Since I am going for full disclosure here, I want to add some other potentially negative points as well. 6) CMake-2.4.x does not support cross-compilation. However, apparently cross-compilation is well supported in the CVS version of cmake that is scheduled to be released at the start of the forthcoming 2.6.x series of releases. You should wait for that release series (or use the CVS version) if you require cross compilation. 7) Current lack of up-to-date chapter-style documentation. The CMake book first edition is completely out of print and also substantially out of date (it documents CMake version 2.2.x while the current release series is 2.4.x). A second edition apparently will be published soon (within weeks), but that didn't help the PLplot team when we were developing the CMake-based build system for PLplot back in the early days of the CMake 2.4.x releases. We did find essentially all we needed to know based on the links we collected at http://www.miscdebris.net/plplot_wiki/index.php?title=General_CMake_documentation_links, Up-to-date chapter-style documentation would have made life even easier for us, and the publication of the second edition should be a big help to those who are just getting interested in CMake (and, no, I am not one of the authors of that book, :-) ). 8) Potential culture shock. Those who are really expert in autotools magic will take a while to feel comfortable in the new CMake build system culture. If autotools gurus aren't mentally prepared to do things in a different way they will run into a classic culture shock. OTOH, those who just use autotools casually or who are build system newbies will probably immediately enjoy the new CMake build system culture since they won't have fixed preconceptions or try to make a build system that is an exact clone of an autotools-based build system. The decision to change from an autotools-based build system to a CMake-based build system is based on a complicated tradeoff of positives and negatives which will differ from one software project to the next. As emphasized by everybody, the biggest negative for any project is the effort required to do the change. However, the positives for switching from autotools to CMake are substantial as recently discovered by quite a few projects such as KDE and PLplot. If some X developer is interested, I would advise attempting a build of some small component of X with CMake to get your feet wet. Such a small proof of concept would substantially help individual developers to decide whether they want to proceed further with CMake for X. I want to emphasize that CMake-based and autotools-based build systems are not either/or propositions since they can peacefully coexist together in the same source tree. However, if somebody does eventually implement a complete CMake-based build system for X, I think you will find the autotools-based build system will naturally fall into disuse over the course of a year or two because the CMake-based alternative should help you to do substantially faster and more convenient development of X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From graeme2 at argyllcms.com Sat Dec 22 00:30:09 2007 From: graeme2 at argyllcms.com (Graeme Gill) Date: Sat, 22 Dec 2007 19:30:09 +1100 Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: <476CCB11.4030100@argyllcms.com> If you were contemplating using a different build system, shouldn't you evaluate the leading contenders before choosing one ? boost.build for instance, has been talked about quite favourably by some projects, and so would be interesting to compare with CMake. Graeme Gill. From ku.b at gmx.de Sat Dec 22 01:09:17 2007 From: ku.b at gmx.de (Kai-Uwe Behrmann) Date: Sat, 22 Dec 2007 10:09:17 +0100 (CET) Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: More to the Cons: Cmake is complicated or at least non intiutive to debug. to elaborate: One of the projects, I like to build, got backslashes in the final compiler line. I could see them with cmake Verbose=1. Ok, cmake created a Makefile. In a few second I hoped to find the line and all is ok. Opened a Makefile and seen lots of cmake specific CMAKE_COMMAND and the like calls. I did not expect this kind of nativeness in Makefile. At some point I stalled the build due to lack of time to invest further. CMake feels not like unix: o no make uninstall target by default as with autotools o no environment variables o no config.site scripts(?) o omitting the fun of posix scripting The above sentences reflect my state of knowledge. Clearly from a pov of a cmake outsider, as generaly most people for build tools are. That, less people love libtool, does not automatic imply to omit autotools completely and use cmake. Cmake has the same disadvantage like autotools, to have a intermediate step like libtool to hide many details. But want I'd want is to see and being able to directly react to the details. A long search where some options come from is a terrible wast of time. For autotools based build systems I'd say, just omit libtool and stay with the shell scripts and makefile combo. Put most host specifics into one file by configure and include that in every Makefile. There are projects out to work like this in an easy manner. Ok the autotools documentation could be improved to better reflect alternative ways of utilisation. A comparision using FLTK (fltk-1.1.x-r5989), which I enjoy to learn from its clear build system: CMake: 1min 18seconds make: 1min 3seconds That Make was quicker, is probably due to not compile the local zlib, png and jpeg versions. But this are probably just 10 seconds. configure detected the libs and omited automatically. One question: What is the difference of installing Cmake in opposite to MinGW in order to compile a software project? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org From jrfonseca at tungstengraphics.com Sat Dec 22 01:50:28 2007 From: jrfonseca at tungstengraphics.com (=?iso-8859-1?b?Sm9z6Q==?= Fonseca) Date: Sat, 22 Dec 2007 09:50:28 +0000 (UTC) Subject: CMake (was More about x-packages) References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On Fri, 21 Dec 2007 14:06:05 -0800, Russell Sears wrote: > After doing some work on a cmake-based project, I'm considering moving a > non-trivial automake project to cmake. Here's why, in order: > > 1) CMake files are written in one language (not m4 + sh + make), so > they're much easier to debug / write than configure.in and Makefile.am. > After two ~4 hour sessions dealing with CMake, I feel about as > comfortable with it as I was after spending years writing and > maintaining a build system that uses autoconf/automake. > > 2) Build performance. "make clean ; make" is much faster under cmake > than automake. > > 3) The recommended cmake configuration keeps all the autogenerated > makefiles / binary objects, etc out of the source directories. On large > projects, this is particularly nice if you have the foresight to have a > build-opt/ and build-dbg/ directory. Then you don't need to do "make > clean" (or mess with patches) to switch between optimized and debug > builds. (I would be surprised if there is no way to get > automake/autoconf to do this too...) > > 4) I've dealt with both, and I think libtool is harder to use than > CMake's library handling. > > 5) CMake supports native windows builds. > > 6) CMake output tends to be a bit more readable than automake's The "% > complete" meter it prints during builds is pretty neat. ;) > > Here are some unknowns / disadvantages that have kept me from switching, > again in order: > > 1) Effort required to make the switch. > > 2) I've heard that cmake uses simpler dependency tracking than automake; > I wonder if they get all the corner cases right, or if they rebuild more > than they have to. (Compilation performance in cmake seems to have a > large constant factor advantage over automake, so rebuilding a little > extra might be OK.) > > 3) Maybe automake/conf is so slow because I need to perform some minor > tweak to my build scripts. > > 4) CMake files only contain code that's executed during the "cmake" > phase of building; it seems to be difficult (or at least "not the cmake > way") to insert snippets of shell code into the generated makefiles. > (This is partially because cmake supports native Windows builds, where > /bin/sh isn't available.) > > 5) I've heard that automake and friends can simplify binary package > generation. I don't know if cmake is any better or worse on this front. > > I am not an expert with (or even well informed about) either system, but > I have dealt with building shared libraries and arranged for installed > library detection / conditional compilation with both systems. > > -Rusty I also have good experiences with CMake, but there is one other disadvantage comparing with libtool: lack of support for convenience libraries. This makes the creation of large SO modules which shared code (e.g. a DRI driver) painful if not unfeasible without writing custom and likely non-portable CMake macros. See the "Autoconf support for Mesa" thread on mesa3d-dev ML: http://sourceforge.net/mailarchive/message.php?msg_name=fjgkbm%24mc6% 241%40ger.gmane.org and http://www.cmake.org/Wiki/ CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F Jos? From zhen78 at gmail.com Sat Dec 22 11:15:42 2007 From: zhen78 at gmail.com (Zhenyu Wang) Date: Sun, 23 Dec 2007 03:15:42 +0800 Subject: linux-2.6.24-rcX regression / xserver-xorg-video-intel / Q35 In-Reply-To: <20071222002516.GR6625@prithivi.gnumonks.org> References: <20071222002516.GR6625@prithivi.gnumonks.org> Message-ID: <20071222191542.GA17055@localdomain> On 2007.12.22 01:25:16 +0100, Harald Welte wrote: > > I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am > observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as > of today, ea67db4cdbbf7f4e74150e71da0984e25121f500). > > The last working version is 2.6.24-rc1. > > The system is running debian unstable (current) using > xserver-xorg-video-intel 2.2.0-1 > > So what is the actual problem: > It seems to be related to the way how the iommu/gart is used for memory > allocation of the framebuffer memory. There's no behavior change in intel agp module between .24-rc1 to rc6. IOMMU shouldn't matter here, if you build x86_64 system and with CONFIG_DMAR on, you should be already having CONFIG_DMAR_GFX_WA for you. > > Xorg starts just as it should, but the lower part of the screen is > completely gobbled. I suppose the lower part of the screen is actually > showing off-screen memory at some completely differnt location. Do you have other changes except kernel? like other xorg packages, bios? > > Interestingly, the mouse cursor is superimposed on top of the garbage > (and it is not distorted). yeah, hardware cursor uses another plane than scan buffer, it's seperate. Could you fire a bug to https://bugs.freedesktop.org with versions and logs? Thanks. From harryrat at postnuklear.de Sat Dec 22 04:57:32 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Sat, 22 Dec 2007 13:57:32 +0100 Subject: KDrive patches Message-ID: <200712221357.32564.harryrat@postnuklear.de> Hi there! For those interested, I uploaded 2 KDrive related patches, to be found at http://www.postnuklear.de/xorg-patches/ The first one is a more elaborated fix of the pointer issue when rotating the screen, this fixes touchscreen problems as well as mouse problems (which also was handled incorrectly on rotation) The second patch incorporates above changes, as well as adding the ability to send Button 3 events on "long touch" for touchscreens. More information can be found under above link. I hope those patches are useful and not too buggy (-: Happy holidays to all Greez Harry From irwin at beluga.phys.uvic.ca Sat Dec 22 11:05:42 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Dec 2007 11:05:42 -0800 (PST) Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On 2007-12-22 09:50-0000 Jos? Fonseca wrote: > I also have good experiences with CMake, but there is one other > disadvantage comparing with libtool: lack of support for convenience > libraries. This makes the creation of large SO modules which shared code > (e.g. a DRI driver) painful if not unfeasible without writing custom and > likely non-portable CMake macros. > > See the "Autoconf support for Mesa" thread on mesa3d-dev ML: > > http://sourceforge.net/mailarchive/message.php?msg_name=fjgkbm%24mc6% > 241%40ger.gmane.org > > and > http://www.cmake.org/Wiki/ > CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F Actually, I think you can state it stronger than that. If you insist on "convenience" libraries (unorganized collections of compiled objects that are not a real library), then CMake is not for you since from discussions on this subject on the CMake mailing list the CMake developers feel that convenience libraries are a build-system crutch that they do not want to support, and I agree with their stand on this. Analysis of the X specifics may indicate an obvious way to avoid using this crutch. For example, if large SO modules share extensive code as indicated above, isn't that a strong indication that you should make a real library out of that shared code? Real libraries are stongly supported by CMake without any need for recompilation, and the end result is a lot easier to understand and maintain in my opinion. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sverre at viewmark.com Sat Dec 22 10:58:16 2007 From: sverre at viewmark.com (Sverre Froyen) Date: Sat, 22 Dec 2007 11:58:16 -0700 Subject: [ANNOUNCE] xf86-video-ati 6.7.197 In-Reply-To: References: Message-ID: <200712221158.16182.sverre@viewmark.com> On Thursday 20 December 2007, Alex Deucher wrote: > Another RC release. Lots of stuff fixed and new features. See the > changelog for more. Highlights: Hi Alex, For some reason, the patch to restore the display upon exiting the X server, and which worked well in the 6.6.3 and 6.6.99 drivers, no longer works in the 6.7 drivers that I have tried (6.7.195 and 6.7.197). The patch was officially included in the ati driver in commit 80eee856938756e1222526b6c39cee8b5252b409 Author: Matthieu Herb <> Date: Tue Oct 9 16:17:50 2007 -0400 RADEON: fix console restore on netbsd Include the mode restore bugfix from monolithic Xorg, that is derived from the version in xsrc which in turn was provided by Matthieu Herb over 3 years ago on the XFree86 lists. Suggested by various developers, hold-back due to the working state in xorg-server 1.1.1. Tracing down the exact change showed that the changed default color depth made this issue a lot more prominent again. Discussed with Eric Anholt. I attempted to print out the the content of the saved data right after the call to vgaHWSave and right before the call to vgaHWRestore (in radeon.c) and it looks like it's been modified in between the two calls (this could, of course, be a misunderstanding on my part). It would be nice to get this issue resolved before the new driver is officially released. Thanks, Sverre PS I've attached my log and config files. -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 50658 bytes Desc: not available URL: -------------- next part -------------- # ********************************************************************** # Refer to the xorg.conf(5) man page for details about the format of # this file. # ********************************************************************** # ********************************************************************** # Module section -- this section is used to specify # which dynamically loadable modules to load. # ********************************************************************** # Section "Module" # This loads the DBE extension module. Load "dbe" # Double buffer extension # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that module. SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection # This loads the font modules # Load "type1" Load "freetype" # Load "xtt" # This loads the GLX module # Load "glx" # This loads the DRI module # Load "dri" EndSection # ********************************************************************** # Files section. This allows default font and rgb paths to be set # ********************************************************************** Section "Files" # The location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. # RgbPath "/usr/pkg/share/X11/rgb" # Multiple FontPath entries are allowed (which are concatenated together), # as well as specifying multiple comma-separated entries in one FontPath # command (or a combination of both methods) # # FontPath "/usr/pkg/lib/X11/fonts/misc/" # FontPath "/usr/pkg/lib/X11/fonts/TTF/" # FontPath "/usr/pkg/lib/X11/fonts/OTF" FontPath "/usr/pkg/lib/X11/fonts/Type1/" FontPath "/usr/pkg/lib/X11/fonts/100dpi/" FontPath "/usr/pkg/lib/X11/fonts/75dpi/" FontPath "/usr/pkg/lib/X11/fonts/local/" FontPath "/usr/pkg/lib/X11/fonts/Speedo/" # FontPath "/usr/pkg/lib/X11/fonts/TrueType/" # FontPath "/usr/pkg/lib/X11/fonts/freefont/" # The module search path. The default path is shown here. # ModulePath "/usr/pkg/lib/modules" EndSection # ********************************************************************** # Server flags section. # ********************************************************************** Section "ServerFlags" # Uncomment this to cause a core dump at the spot where a signal is # received. This may leave the console in an unusable state, but may # provide a better stack trace in the core dump to aid in debugging # Option "NoTrapSignals" # Uncomment this to disable the VT switch sequence # (where n is 1 through 12). This allows clients to receive these key # events. # Option "DontVTSwitch" # Uncomment this to disable the server abort sequence # This allows clients to receive this key event. # Option "DontZap" # Uncomment this to disable the / mode switching # sequences. This allows clients to receive these key events. # Option "Dont Zoom" # Uncomment this to disable tuning with the xvidtune client. With # it the client can still run and fetch card and monitor attributes, # but it will not be allowed to change them. If it tries it will # receive a protocol error. # Option "DisableVidModeExtension" # Uncomment this to enable the use of a non-local xvidtune client. # Option "AllowNonLocalXvidtune" # Uncomment this to disable dynamically modifying the input device # (mouse and keyboard) settings. # Option "DisableModInDev" # Uncomment this to enable the use of a non-local client to # change the keyboard or mouse settings (currently only xset). # Option "AllowNonLocalModInDev" EndSection # ********************************************************************** # Input devices # ********************************************************************** # ********************************************************************** # Core keyboard's InputDevice section # ********************************************************************** Section "InputDevice" Identifier "Keyboard0" Driver "kbd" # For most OSs the protocol can be omitted (it defaults to "Standard"). # When using XQUEUE (only for SVR3 and SVR4, but not Solaris), # uncomment the following line. # Option "Protocol" "Xqueue" # Option "Protocol" "wskbd" # wskbd protocol # Option "Device" "/dev/wskbd" Option "AutoRepeat" "500 30" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Option "Xleds" "1 2 3" # Option "LeftAlt" "Meta" # Option "RightAlt" "ModeShift" # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: # Option "XkbModel" "pc105" # If you have a US Microsoft Natural keyboard, you can use: # Option "XkbModel" "microsoft" # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: # Option "XkbLayout" "de" # or: # Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" # # If you'd like to switch the positions of your capslock and # control keys, use: # Option "XkbOptions" "ctrl:swapcaps" # These are the default XKB settings for Xorg # Option "XkbRules" "xorg" # Option "XkbModel" "pc105" # Option "XkbLayout" "us" # Option "XkbVariant" "" # Option "XkbOptions" "" # Option "XkbDisable" Option "XkbRules" "xorg" Option "XkbModel" "pc101" Option "XkbLayout" "us" EndSection # ********************************************************************** # Core Pointer's InputDevice section # ********************************************************************** Section "InputDevice" # Identifier and driver Identifier "Mouse0" Driver "mouse" #Driver "ws" Option "Protocol" "wsmouse" # wsmouse protocol Option "Device" "/dev/wsmouse" # When using XQUEUE, comment out the above two lines, and uncomment # the following line. # Option "Protocol" "Xqueue" # Mouse-speed setting for PS/2 mouse. # Option "Resolution" "256" # Baudrate and SampleRate are only for some Logitech mice. In # almost every case these lines should be omitted. # Option "BaudRate" "9600" # Option "SampleRate" "150" # Mouse wheel mapping. Default is to map vertical wheel to buttons 4 & 5, # horizontal wheel to buttons 6 & 7. Change if your mouse has more than # 3 buttons and you need to map the wheel to different button ids to avoid # conflicts. Option "ZAxisMapping" "4 5 6 7" # Emulate3Buttons is an option for 2-button mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) Option "Emulate3Buttons" # Option "Emulate3Timeout" "50" # ChordMiddle is an option for some 3-button Logitech mice # Option "ChordMiddle" EndSection # ********************************************************************** # Monitor section # ********************************************************************** # Any number of monitor sections may be present Section "Monitor" Identifier "Monitor0" HorizSync 28-99 VertRefresh 43-85 VendorName "IBM" ModelName "T42" #Option "DPMS" "false" Option "PanelSize" "1400x1050" Option "PreferredMode" "1400x1050" EndSection Section "Monitor" Identifier "Monitor1" #HorizSync 28-100 #VertRefresh 43-85 #DisplaySize 480 310 # mm #VendorName "Mitsubishi" #ModelName "Diamond Plus 200" #Option "DPMS" "false" # For Sony wide #ModeLine "1600x1050" 162.0 1600 1664 1856 2160 1050 1052 1064 1082 #ModeLine "1850x1200" 212.0 1850 1874 2076 2400 1200 1202 1210 1252 Option "PreferredMode" "1600x1200" Option "RightOf" "Monitor0" EndSection Section "Monitor" Identifier "Monitor2" HorizSync 28-82 #VertRefresh 60.28 VertRefresh 74.84 #DisplaySize 480 310 # mm VendorName "PHL" ModelName "Philips 170B2" #Option "DPMS" "false" # 1280x1024 @ 60.28 Hz (GTF) hsync: 63.90 kHz; pclk: 109.39 MHz Modeline "1280x1024_60.28" 109.39 1280 1360 1496 1712 1024 1025 1028 1060 -HSync +Vsync # 1280x1024 @ 74.84 Hz (GTF) hsync: 80.00 kHz; pclk: 138.25 MHz Modeline "1280x1024_74.84" 138.25 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync Option "PreferredMode" "1280x1024_74.84" Option "LeftOf" "Monitor0" EndSection # ********************************************************************** # Graphics device section # ********************************************************************** # Any number of graphics device sections may be present Section "Device" Identifier "Card0" Driver "ati" BusID "PCI:1:0:0" Option "Monitor-LVDS" "Monitor0" #Option "Monitor-VGA-0" "Monitor1" #Option "Monitor-DVI-0" "Monitor2" EndSection # Standard VGA Device: Section "Device" Identifier "Standard VGA" VendorName "Unknown" BoardName "Unknown" # The chipset line is optional in most cases. It can be used to override # the driver's chipset detection, and should not normally be specified. # Chipset "generic" # The Driver line must be present. When using run-time loadable driver # modules, this line instructs the server to load the specified driver # module. Even when not using loadable driver modules, this line # indicates which driver should interpret the information in this section. Driver "vga" # The BusID line is used to specify which of possibly multiple devices # this section is intended for. When this line isn't present, a device # section can only match up with the primary video device. For PCI # devices a line like the following could be used. This line should not # normally be included unless there is more than one video device # intalled. # BusID "PCI:0:10:0" # VideoRam 256 # Clocks 25.2 28.3 EndSection # ********************************************************************** # Screen sections # ********************************************************************** # Any number of screen sections may be present. Each describes # the configuration of a single screen. A single specific screen section # may be specified from the X server command line with the "-screen" # option. Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1400x1050" Virtual 3000 1200 EndSubsection EndSection # ********************************************************************** # ServerLayout sections. # ********************************************************************** # Any number of ServerLayout sections may be present. Each describes # the way multiple screens are organised. A specific ServerLayout # section may be specified from the X server command line with the # "-layout" option. In the absence of this, the first section is used. # When now ServerLayout section is present, the first Screen section # is used alone. Section "ServerLayout" Identifier "other" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection #Section "ServerLayout" # Identifier "work" # Screen 0 "Screen1" 0 0 # InputDevice "Mouse0" "CorePointer" # InputDevice "Keyboard0" "CoreKeyboard" #EndSection # #Section "ServerLayout" # Identifier "home" # Screen 0 "Screen2" 0 0 # InputDevice "Mouse0" "CorePointer" # InputDevice "Keyboard0" "CoreKeyboard" #EndSection #Section "DRI" # Mode 0666 #EndSection From irwin at beluga.phys.uvic.ca Sat Dec 22 11:37:56 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Dec 2007 11:37:56 -0800 (PST) Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On 2007-12-22 10:09+0100 Kai-Uwe Behrmann wrote: > CMake feels not like unix: > (1) no make uninstall target by default as with autotools > (2) no environment variables > (3) no config.site scripts(?) > (4) omitting the fun of posix scripting These comments (which I have numbered for clarity) should be answered. (1) is true, but see http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F for an easy alternative using install_manifest.txt. (2) CMake has complete support for environment variables. There are standard CMake-specific environment variables it interprets which are documented at http://www.cmake.org/Wiki/CMake_Useful_Variables Furthermore, from within the CMake environment you can get and set arbitrary environment variables. (3) Not sure exactly what you mean here, but you can tailor cmake to your exact needs using the cmake -C option. (4) You can specifically run any command you like (including shell scripts) at cmake (configuration) time using the execute_process CMake command. As I noted before, full scripting is also available at build time from within the Makefile generated by CMake. > One question: What is the difference of installing Cmake in opposite to > MinGW in order to compile a software project? MinGW with MSYS and MinGW without MSYS are two possible windows platforms. CMake can be used to help build software on both those platforms. Autotools can be used to build software on MinGW but MSYS is required in that case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From alexdeucher at gmail.com Sat Dec 22 12:06:18 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Sat, 22 Dec 2007 15:06:18 -0500 Subject: [ANNOUNCE] xf86-video-ati 6.7.197 In-Reply-To: <200712221158.16182.sverre@viewmark.com> References: <200712221158.16182.sverre@viewmark.com> Message-ID: On Dec 22, 2007 1:58 PM, Sverre Froyen wrote: > On Thursday 20 December 2007, Alex Deucher wrote: > > Another RC release. Lots of stuff fixed and new features. See the > > changelog for more. Highlights: > > Hi Alex, > > For some reason, the patch to restore the display upon exiting the X server, > and which worked well in the 6.6.3 and 6.6.99 drivers, no longer works in the > 6.7 drivers that I have tried (6.7.195 and 6.7.197). The patch was > officially included in the ati driver in The driver has changed substantially since then. > > commit 80eee856938756e1222526b6c39cee8b5252b409 > Author: Matthieu Herb <> > Date: Tue Oct 9 16:17:50 2007 -0400 > > RADEON: fix console restore on netbsd > > Include the mode restore bugfix from monolithic Xorg, that is derived > from the version in xsrc which in turn was provided by Matthieu Herb > over 3 years ago on the XFree86 lists. Suggested by various > developers, hold-back due to the working state in xorg-server 1.1.1. > Tracing down the exact change showed that the changed default color > depth made this issue a lot more prominent again. Discussed with Eric > Anholt. > So this patch makes no difference? I thought you told me it fixed your problems when I applied it. That's why I applied it. > I attempted to print out the the content of the saved data right after the > call to vgaHWSave and right before the call to vgaHWRestore (in radeon.c) and > it looks like it's been modified in between the two calls (this could, of > course, be a misunderstanding on my part). TBH, I doubt the vga regs are at fault. We deal with a lot more state than the previous driver did so there is probably some new reg or regs that need to be restored in a particular way to fix console restore. > > It would be nice to get this issue resolved before the new driver is > officially released. Of course. The best bet for tracking this down is to try and find a recent-ish (6.7.19x version) of the driver that works for you. then use git bisect to try and track down what commit broken things. Alex From hvengel at astound.net Sat Dec 22 12:05:31 2007 From: hvengel at astound.net (Hal V. Engel) Date: Sat, 22 Dec 2007 12:05:31 -0800 Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> Message-ID: <200712221205.31208.hvengel@astound.net> On Saturday 22 December 2007 11:37:56 Alan W. Irwin wrote: > > One question: What is the difference of installing Cmake in opposite to > > MinGW in order to compile a software project? > > MinGW with MSYS and MinGW without MSYS are two possible windows platforms. > CMake can be used to help build software on both those platforms. Autotools > can be used to build software on MinGW but MSYS is required in that case. More specifically. MinGW is a minimal GCC installation (compiler, linker, make utility and compiler runtimes) and some Windows specific runtimes. MSYS is autotools and some other unix utilities such as a bash shell, ls... so that you can build applications and libraries that use autotools in an environment that is unix like. For applications/libraries that use build systems like cmake, scons, jam... you do not need MSYSwhen using MinGW. Because many applications that do not use autotools are dependant on libraries that do use autotools it is common to have MSYS installed along side MinGW so that those autotooled libraries can be built. Hal From jrfonseca at tungstengraphics.com Sat Dec 22 12:44:35 2007 From: jrfonseca at tungstengraphics.com (=?ISO-8859-1?Q?Jos=E9_Fonseca?=) Date: Sat, 22 Dec 2007 20:44:35 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On 12/22/07, Alan W. Irwin wrote: > On 2007-12-22 09:50-0000 Jos? Fonseca wrote: > > > I also have good experiences with CMake, but there is one other > > disadvantage comparing with libtool: lack of support for convenience > > libraries. This makes the creation of large SO modules which shared code > > (e.g. a DRI driver) painful if not unfeasible without writing custom and > > likely non-portable CMake macros. > > > > See the "Autoconf support for Mesa" thread on mesa3d-dev ML: > > > > http://sourceforge.net/mailarchive/message.php?msg_name=fjgkbm%24mc6% > > 241%40ger.gmane.org > > > > and > > http://www.cmake.org/Wiki/ > > CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F > > Actually, I think you can state it stronger than that. If you insist on > "convenience" libraries (unorganized collections of compiled objects that > are not a real library), then CMake is not for you since from discussions on > this subject on the CMake mailing list the CMake developers feel that > convenience libraries are a build-system crutch that they do not want to > support, and I agree with their stand on this. I don't think they have that they have that stand at all. Check Bill Hoffman note on the bottom of http://www.cmake.org/Bug/view.php?id=5155 , It is a technically difficult problem but there are legitimate use cases. I think DRI drivers, or drivers in general, is one of them. > Analysis of the X specifics may indicate an obvious way to avoid using this > crutch. For example, if large SO modules share extensive code as indicated > above, isn't that a strong indication that you should make a real library > out of that shared code? Not really. There will be only one DRI driver loaded in a single process. I don't know enough to comment on X. > Real libraries are stongly supported by CMake > without any need for recompilation, and the end result is a lot easier to > understand and maintain in my opinion. I don't agree. It might make easier to understand and maintain from the build system POV. But I fail to see the practical benefit of increasing the number of shared libraries, if they won't be shared at all at runtime, just linked once. Jos? From daniel at fooishbar.org Sat Dec 22 13:02:54 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sat, 22 Dec 2007 21:02:54 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: <20071222210254.GA27087@fooishbar.org> On Sat, Dec 22, 2007 at 11:05:42AM -0800, Alan W. Irwin wrote: > Actually, I think you can state it stronger than that. If you insist on > "convenience" libraries (unorganized collections of compiled objects that > are not a real library), then CMake is not for you since from discussions on > this subject on the CMake mailing list the CMake developers feel that > convenience libraries are a build-system crutch that they do not want to > support, and I agree with their stand on this. X has a huge number of subsystems which need to be linked together. I'm also willing to bet that the number of files involved would exceed the limits of some linkers. > Analysis of the X specifics may indicate an obvious way to avoid using this > crutch. For example, if large SO modules share extensive code as indicated > above, isn't that a strong indication that you should make a real library > out of that shared code? Real libraries are stongly supported by CMake > without any need for recompilation, and the end result is a lot easier to > understand and maintain in my opinion. Yes, real libraries are good, but they won't work for the X case due to design that assumes everything's linked into the same final object, and also due to the fact that they're, well, not real libraries. We don't make API guarantees for internals. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From irwin at beluga.phys.uvic.ca Sat Dec 22 15:22:18 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Dec 2007 15:22:18 -0800 (PST) Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: On 2007-12-22 20:44-0000 Jos? Fonseca wrote: > On 12/22/07, Alan W. Irwin wrote: >> Actually, I think you can state it stronger than that. If you insist on >> "convenience" libraries (unorganized collections of compiled objects that >> are not a real library), then CMake is not for you since from discussions on >> this subject on the CMake mailing list the CMake developers feel that >> convenience libraries are a build-system crutch that they do not want to >> support, and I agree with their stand on this. > > I don't think they have that they have that stand at all. Check Bill > Hoffman note on the bottom of > http://www.cmake.org/Bug/view.php?id=5155 , It is a technically > difficult problem but there are legitimate use cases. I think DRI > drivers, or drivers in general, is one of them. Thanks for that link, Joe. I stand corrected on the "attitude" issue. But it is also pretty clear from that link that Bill (the chief CMake developer for others following this thread) gave up on the CMake convenience library implementation and no other CMake developer has taken this issue on yet. Thus, I believe the only practical way to use CMake for the indefinite future is to wean yourself from convenience libraries by, e.g., replacing them with real libraries. By the way, convenience libraries are not a necessity for drivers in general (if by that term above you meant a dynamically loaded shared object). For example, PLplot has no convenience libraries, but we have plenty of dynamically loaded plotting device drivers which link to all sorts of real libraries (some built by PLplot some external). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Sat Dec 22 16:02:06 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Dec 2007 16:02:06 -0800 (PST) Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: <20071222210254.GA27087@fooishbar.org> References: <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> <20071222210254.GA27087@fooishbar.org> Message-ID: On 2007-12-22 21:02-0000 Daniel Stone wrote: > On Sat, Dec 22, 2007 at 11:05:42AM -0800, Alan W. Irwin wrote: >> Analysis of the X specifics may indicate an obvious way to avoid using this >> crutch. For example, if large SO modules share extensive code as indicated >> above, isn't that a strong indication that you should make a real library >> out of that shared code? Real libraries are stongly supported by CMake >> without any need for recompilation, and the end result is a lot easier to >> understand and maintain in my opinion. > > Yes, real libraries are good, but they won't work for the X case due to > design that assumes everything's linked into the same final object, and > also due to the fact that they're, well, not real libraries. We don't > make API guarantees for internals. I would appreciate your comments on the following idea, but please be gentle if I have wandered beyond my depth. :-) The idea is to directly replace a convenience library (a collection of compiled objects according to http://sourceware.org/autobook/autobook/autobook_92.html) by a real static library which is private to X. Of course, assuming the SO modules will need to be linked to that static library, the static library has to be compiled with the same compile flags (e.g., -fPIC) used to create the SO modules. Then I understand that the linking of the SO module with the static library proceeds by copying the required code from the static library and placing it in the SO with no necessity of installing the static library or letting its internals be exposed. There may be some additional linking options required to keep the API of the copied static library code within the SO private. But if my overall mental model of the linking issues is correct, then the above idea should work. Furthermore, implementing it with CMake would be straightforward so that lack of convenience library support would no longer be a CMake deal breaker for X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bjlockie at lockie.ca Sat Dec 22 20:59:59 2007 From: bjlockie at lockie.ca (James Lockie) Date: Sat, 22 Dec 2007 23:59:59 -0500 Subject: what does this error mean? Message-ID: <476DEB4F.6090507@lockie.ca> > [4739]: segfault at 00000000000001b8 rip 000000000053f5e7 rsp > 00007fffa6fe95b0 error 4 From ku.b at gmx.de Sun Dec 23 00:45:36 2007 From: ku.b at gmx.de (Kai-Uwe Behrmann) Date: Sun, 23 Dec 2007 09:45:36 +0100 (CET) Subject: CMake (was More about x-packages) In-Reply-To: References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: Am 22.12.07, 11:37 -0800 schrieb Alan W. Irwin: > On 2007-12-22 10:09+0100 Kai-Uwe Behrmann wrote: > > > CMake feels not like unix: > > (1) no make uninstall target by default as with autotools > > (2) no environment variables > > (3) no config.site scripts(?) > > (4) omitting the fun of posix scripting > > These comments (which I have numbered for clarity) should be answered. > > (1) is true, but see > http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F > for an easy alternative using install_manifest.txt. I'd emphasise 'by default' as we will see many projects comming witout a 'uninstall' target much more potentially smearing the file system. With autotools one could almost rely on a cleaned system, of course with caution. > (2) CMake has complete support for environment variables. There are standard > CMake-specific environment variables it interprets which are documented at > http://www.cmake.org/Wiki/CMake_Useful_Variables Furthermore, from within > the CMake environment you can get and set arbitrary environment variables. Ok, most variables you pointed out I'd consider useful are there. Still I cant see a reason to omit the common place CC/CXX/CFLAGS/CXXFLAGS... variables. > (3) Not sure exactly what you mean here, but you can tailor cmake to your > exact needs using the cmake -C option. Autoconf generated configure scripts support inclusion of a host site script to plug into the configure process. -C is leaving the established rule again, at least provides the same functionality. > (4) You can specifically run any command you like (including shell scripts) > at cmake (configuration) time using the execute_process CMake command. As I > noted before, full scripting is also available at build time from within the > Makefile generated by CMake. Oh my apologise, I had overseen this. > > One question: What is the difference of installing Cmake in opposite to > > MinGW in order to compile a software project? > > MinGW with MSYS and MinGW without MSYS are two possible windows platforms. > CMake can be used to help build software on both those platforms. Autotools > can be used to build software on MinGW but MSYS is required in that case. What is the advantage of CMake <-> autotools on MS systems? Just the nmake target for a expectedly cryptic, on the provided nmake side, compilation inside VC++? Remembering the unix Makefiles, at least me would like to see a nmake example first before doing any testing. Ok, with your arguments you gave, in my eyes, more of the hidden unix face back. The order of magnitude speedup for CMake is a apple with oranges comparision. What remains is a reported advantage over, in my eyes, obsolete libtool, with later harder debugging than autotools. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org From daniel at fooishbar.org Sun Dec 23 00:54:05 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 23 Dec 2007 08:54:05 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> <20071222210254.GA27087@fooishbar.org> Message-ID: <20071223085405.GB27087@fooishbar.org> On Sat, Dec 22, 2007 at 04:02:06PM -0800, Alan W. Irwin wrote: > On 2007-12-22 21:02-0000 Daniel Stone wrote: >> Yes, real libraries are good, but they won't work for the X case due to >> design that assumes everything's linked into the same final object, and >> also due to the fact that they're, well, not real libraries. We don't >> make API guarantees for internals. > > I would appreciate your comments on the following idea, but please be gentle > if I have wandered beyond my depth. :-) > > The idea is to directly replace a convenience library (a collection of > compiled objects according to > http://sourceware.org/autobook/autobook/autobook_92.html) by a real static > library which is private to X. Of course, assuming the SO modules will need > to be linked to that static library, the static library has to be compiled > with the same compile flags (e.g., -fPIC) used to create the SO modules. > Then I understand that the linking of the SO module with the static library > proceeds by copying the required code from the static library and placing it > in the SO with no necessity of installing the static library or letting its > internals be exposed. There may be some additional linking options required > to keep the API of the copied static library code within the SO private. But > if my overall mental model of the linking issues is correct, then the above > idea should work. Furthermore, implementing it with CMake would be > straightforward so that lack of convenience library support would no longer > be a CMake deal breaker for X. Which .so modules? I'm talking about the convenience libraries within the X server at the moment, which all get linked into the final Xorg/Xephyr/etc binaries (handwaving past the loadable module case). And again, maybe I'm missing something, but it does look vastly like we're missing the point, and reinventing convenience libraries in a pretty stunningly roundabout fashion. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jrfonseca at tungstengraphics.com Sun Dec 23 03:19:17 2007 From: jrfonseca at tungstengraphics.com (=?ISO-8859-1?Q?Jos=E9_Fonseca?=) Date: Sun, 23 Dec 2007 11:19:17 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: <20071223085405.GB27087@fooishbar.org> References: <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> <20071222210254.GA27087@fooishbar.org> <20071223085405.GB27087@fooishbar.org> Message-ID: On 12/23/07, Daniel Stone wrote: > On Sat, Dec 22, 2007 at 04:02:06PM -0800, Alan W. Irwin wrote: > > On 2007-12-22 21:02-0000 Daniel Stone wrote: > >> Yes, real libraries are good, but they won't work for the X case due to > >> design that assumes everything's linked into the same final object, and > >> also due to the fact that they're, well, not real libraries. We don't > >> make API guarantees for internals. > > > > I would appreciate your comments on the following idea, but please be gentle > > if I have wandered beyond my depth. :-) > > > > The idea is to directly replace a convenience library (a collection of > > compiled objects according to > > http://sourceware.org/autobook/autobook/autobook_92.html) by a real static > > library which is private to X. Of course, assuming the SO modules will need > > to be linked to that static library, the static library has to be compiled > > with the same compile flags (e.g., -fPIC) used to create the SO modules. > > Then I understand that the linking of the SO module with the static library > > proceeds by copying the required code from the static library and placing it > > in the SO with no necessity of installing the static library or letting its > > internals be exposed. There may be some additional linking options required > > to keep the API of the copied static library code within the SO private. But > > if my overall mental model of the linking issues is correct, then the above > > idea should work. Yes, I agree this is the way to go in respect to supporting convenience libraries in CMake. > > Furthermore, implementing it with CMake would be > > straightforward so that lack of convenience library support would no longer > > be a CMake deal breaker for X. It can and reportedly has been made to work on Linux systems (the best attempt I found so far was in the bug report link I emailed before, but there are a few more on the mailing list), but it is not that straightforward since it implies dealing with some CMake internals, which are not guaranteed to be preserved across versions. For those who care for portability to non-unix platforms it is even more difficult to accomplish. > Which .so modules? I'm talking about the convenience libraries within > the X server at the moment, which all get linked into the final > Xorg/Xephyr/etc binaries (handwaving past the loadable module case). > And again, maybe I'm missing something, but it does look vastly like > we're missing the point, and reinventing convenience libraries in a > pretty stunningly roundabout fashion. Daniel, if a library will be linked into an executable, and not a SO, then it is not referred as a "convenience library". It is just a regular static library, and CMake handles those fine. "Convinience libraries" are temporary libraries that will be linked into SOs and will not be released by themselves. The problems with these convenience libraries is that: a) linking a static library into a SO is not guaranteed to work, unless the static library was compiled with the proper compilation flags, and b) it does not fit into CMake's general approach for libraries quite well. Jos? From daniel at fooishbar.org Sun Dec 23 03:38:03 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 23 Dec 2007 11:38:03 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: References: <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> <20071222210254.GA27087@fooishbar.org> <20071223085405.GB27087@fooishbar.org> Message-ID: <20071223113803.GA3302@fooishbar.org> On Sun, Dec 23, 2007 at 11:19:17AM +0000, Jos? Fonseca wrote: > On 12/23/07, Daniel Stone wrote: > > Which .so modules? I'm talking about the convenience libraries within > > the X server at the moment, which all get linked into the final > > Xorg/Xephyr/etc binaries (handwaving past the loadable module case). > > And again, maybe I'm missing something, but it does look vastly like > > we're missing the point, and reinventing convenience libraries in a > > pretty stunningly roundabout fashion. > > Daniel, if a library will be linked into an executable, and not a SO, > then it is not referred as a "convenience library". It is just a > regular static library, and CMake handles those fine. Yes, I'm aware. > "Convinience libraries" are temporary libraries that will be linked > into SOs and will not be released by themselves. The problems with > these convenience libraries is that: a) linking a static library into > a SO is not guaranteed to work, unless the static library was compiled > with the proper compilation flags, and b) it does not fit into CMake's > general approach for libraries quite well. Right. At the moment, I'm not talking about linking static libraries into shared objects (Debian people tend to have a better appreciation than most of the problems inherent here), nor am I talking about shipping static libraries. I'm talking about the convenince libraries (of which there are over 112) in the server, which are compiled once, never installed, and then linked multiple times into every server[0]. How does CMake solve this problem, apart from 'badly'? Having to hack CMake internals to support convenience libraries and do things very non-portably sounds about as good as, well, having to hack automake internals to get rid of libtool for shared objects. Cheers, Daniel [0]: Yes, some of these are linked into .so's which are later dynamically loaded by Xorg. Imagine Xorg doesn't exist and that we're talking about KDrive, and then we'll cross the dynamic bridge when we come to it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From harryrat at postnuklear.de Sun Dec 23 04:19:11 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Sun, 23 Dec 2007 13:19:11 +0100 Subject: Kdrive - linux/keyboard.c Message-ID: <200712231319.11996.harryrat@postnuklear.de> Hi there! I am looking to get Xfbdev working with the keyboard driver, using "-keybd keyboard" option Some strange behaviour of the Xserver led me to do some superficial debugging. It looks like the keyboard driver also reacts on touchscreen events! This is really wierd... The initial problem is: when using above driver, and closing an X app, the display turns black with underscore cursor in the left corner, starting X apps doesn't do anything...when tapping the touchscreen, it finally returns to the checkered X background or started X app and operation state is back normal... when terminating an X app following keyboard function sequence is processed: - keyboard disable - keyboard init - keyboard enable and here is where X "hangs", inside the enable function the keyboard driver waits for input, flushing the input buffer with read() ... actually it doesn't react on keyboard input at that stage, only touchscreen Any ideas? Or am I totally missing something? Greez, Harry From pierre at archlinux.de Sun Dec 23 04:39:46 2007 From: pierre at archlinux.de (Pierre Schmitz) Date: Sun, 23 Dec 2007 13:39:46 +0100 Subject: xf86-video-intel does not detect tv-out Message-ID: <200712231339.46886.pierre@archlinux.de> Hi all, I tired to connect a TV to my notebook yesterday. It's a Toshib Satellite L10 with Intel 852GM. Using the latest intel driver xrandr does not even detect a TV output: > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024 > VGA disconnected (normal left inverted right x axis y axis) > LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) > 304mm x 228mm 1024x768 61.3*+ 60.0 > 800x600 60.3 > 640x480 59.9 > TMDS disconnected (normal left inverted right x axis y axis) VGA and LVDS is working well. But there is no TV; on the other hand a TMDS (DVI?) is detected which is not really there. Something like "xrandr --verbose --output TV" just does nothing. I have also tried the old i810 driver. It does not detect the TV either but one could "repair" this by setting the option "DevicePresence" (which is not known by the new driver anymore). But I would like to use the new one because of xrandr 1.2 and PAL support. i810 only produces a corrupted greyscale picture. I am using the following package versions: > kernel26 2.6.23.12-3 > xf86-video-intel 2.2.0-1 > xorg-server 1.4.0.90-2 I have also uploaded some interestring logfiles like xorg.log, dmesg etc.: http://users.archlinux.de/~pierre/tmp/xf86-video-intel+tv/ Do you have any idea who I could get this working? It does not seem to be a hardware problem; i810 partially works and of course windows does not have any problems :-(. Pierre -- http://www.archlinux.de From heavytull at hotmail.com Sun Dec 23 04:59:57 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Sun, 23 Dec 2007 12:59:57 +0000 Subject: radeon dual head In-Reply-To: <200712231319.11996.harryrat@postnuklear.de> References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: I'm trying to configure my Xserver to get working as th dual head mode on my laptop.it's a 1280x800 flat screen and the extra monitor is a 1440x900the specific config lines are as follows:Section "Monitor" Identifier "My Monitor" HorizSync 30-48 VertRefresh 60EndSectionSection "Monitor" Identifier "Extra Mon" HorizSync 31.5-67.5 VertRefresh 75EndSectionSection "Screen" Identifier "Screen 1" Device "** ATI Radeon (generic) [radeon]" Monitor "My Monitor" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1280x800" "800x600" ViewPort 0 0 EndSubsectionEndSectionSection "Screen" Identifier "Screen 2" Device "** ATI Radeon (generic) [radeon]" Monitor "Extra Mon" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1440x900" ViewPort 0 0 EndSubsectionEndSectionSection "ServerLayout" Identifier "Simple Layout" Screen "Screen 1" Screen "Screen 2" LeftOf "Screen1"...EndSectionbut it doesn't work as expected, the extra monitor display seems to be assigned a 600x800 resolution and show a part of the desktop but can slip on the whole desktop when the pointer reaches an end of the screen.While the main screen of the laptop is assigned the correct resolution.the output of the Xorg.log is as follows:(==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 23 13:18:44 2007(==) Using config file: "/etc/X11/xorg.conf"(==) ServerLayout "Simple Layout"(**) |-->Screen "Screen 1" (0)(**) | |-->Monitor "My Monitor"(**) | |-->Device "** ATI Radeon (generic) [radeon]"(**) |-->Screen "Screen 2" (1)(**) | |-->Monitor "Extra Mon"(**) | |-->Device "** ATI Radeon (generic) [radeon]"(EE) Screen Screen1 doesn't exist: deleting placementWhile when the xorg.conf file is configured for a single head everything is OK. _________________________________________________________________ Fancy some celeb spotting? https://www.celebmashup.com From jrfonseca at tungstengraphics.com Sun Dec 23 07:16:26 2007 From: jrfonseca at tungstengraphics.com (=?ISO-8859-1?Q?Jos=E9_Fonseca?=) Date: Sun, 23 Dec 2007 15:16:26 +0000 Subject: [xorg] Re: CMake (was More about x-packages) In-Reply-To: <20071223113803.GA3302@fooishbar.org> References: <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> <20071222210254.GA27087@fooishbar.org> <20071223085405.GB27087@fooishbar.org> <20071223113803.GA3302@fooishbar.org> Message-ID: On 12/23/07, Daniel Stone wrote: > > "Convinience libraries" are temporary libraries that will be linked > > into SOs and will not be released by themselves. The problems with > > these convenience libraries is that: a) linking a static library into > > a SO is not guaranteed to work, unless the static library was compiled > > with the proper compilation flags, and b) it does not fit into CMake's > > general approach for libraries quite well. > > Right. At the moment, I'm not talking about linking static libraries > into shared objects (Debian people tend to have a better appreciation > than most of the problems inherent here), nor am I talking about > shipping static libraries. I'm talking about the convenince libraries > (of which there are over 112) in the server, which are compiled once, > never installed, and then linked multiple times into every server[0]. > How does CMake solve this problem, apart from 'badly'? I'm not very familiar with KDrive, but the situation that you describe (static libraries, statically linked into many executables, and never installed) poses no problem to CMake AFAIK. You can decide with CMake which libraries get or not installed. Furthermore, CMake makes it easy to cope with many static libraries, since whenever you specify that a static library shall be linked, CMake automatically links all the recursive dependencies of that library (static or dynamic). > Having to hack > CMake internals to support convenience libraries and do things very > non-portably sounds about as good as, well, having to hack automake > internals to get rid of libtool for shared objects. That's quite a true statement. And that situation will surely arise if/when you cross the "dynamic bridge" you mention below. CMake has portability going for it, but it is by no mean one-size-fits-all solution, especially because portability implies compromises. And there's then all sort of problems that will only be noticed when one actually tries to use it... If it's worth it or not for Xorg to switch from autotools to CMake is a something that I don't really feel entitled to say. But if X.Org doesn't care for non-unix portability (and I mostly mean Windows here) then there isn't that much to be gained by switching to an unfamiliar build system as CMake. > Cheers, > Daniel > > [0]: Yes, some of these are linked into .so's which are later > dynamically loaded by Xorg. Imagine Xorg doesn't exist and that > we're talking about KDrive, and then we'll cross the dynamic bridge > when we come to it. Jos? From vignatti at c3sl.ufpr.br Sun Dec 23 07:40:03 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Sun, 23 Dec 2007 13:40:03 -0200 Subject: Kdrive - linux/keyboard.c In-Reply-To: <200712231319.11996.harryrat@postnuklear.de> References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: <476E8153.1070307@c3sl.ufpr.br> Harald Radke escreveu: > Hi there! > > I am looking to get Xfbdev working with the keyboard driver, using "-keybd > keyboard" option > > Some strange behaviour of the Xserver led me to do some superficial debugging. > It looks like the keyboard driver also reacts on touchscreen events! This is > really wierd... > > The initial problem is: when using above driver, and closing an X app, the > display turns black with underscore cursor in the left corner, starting X > apps doesn't do anything...when tapping the touchscreen, it finally returns > to the checkered X background or started X app and operation state is back > normal... > > when terminating an X app following keyboard function sequence is processed: > > - keyboard disable > - keyboard init > - keyboard enable > > and here is where X "hangs", inside the enable function the keyboard driver > waits for input, flushing the input buffer with read() ... actually it > doesn't react on keyboard input at that stage, only touchscreen > > > Any ideas? Or am I totally missing something? Any problem in use the evdev driver? IIRC it's in a better state than keyboard. Cheers, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From vignatti at c3sl.ufpr.br Sun Dec 23 08:08:16 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Sun, 23 Dec 2007 14:08:16 -0200 Subject: VGA arbiter: removing RAC In-Reply-To: <18282.28773.32601.996308@hermes.suse.de> References: <47699F21.8000001@c3sl.ufpr.br> <20071219231239.GF29049@britannica.bec.de> <4769BACE.7090307@c3sl.ufpr.br> <18282.28773.32601.996308@hermes.suse.de> Message-ID: <476E87F0.6020503@c3sl.ufpr.br> Hi Egbert, Egbert Eich escreveu: > Tiago Vignatti writes: > > And yes, unfortunately we will need to keep the RAC module together with > > the VGA arbiter inside Xorg for some time due the portability of Xorg. > > Probably let autoconf set if Xorg needs RAC or the arbiter depending the > > OS would be fine and easy to do. > > Why unfortunately? > > I would think it should be possible to share a lot of code between > the DDX part that deals with the arbiter and RAC itself. A lot of > ideas that went into RAC have not been implemented in the arbiter. Yes, to be fair the X arbiter implementation wraps all the functions that deals with VGA things in the same way RAC does. But what kind of ideas specifically are you talking that is not implemented in the arbiter? > > The arbiter takes care of resource enabling and disabling and acts > as a broker between different processes - the latter is something > the broker inside the Xserver cannot do. > This however is not all of RAC. The code in the Xserver decides which > resources actually need to be disabled depending on if the device > actually decodes VGA or not. > VGA decoding can be disabled on some devices while they will still > identify themselves as VGA devices in PCI config space - so this is > something the driver has to set. Yes, the currently arbiter implementation already exports a function to be set at PreInit time, in the drivers side. > Furthermore it decides if VGA resources are actually needed for a > specific operation. > This provides the opportunity for a lot of optimization. This also we stolen from RAC. We can set some flags telling what kind of operation is needed depending on the chipset. > > For platforms that don't provide an arbiter inside the kernel a > comparable functionality could be put into a user land broker. This is a good idea. Thanks for the tip, Egbert. Moreover, we trying to evaluate some experiments regarding the VGA (e.g., the burden of a single-head uses the arbiter, a multi-head using the arbiter versus multihead using RAC, etc). I'll share this all with the community as soon as possible. > I may have missed where the DDX bits of this VGA arbiter are developed. I have to push this all to fd.o but for now you can see what's going on here: - Kernel module: git-clone http://www.inf.ufpr.br/ribas/repos/vga-module.git - User space library: git-clone http://www.inf.ufpr.br/ribas/repos/libvgaaccess.git - X implementation: git-clone http://www.inf.ufpr.br/ribas/repos/xserver.git Thanks, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From daniel at fooishbar.org Sun Dec 23 08:56:59 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sun, 23 Dec 2007 16:56:59 +0000 Subject: Kdrive - linux/keyboard.c In-Reply-To: <200712231319.11996.harryrat@postnuklear.de> References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: <20071223165659.GB3302@fooishbar.org> On Sun, Dec 23, 2007 at 01:19:11PM +0100, Harald Radke wrote: > when terminating an X app following keyboard function sequence is processed: > > - keyboard disable > - keyboard init > - keyboard enable > > and here is where X "hangs", inside the enable function the keyboard driver > waits for input, flushing the input buffer with read() ... actually it > doesn't react on keyboard input at that stage, only touchscreen Honestly, just remove that line. It's broken. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From lope.vega at yahoo.com Sun Dec 23 12:09:51 2007 From: lope.vega at yahoo.com (Lope De Vega) Date: Sun, 23 Dec 2007 12:09:51 -0800 (PST) Subject: Trying to grab Super_L Message-ID: <390188.20889.qm@web45511.mail.sp1.yahoo.com> Hi list, I'm trying to make a little window manager stand on it's own feet, which I'm doing through xlib, though I've come into troubles already. My problem is that I wanted to be able to depoly a menu upon a Super_L key-press event --fortunately, no application out there seems to make use of it--so I wouldn't need to program taskbars and the like. I wanted this to happen indepently of the window which had the focus at that time, which is were I'm having problems. How I'm doing it is, the wm starts up, and it looks wheter the Super_L key alone is defined within the modifier map, if not, it will insert it. Then I just query the window's tree (XQueryTree), and register each window seen, grab the Super_L key on them, and not much more by now. This works ok when the keypress is seen within the root window, but not for example when seen within an xterm. This is how my ~/.xinitrc file looks like: "xterm & ~/wm/src/wm". I've been trying different things such like playing arround changing client's windows attributes, though whatever I do, xterm always "swallows" this keypress. So I'd really appreciate if somebody could make some comment on this. Merry Christmas. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From alexdeucher at gmail.com Sun Dec 23 12:37:40 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Sun, 23 Dec 2007 15:37:40 -0500 Subject: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: On Dec 23, 2007 7:59 AM, Jethro Tull wrote: > > I'm trying to configure my Xserver to get working as th dual head mode on my laptop.it's a 1280x800 flat screen and the extra monitor is a 1440x900the specific config lines are as follows:Section "Monitor" Identifier "My Monitor" HorizSync 30-48 VertRefresh 60EndSectionSection "Monitor" Identifier "Extra Mon" HorizSync 31.5-67.5 VertRefresh 75EndSectionSection "Screen" Identifier "Screen 1" Device "** ATI Radeon (generic) [radeon]" Monitor "My Monitor" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1280x800" "800x600" ViewPort 0 0 EndSubsectionEndSectionSection "Screen" Identifier "Screen 2" Device "** ATI Radeon (generic) [radeon]" Monitor "Extra Mon" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1440x900" ViewPort > 0 0 EndSubsectionEndSectionSection "ServerLayout" Identifier "Simple Layout" Screen "Screen 1" Screen "Screen 2" LeftOf "Screen1"...EndSectionbut it doesn't work as expected, the extra monitor display seems to be assigned a 600x800 resolution and show a part of the desktop but can slip on the whole desktop when the pointer reaches an end of the screen.While the main screen of the laptop is assigned the correct resolution.the output of the Xorg.log is as follows:(==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 23 13:18:44 2007(==) Using config file: "/etc/X11/xorg.conf"(==) ServerLayout "Simple Layout"(**) |-->Screen "Screen 1" (0)(**) | |-->Monitor "My Monitor"(**) | |-->Device "** ATI Radeon (generic) [radeon]"(**) |-->Screen "Screen 2" (1)(**) | |-->Monitor "Extra Mon"(**) | |-->Device "** ATI Radeon (generic) [radeon]"(EE) Screen Screen1 doesn't exist: deleting placementWhile when the xorg.conf file is configured > for a single head everything is OK. Your mailer seems to have messed up your message. What version of the driver are you using? The 6.7.19x series only supports multi-head via xrandr. zaphod mode is not suppored. If you want to use zaphod mode, you'll need either 6.6.3 or ati git master. Alex From bart at jukie.net Sun Dec 23 12:02:04 2007 From: bart at jukie.net (Bart Trojanowski) Date: Sun, 23 Dec 2007 15:02:04 -0500 Subject: Geode LX DDC freeze in emulator when executing OUTW 0x20 Message-ID: <20071223200204.GA30545@jukie.net> Hi, I have been looking into an issue we have been seeing on several GeodeLX based embedded devices when using Linux 2.6.21-2.6..23, xorg 1.3.0.0 and xorg-video-amd 2.7.7.X. I have CC'ed the other people involved. The investigation started on Ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051 It then continued on the new xorg-geode-driver mailing list: http://lists.x.org/archives/xorg-driver-geode/2007-December/000002.html I have traced through the code effected and discovered the following: * xorg-video-amd DDC probe calls into vbeDoEDID() * The X86EMU runs through thousands of VGA BIOS instructions, some of them being IO operations, but freezes when it tries to execute outl(0x20, 00000018) * On the x86 port 0x20 is responsible for initializing the first PIC (interrupt controller). After that instruction nothing else executes, probably because it messes up the (Linux) kernel's scheduler. There is more info here for those interested... http://lists.x.org/archives/xorg-driver-geode/2007-December/000074.html http://lists.x.org/archives/xorg-driver-geode/2007-December/000075.html We have no control over what the BIOS tries to execute but we can prevent the emulator from causing bad things to happen when the BIOS has bugs (or is expecting to be running only DOS). Under the belief that access to certain ports should not be permitted under any circumstances I propose this patch: http://www.jukie.net/~bart/patches/xorg-server/20071222/0001-X86EMU-blacklist-I-O-port-20-for-INT-10-emulation.patch The patch has a black list, but maybe a white list is more appropriate. I have also seen a lot of accesses to port 0. Port 0 is the first DMA channel. X has no guarantee that it's the only consumer of this peripheral, and thus could cause really bad memory corruptions by racing with other software (most likely the kernel). For the purpose of the DMA agents, X86EMU should probably emulate DMA's with memcpy(). I would like to continue working on this, but I need some advice from the xorg-core team. What direction would you like me to take this work? Should I perhaps form a framework for blacklisting arbitrary instructions and test them from X86EMU_exec() before executing the actual handler? Thanks for reading, and seasons greetings. -Bart -- WebSig: http://www.jukie.net/~bart/sig/ From patrakov at gmail.com Sun Dec 23 21:28:25 2007 From: patrakov at gmail.com (Alexander E. Patrakov) Date: Mon, 24 Dec 2007 10:28:25 +0500 Subject: Geode LX DDC freeze in emulator when executing OUTW 0x20 In-Reply-To: <20071223200204.GA30545@jukie.net> References: <20071223200204.GA30545@jukie.net> Message-ID: <476F4379.8000406@gmail.com> [sorry for a possible duplicate] Bart Trojanowski wrote: > We have no control over what the BIOS tries to execute but we can > prevent the emulator from causing bad things to happen when the BIOS > has bugs (or is expecting to be running only DOS). > > Under the belief that access to certain ports should not be permitted > under any circumstances I propose this patch: > > http://www.jukie.net/~bart/patches/xorg-server/20071222/0001-X86EMU-blacklist-I-O-port-20-for-INT-10-emulation.patch While the blacklist is certainly useful, I am afraid it just hides the second bug: the BIOS chooses a different path under the emulator than without it (i.e., through vm86). Access to port 20 is likely to crash Windows XP, too, and this simply cannot happen for marketing reasons. Thus: could you please verify if the bug also exists with vm86-based int10 module? -- Alexander E. Patrakov From patrakov at gmail.com Sun Dec 23 21:58:01 2007 From: patrakov at gmail.com (Alexander E. Patrakov) Date: Mon, 24 Dec 2007 10:58:01 +0500 Subject: Geode LX DDC freeze in emulator when executing OUTW 0x20 In-Reply-To: <476F4379.8000406@gmail.com> References: <20071223200204.GA30545@jukie.net> <476F4379.8000406@gmail.com> Message-ID: <476F4A69.9030202@gmail.com> I wrote: > Bart Trojanowski wrote: > >> We have no control over what the BIOS tries to execute but we can >> prevent the emulator from causing bad things to happen when the BIOS >> has bugs (or is expecting to be running only DOS). >> >> Under the belief that access to certain ports should not be permitted >> under any circumstances I propose this patch: >> >> http://www.jukie.net/~bart/patches/xorg-server/20071222/0001-X86EMU-blacklist-I-O-port-20-for-INT-10-emulation.patch > > While the blacklist is certainly useful, I am afraid it just hides the second > bug: the BIOS chooses a different path under the emulator than without it (i.e., > through vm86). Access to port 20 is likely to crash Windows XP, too, and this > simply cannot happen for marketing reasons. To avoid misinterpretation: I don't have a Geode card, so the above is just a guess, not a bug report. > Thus: could you please verify if the bug also exists with vm86-based int10 module? And one more question: doesn't it make sense (if possible at all) to add the same port blacklist to the vm86-based int10 module? -- Alexander E. Patrakov From kamalneet.s at samsung.com Sun Dec 23 21:45:02 2007 From: kamalneet.s at samsung.com (KAMALNEET SINGH) Date: Mon, 24 Dec 2007 05:45:02 +0000 (GMT) Subject: [xorg] Re: CMake (was More about x-packages) Message-ID: <0JTJ003URHB21H@ms13.samsung.com> An HTML attachment was scrubbed... URL: From vehemens at verizon.net Wed Dec 19 14:37:01 2007 From: vehemens at verizon.net (vehemens) Date: Wed, 19 Dec 2007 14:37:01 -0800 Subject: XACE-SELINUX branch ready for merge Message-ID: <200712191437.02325.vehemens@verizon.net> >Eamon Walsh wrote: >> The XACE-SELINUX branch contains a rework of the devPrivates system used >> to store private data, a new version of the XACE (X Access Control >> Extension) security hook framework, a protocol name registry, a reworked >> XC-SECURITY extension (disabled by default), and an under-development >> SELinux extension (also disabled by default). >> >> I've been running GNOME on it without any issues, all the major drivers >> compile against it and I've tested with vesa and intel (and continue to >> rebuild and test). I've put up the complete patchset with some basic >> annotations at >> http://people.freedesktop.org/~ewalsh/xace_selinux_merge_patch/ >> >> The total damage from the patch is 398 files changed, 7785 >> insertions(+), 7604 deletions(-). I think it's about ready to land on >> master; I have been working on the branch for 18 months and will >> continue working in master. >> >> Comments? >> > >I merged it. Time to recompile everything! Please notify me of any >issues right away. > >Peter (and other branch developers): if you need help resolving >conflicts when syncing up with master, point me to your branch head and >I will help out. It seems to of broken GLX on my amd64 system. My i386 system works fine. glxinfo gives: libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x54 Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 0 8 8 8 0 24 0 0 0 0 0 0 0 None 0x54 32 tc 0 32 0 r . . 0 8 8 8 0 24 0 0 0 0 0 0 0 None Recompiling the X11 and GL libraries don't help. I first noticed it with commits. good 8a8239f2e21795602fcff5281833b350e6b2a286 bad a3f7f7b60e391e6106f5db40b3fe5fbc67ccd836 I narrowed it down to commits: good a125ce4a84f5fb5934fefebd7cfb22a83180874d bad 86b2e59bfb79bd042a13c35fbb4ccecec576f629 From shuiguomayi at gmail.com Mon Dec 24 00:44:11 2007 From: shuiguomayi at gmail.com (=?gb2312?B?c2h1aWd1b21heWlAZ21haWwuY29t?=) Date: Mon, 24 Dec 2007 16:44:11 +0800 Subject: =?gb2312?B?aG93IHRvIHVuaW5zdGFsbCBrZHJpdmUvdGlueXg=?= Message-ID: <476f715b.0a528c0a.6241.ffffb56c@mx.google.com> hello everyone ,i read this document http://www.pps.jussieu.fr/~jch/software/kdrive.html, and find Xfbdev KDrive server and Xvesa KDrive server have no accelerated , but i wanna have accelerate in my notebook, i don't know which "define xxxx" should i add to host.def? where can i find these infomation? another question, how could i uninstall kdrive if i do not want it stay in my linux? The command "#make uninstall" have no effect. ????????shuiguomayi at gmail.com ????????shuiguomayi at gmail.com ??????????2007-12-24 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vignatti at c3sl.ufpr.br Mon Dec 24 06:03:16 2007 From: vignatti at c3sl.ufpr.br (Tiago Vignatti) Date: Mon, 24 Dec 2007 12:03:16 -0200 Subject: how to uninstall kdrive/tinyx In-Reply-To: <476f715b.0a528c0a.6241.ffffb56c@mx.google.com> References: <476f715b.0a528c0a.6241.ffffb56c@mx.google.com> Message-ID: <476FBC24.1010607@c3sl.ufpr.br> shuiguomayi at gmail.com escreveu: > hello everyone ,i read this document > http://www.pps.jussieu.fr/~jch/software/kdrive.html, and find Xfbdev > KDrive server and Xvesa KDrive server have no accelerated , but i wanna > have accelerate in my notebook, i don't know which "define xxxx" should > i add to host.def? where can i find these infomation? another question, > how could i uninstall kdrive if i do not want it stay in my linux? The > command "#make uninstall" have no effect. > No, this page is *very* old. You have to rely on the last bits of kdrive. Please, follow here: http://xorg.freedesktop.org/wiki/ModularDevelopersGuide Cheers, -- Tiago Vignatti C3SL - Centro de Computa??o Cient?fica e Software Livre www.c3sl.ufpr.br From heavytull at hotmail.com Mon Dec 24 06:07:47 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Mon, 24 Dec 2007 14:07:47 +0000 Subject: FW: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: From: heavytull at hotmail.com To: alexdeucher at gmail.com Subject: RE: radeon dual head Date: Mon, 24 Dec 2007 14:07:01 +0000 The following is a format corrected of the message i posted yesterday: >>.................start I'm trying to configure my Xserver to get working as th dual head mode on my laptop. it's a 1280x800 flat screen and the extra monitor is a 1440x900. the specific config lines are as follows: Section "Monitor" Identifier "My Monitor" HorizSync 30-48 VertRefresh 60 EndSection Section "Monitor" Identifier "Extra Mon" HorizSync 31.5-67.5 VertRefresh 75 EndSection Section"Screen" Identifier "Screen 1" Device "** ATI Radeon (generic) [radeon]" Monitor "My Monitor" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1280x800" "800x600" ViewPort 0 0 EndSubsection EndSection Section "Screen" Identifier "Screen 2" Device "** ATI Radeon (generic) [radeon]" Monitor "Extra Mon" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1440x900" ViewPort 0 0 EndSubsection EndSection Section "ServerLayout" Identifier "Simple Layout" Screen "Screen 1" Screen "Screen 2" LeftOf "Screen1" ...EndSection but it doesn't work as expected, the extra monitor display seems to be assigned a 600x800 resolution and shows a part of the desktop but can slip on the whole desktop when the pointer reaches an end of the screen. While the main screen of the laptop is assigned the correct resolution. the output of the Xorg.log is as follows: (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 23 13:18:44 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout"(**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "** ATI Radeon (generic) [radeon]" (**) |-->Screen "Screen 2" (1) (**) | |-->Monitor "Extra Mon" (**) | |-->Device "** ATI Radeon (generic) [radeon]" (EE) Screen Screen1 doesn't exist: deleting placement While when the xorg.conf file is configured for a single head everything is OK. >>....................end > > Your mailer seems to have messed up your message. bloody hotmail >What version of the > driver are you using? how do you check this information? >The 6.7.19x series only supports multi-head via > xrandr. zaphod mode is not suppored. If you want to use zaphod mode, > you'll need either 6.6.3 or ati git master. > > Alex by the way i would like to know if this is normal tthat drm is never loaded. when i load it manually it says: root at slack12:/home/slackkk# modprobe drm FATAL: Error inserting drm (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot allocate memory but the X interface works well, Open GL screen savers are Ok, some are slow. google earth is not hard accelerated at all, it is awfully slow and runs th CPU at 100% Think you know your TV, music and film? Try Search Charades! _________________________________________________________________ Fancy some celeb spotting? https://www.celebmashup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bamboo9527 at gmail.com Mon Dec 24 06:51:28 2007 From: bamboo9527 at gmail.com (antilife) Date: Mon, 24 Dec 2007 22:51:28 +0800 Subject: xf86PostMotionEvent caused server aborting Message-ID: <003a01c8463c$80db58e0$3201a8c0@lgw3dce7a2070b> I wrote a x driver, it read some data from serial line, then i parse data and post some events: xf86PostButtonEvent work well: ////////////////////////////////////////// if (priv->zzzOldPush != push) { int delta; delta = push - priv->zzzOldPush; if (priv->zzzOldPush != push) { xf86PostButtonEvent(device, 1, 1, (delta > 0), 0, 3, x, y, pressure); } } ////////////////////////////////////////// but xf86PostButtonEvent can not work, it caused server aborting: ///////////////////////////////////////// if ( (priv->zzzOldX != x) || (priv->zzzOldY != y)) { xf86PostMotionEvent(device, 1, 0, 3, x, y, pressure); } ///////////////////////////////////////// anybody who can help me? many thanks!!!!!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexdeucher at gmail.com Mon Dec 24 08:36:41 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 24 Dec 2007 11:36:41 -0500 Subject: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: On Dec 24, 2007 9:07 AM, Jethro Tull wrote: > > The following is a format corrected of the message i posted yesterday: > > >>.................start > > I'm trying to configure my Xserver to get working as th dual head mode on my > laptop. > it's a 1280x800 flat screen and the extra monitor is a 1440x900. > the specific config lines are as follows: > Section "Monitor" > Identifier "My Monitor" > HorizSync 30-48 > VertRefresh 60 > EndSection > > Section "Monitor" > Identifier "Extra Mon" > HorizSync 31.5-67.5 > VertRefresh 75 > EndSection > Section"Screen" > Identifier "Screen 1" > Device "** ATI Radeon (generic) [radeon]" > Monitor "My Monitor" > DefaultDepth 24 > Subsection "Display" > Depth 24 Modes "1280x800" "800x600" > ViewPort 0 0 > EndSubsection > EndSection > Section "Screen" > Identifier "Screen 2" > Device "** ATI Radeon (generic) [radeon]" > Monitor "Extra Mon" > DefaultDepth 24 > Subsection "Display" > Depth 24 > Modes "1440x900" > ViewPort 0 0 > EndSubsection > EndSection > Section "ServerLayout" > Identifier "Simple Layout" > Screen "Screen 1" > Screen "Screen 2" LeftOf "Screen1" > ...EndSection > > but it doesn't work as expected, the extra monitor display seems to be > assigned a 600x800 resolution and shows a part of the desktop but can slip > on the whole desktop when the pointer reaches an end of the screen. While > the main screen of the laptop is assigned the correct resolution. > > the output of the Xorg.log is as follows: > (==) Log file: "/var/log/Xorg.0.log", > Time: Sun Dec 23 13:18:44 2007 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "Simple Layout"(**) |-->Screen "Screen 1" (0) > (**) | |-->Monitor "My Monitor" > (**) | |-->Device "** ATI Radeon (generic) [radeon]" > (**) |-->Screen "Screen 2" (1) > (**) | |-->Monitor "Extra Mon" > (**) | |-->Device "** ATI Radeon (generic) [radeon]" > (EE) Screen Screen1 doesn't exist: deleting placement > > While when the xorg.conf file is configured for a single head everything is > OK. > > >>....................end > > > > > Your mailer seems to have messed up your message. > bloody hotmail > > >What version of the > > driver are you using? > how do you check this information? Take a look at your xorg log (usually /var/log/Xorg.0.log). you should see a line like this: (II) ATI: ATI driver wrapper (version 6.7.197) for chipsets: mach64, rage128, radeon > > >The 6.7.19x series only supports multi-head via > > xrandr. zaphod mode is not suppored. If you want to use zaphod mode, > > you'll need either 6.6.3 or ati git master. As I said zaphod (screen based multi-head) only works with git master. if you are using an older version take a look at xrandr: http://www.intellinuxgraphics.com/dualhead.html > > > > Alex > > > > by the way i would like to know if this is normal tthat drm is never loaded. > > when i load it manually it says: > > root at slack12:/home/slackkk# modprobe drm > FATAL: Error inserting drm > (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot allocate > memory > > > > but the X interface works well, Open GL screen savers are Ok, some are slow. > google earth is not hard accelerated at all, it is awfully slow and runs th > CPU at 100% In that case I suspect the drm isn't loaded and you are probably using SW rendering. Take a look at your xorg log or the output of glxinfo to be sure. Alex From sergio at sergiomb.no-ip.org Mon Dec 24 18:48:25 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Tue, 25 Dec 2007 02:48:25 +0000 Subject: i915tex commits on mesa_7_0_branch Message-ID: <1198550906.5937.20.camel@localhost.localdomain> Hi , Michel , I saw some commits on mesa_7_0_branch for i915tex. I'm wondering how we test or use i915tex instead i915 ? How do you test i915tex ? we have Mesa/drm/i915tex-compat for necessary drm , but the Intel video drive 2.2.0, don't had any code to call i915tex instead i915. The patch above revert the commit of unification of i915 with i915tex on video Intel, is suficiente to have i915tex working again ? On 5 of November, I had test i915tex on this way, but textures aren't working correctly ... , but since you are working on it I'd like try again, in the appropriate way, which I don't know what it is. Happy Christmas, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: i915texrevert.diff Type: text/x-patch Size: 2368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From gordon.jin at intel.com Mon Dec 24 19:49:03 2007 From: gordon.jin at intel.com (Jin, Gordon) Date: Tue, 25 Dec 2007 11:49:03 +0800 Subject: xf86-video-intel does not detect tv-out In-Reply-To: <200712231339.46886.pierre@archlinux.de> References: <200712231339.46886.pierre@archlinux.de> Message-ID: <70F95043FD1E5B40B3872B8784B9EB75E43456@pdsmsx414.ccr.corp.intel.com> Pierre Schmitz wrote: > Hi all, > > I tired to connect a TV to my notebook yesterday. It's a Toshib > Satellite L10 with Intel 852GM. Using the latest intel driver xrandr > does not even detect a TV output: > >> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024 >> VGA disconnected (normal left inverted right x axis y axis) >> LVDS connected 1024x768+0+0 (normal left inverted right x axis y >> axis) 304mm x 228mm 1024x768 61.3*+ 60.0 >> 800x600 60.3 >> 640x480 59.9 >> TMDS disconnected (normal left inverted right x axis y axis) > > VGA and LVDS is working well. But there is no TV; on the other hand a > TMDS (DVI?) is detected which is not really there. > > Something like "xrandr --verbose --output TV" just does nothing. I > have also tried the old i810 driver. It does not detect the TV either > but one > could "repair" this by setting the option "DevicePresence" (which is > not known by the new driver anymore). But I would like to use the new > one because of xrandr 1.2 and PAL support. i810 only produces a > corrupted greyscale picture. > > I am using the following package versions: > >> kernel26 2.6.23.12-3 >> xf86-video-intel 2.2.0-1 >> xorg-server 1.4.0.90-2 > > I have also uploaded some interestring logfiles like xorg.log, dmesg > etc.: http://users.archlinux.de/~pierre/tmp/xf86-video-intel+tv/ > > Do you have any idea who I could get this working? It does not seem > to be a hardware problem; i810 partially works and of course windows > does not have any problems :-(. > > Pierre It looks like the TV out is not detected at all. Could you file a bug on https://bugs.freedesktop.org to track down? Thanks Gordon From heavytull at hotmail.com Tue Dec 25 06:40:14 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Tue, 25 Dec 2007 14:40:14 +0000 Subject: FW: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: From: heavytull at hotmail.com To: alexdeucher at gmail.com Subject: RE: radeon dual head Date: Tue, 25 Dec 2007 14:39:28 +0000 > Date: Mon, 24 Dec 2007 11:36:41 -0500 > From: alexdeucher at gmail.com > To: heavytull at hotmail.com; xorg at lists.freedesktop.org > Subject: Re: radeon dual head > > >What version of the > > > driver are you using? > > how do you check this information? > > Take a look at your xorg log (usually /var/log/Xorg.0.log). you > should see a line like this: > (II) ATI: ATI driver wrapper (version 6.7.197) for chipsets: mach64, > rage128, radeon > #less /var/log/Xorg.0.log .... (II) LoadModule: "radeon" (II) Loading /usr/X11R6/lib/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.3.0, module version = 4.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) LoadModule: "ati" (II) Loading /usr/X11R6/lib/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.3.0, module version = 6.6.192 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) ATI: ATI driver wrapper (version 6.6.192) for chipsets: mach64, rage128, radeon (II) Primary Device is: PCI 01:00:0 (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Reloading /usr/X11R6/lib/modules/drivers//radeon_drv.so .... > > > > >The 6.7.19x series only supports multi-head via > > > xrandr. zaphod mode is not suppored. If you want to use zaphod mode, > > > you'll need either 6.6.3 or ati git master. > > As I said zaphod (screen based multi-head) only works with git master. > if you are using an older version take a look at xrandr: > http://www.intellinuxgraphics.com/dualhead.html > > > > > > > by the way i would like to know if this is normal tthat drm is never loaded. > > > > when i load it manually it says: > > > > root at slack12:/home/slackkk# modprobe drm > > FATAL: Error inserting drm > > (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot allocate > > memory > > > > > > > > but the X interface works well, Open GL screen savers are Ok, some are slow. > > google earth is not hard accelerated at all, it is awfully slow and runs th > > CPU at 100% > > In that case I suspect the drm isn't loaded and you are probably using > SW rendering. Take a look at your xorg log or the output of glxinfo > to be sure. > #less /var/log/Xorg.0.log .... (II) RADEON(0): PCIE card detected drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -19 drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -19 ..... user at slack12:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 (1.5 Mesa 6.5.2) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > Alex Sounds like? How many syllables? Guess and win prizes with Search Charades! _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From heavytull at hotmail.com Tue Dec 25 06:40:15 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Tue, 25 Dec 2007 14:40:15 +0000 Subject: FW: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: From: heavytull at hotmail.com To: alexdeucher at gmail.com Subject: RE: radeon dual head Date: Tue, 25 Dec 2007 14:39:28 +0000 > Date: Mon, 24 Dec 2007 11:36:41 -0500 > From: alexdeucher at gmail.com > To: heavytull at hotmail.com; xorg at lists.freedesktop.org > Subject: Re: radeon dual head > > >What version of the > > > driver are you using? > > how do you check this information? > > Take a look at your xorg log (usually /var/log/Xorg.0.log). you > should see a line like this: > (II) ATI: ATI driver wrapper (version 6.7.197) for chipsets: mach64, > rage128, radeon > #less /var/log/Xorg.0.log .... (II) LoadModule: "radeon" (II) Loading /usr/X11R6/lib/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.3.0, module version = 4.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) LoadModule: "ati" (II) Loading /usr/X11R6/lib/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.3.0, module version = 6.6.192 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.2 (II) ATI: ATI driver wrapper (version 6.6.192) for chipsets: mach64, rage128, radeon (II) Primary Device is: PCI 01:00:0 (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Reloading /usr/X11R6/lib/modules/drivers//radeon_drv.so .... > > > > >The 6.7.19x series only supports multi-head via > > > xrandr. zaphod mode is not suppored. If you want to use zaphod mode, > > > you'll need either 6.6.3 or ati git master. > > As I said zaphod (screen based multi-head) only works with git master. > if you are using an older version take a look at xrandr: > http://www.intellinuxgraphics.com/dualhead.html > > > > > > > by the way i would like to know if this is normal tthat drm is never loaded. > > > > when i load it manually it says: > > > > root at slack12:/home/slackkk# modprobe drm > > FATAL: Error inserting drm > > (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot allocate > > memory > > > > > > > > but the X interface works well, Open GL screen savers are Ok, some are slow. > > google earth is not hard accelerated at all, it is awfully slow and runs th > > CPU at 100% > > In that case I suspect the drm isn't loaded and you are probably using > SW rendering. Take a look at your xorg log or the output of glxinfo > to be sure. > #less /var/log/Xorg.0.log .... (II) RADEON(0): PCIE card detected drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -19 drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -19 ..... user at slack12:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 (1.5 Mesa 6.5.2) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > Alex Sounds like? How many syllables? Guess and win prizes with Search Charades! _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at sphinx.net.ru Tue Dec 25 07:54:35 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Tue, 25 Dec 2007 18:54:35 +0300 Subject: Problems with evdev driver for keyboard Message-ID: <87wsr2lqh0.fsf@sphinx.net.ru> Greetings! I'm trying to make my MS Natural 4000 keyboard work in X using `evdev(4x)` driver. In my xorg.conf, i've got the following related Section "InputDevice" Identifier "MSnek" Driver "evdev" Option "Phys" "*input0" Option "vendor" "0x045e" Option "product" "0x00db" Option "XkbRules" "xorg" Option "XkbModel" "evdev" Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys" Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" EndSection Section "InputDevice" Identifier "MSnek1" Driver "evdev" Option "Phys" "*input1" Option "vendor" "0x045e" Option "product" "0x00db" Option "XkbRules" "xorg" Option "XkbModel" "evdev" Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys" Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" EndSection Server layout section follows: Section "ServerLayout" Identifier "Main Layout" Screen "Screen1" InputDevice "MSnek" "CoreKeyboard" InputDevice "MSnek1" "SendCoreEvents" InputDevice "Mouse1" EndSection Two sections are needed as this keyboard actually acts as two event devices (according to /proc/bus/input/devices). The bad thing is that keyboard stops working *right after* I type in my login/password in GDM (that's for G desktop manager, I don't use GNOME though). I *can* still zap the X server with Ctrl-Alt-Backspace or switch to terminals using Ctrl-Alt-F1. That make thing even weirder. The `Xorg.0.log` ends with the following lines which seem to be relevant: (II) evdev brain: Rescanning devices (1). (**) Option "CoreKeyboard" (**) MSnek-usb-0000:00:07.2-1/input0: always reports core events (**) Option "XkbRules" "xorg" (**) Option "XkbModel" "evdev" (**) Option "XkbLayout" "us,ru" (**) Option "XkbVariant" ",winkeys" (**) Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" (II) evdev brain: Rescanning devices (2). (**) Option "SendCoreEvents" (**) MSnek1-usb-0000:00:07.2-1/input1: always reports core events (II) MSnek1-usb-0000:00:07.2-1/input1: Found 1 absolute axes. (II) MSnek1-usb-0000:00:07.2-1/input1: Configuring as pointer. (II) MSnek1-usb-0000:00:07.2-1/input1: Found 1 relative axes. (II) MSnek1-usb-0000:00:07.2-1/input1: Configuring as pointer. (**) MSnek1-usb-0000:00:07.2-1/input1: HWHEELRelativeAxisButtons: 6 7. (II) MSnek1-usb-0000:00:07.2-1/input1: Found 17 mouse buttons (**) MSnek1-usb-0000:00:07.2-1/input1: Configuring 1 absolute axes. (II) MSnek1-usb-0000:00:07.2-1/input1: Checking button DIGI_STYLUS (330) (II) MSnek1-usb-0000:00:07.2-1/input1: Checking bit 330 (EE) MSnek1-usb-0000:00:07.2-1/input1: AbsoluteTouch: 'DIGI_Touch' does not exist. (**) MSnek1-usb-0000:00:07.2-1/input1: Configuring in Absolute mode. (**) MSnek1-usb-0000:00:07.2-1/input1: Configuring 1 relative axes. (II) MSnek1-usb-0000:00:07.2-1/input1: Configured 19 mouse buttons (**) Option "XkbRules" "xorg" (**) Option "XkbModel" "evdev" (**) Option "XkbLayout" "us,ru" (**) Option "XkbVariant" ",winkeys" (**) Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" (**) Mouse1: Device: "/dev/input/mouse0" (==) Mouse1: Protocol: "Auto" (**) Option "CorePointer" (**) Mouse1: always reports core events (**) Option "Device" "/dev/input/mouse0" (==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Mouse1: ZAxisMapping: buttons 4 and 5 (**) Mouse1: Buttons: 9 (**) Mouse1: Sensitivity: 1 (II) evaluating device (Mouse1) (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (II) evaluating device (MSnek1-usb-0000:00:07.2-1/input1) (II) XINPUT: Adding extended input device "MSnek1-usb-0000:00:07.2-1/input1" (type: KEYBOARD) (II) evaluating device (MSnek-usb-0000:00:07.2-1/input0) (II) XINPUT: Adding extended input device "MSnek-usb-0000:00:07.2-1/input0" (type: KEYBOARD) (II) evaluating device (evdev brain) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (**) MSnek1-usb-0000:00:07.2-1/input1: 1 valuators. (**) evdev_btn.c (166): Registering 19 buttons. (II) MSnek1-usb-0000:00:07.2-1/input1: Init (II) MSnek-usb-0000:00:07.2-1/input0: Init (--) Mouse1: PnP-detected protocol: "ExplorerPS/2" (II) Mouse1: ps2EnableDataReporting: succeeded (II) MSnek1-usb-0000:00:07.2-1/input1: On (II) MSnek-usb-0000:00:07.2-1/input0: On (II) evdev brain: Rescanning devices (3). Could not init font path element /usr/share/fonts/OTF, removing from list! (II) MSnek1-usb-0000:00:07.2-1/input1: Off (II) MSnek-usb-0000:00:07.2-1/input0: Off (Font error in 3rd last line is not relevant). It seems to mean that my two evdev devices get switched off by the driver! Am I right? Is that somehow connected with "Pass" option mentioned in `evdev(4x)` man page? I've tried to specify different sets of "Pass" options in my `InputDevice` sections of `xorg.conf` file, but that failed all the same. I've also attempted to use `Option "Device"` instead of vendor&product id's to specify direct path to event devices in `/dev/input/` representing keyboard, but that didn't help either. I could just use a `keyboard` driver instead of `evdev`, but then X applications (namely `xev(1)`) do not see several of special keys on my keyboard. On the other hand, using `showkey(1)` in terminal (not X) indicates that _all_ of keyboard events actually get recieved by my machine, including funky zooming throttle. The only problem is to make keybord work in X with event interface. I'm using 2.6.24-rc6 version of Linux kernel which *has* support for HID and my keyboard so that I do not need to apply special kernel patches to make Linux see all the keyboard events. Output of `X -version` follows: X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-rc6-git1 i686 Current Operating System: Linux storm 2.6.24-rc6-git1 #7 Tue Dec 25 10:46:49 MSK 2007 i686 Build Date: 25 December 2007 02:40:37AM I'm using xf86-input-evdev of version 1.1.5. I'd be happy to post more relevant information or logs if needed or recompile *something* with debug flags enabled. I'm also not so sure if this is an appropriate newsgroup to post this question in; please point me to relevant newsgroup or mailing list in that case. -- Happy Hacking. Dmitry Dzhus http://sphinx.net.ru ? From fatih at pardus.org.tr Tue Dec 25 14:14:11 2007 From: fatih at pardus.org.tr (Fatih =?utf-8?q?A=C5=9F=C4=B1c=C4=B1?=) Date: Wed, 26 Dec 2007 00:14:11 +0200 Subject: [PATCH] Config: Fix a memory leak Message-ID: <200712260014.11424.fatih@pardus.org.tr> Adds a missing xfree. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Config-Fix-a-memory-leak.patch Type: text/x-diff Size: 651 bytes Desc: not available URL: From fatih at pardus.org.tr Tue Dec 25 14:14:29 2007 From: fatih at pardus.org.tr (Fatih =?utf-8?q?A=C5=9F=C4=B1c=C4=B1?=) Date: Wed, 26 Dec 2007 00:14:29 +0200 Subject: [PATCH] Config: Don't forget to add xkb_rules option Message-ID: <200712260014.29530.fatih@pardus.org.tr> It seems that xkb_rules option is forgotten to be added into config. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Config-Don-t-forget-to-add-xkb_rules-option.patch Type: text/x-diff Size: 753 bytes Desc: not available URL: From olafBuddenhagen at gmx.net Tue Dec 25 11:32:35 2007 From: olafBuddenhagen at gmx.net (olafBuddenhagen at gmx.net) Date: Tue, 25 Dec 2007 20:32:35 +0100 Subject: CMake In-Reply-To: <476C38CD.50305@cs.berkeley.edu> References: <20071219021926.oxah6qn8uodckgg8@webmail.conectiva.com.br> <476A744F.6000202@gentoo.org> <476A7DC2.4020306@mandriva.com.br> <1198162373.25977.14.camel@blackadder> <476A88F0.40104@mandriva.com.br> <20071221031735.cqb6rpw6v5pt8oks@webmail.conectiva.com.br> <20071221200940.GA14359@fooishbar.org> <476C38CD.50305@cs.berkeley.edu> Message-ID: <20071225193232.GA511@alien.local> Hi, On Fri, Dec 21, 2007 at 02:06:05PM -0800, Russell Sears wrote: > 3) The recommended cmake configuration keeps all the autogenerated > makefiles / binary objects, etc out of the source directories. On large > projects, this is particularly nice if you have the foresight to have a > build-opt/ and build-dbg/ directory. Then you don't need to do "make > clean" (or mess with patches) to switch between optimized and debug > builds. (I would be surprised if there is no way to get > automake/autoconf to do this too...) Autotools don't have a "recommended" configuration here, because that's up to the user to decide. A good tool should not prescribe the user how to work. (That's what also makes git a superior tool, for example.) Unless the build system is seriouly broken, autotooled applications support both modes equally well. -antrik- From jcristau at debian.org Tue Dec 25 17:14:29 2007 From: jcristau at debian.org (Julien Cristau) Date: Wed, 26 Dec 2007 02:14:29 +0100 Subject: [PATCH] Config: Fix a memory leak In-Reply-To: <200712260014.29530.fatih@pardus.org.tr> <200712260014.11424.fatih@pardus.org.tr> References: <200712260014.29530.fatih@pardus.org.tr> <200712260014.11424.fatih@pardus.org.tr> Message-ID: <20071226011426.GA13438@patate.is-a-geek.org> On Wed, Dec 26, 2007 at 00:14:11 +0200, Fatih A??c? wrote: > Adds a missing xfree. On Wed, Dec 26, 2007 at 00:14:29 +0200, Fatih A??c? wrote: > It seems that xkb_rules option is forgotten to be added into config. Thanks, pushed. Cheers, Julien From mailinglists at who-t.net Tue Dec 25 19:47:49 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 26 Dec 2007 14:17:49 +1030 Subject: Problems with evdev driver for keyboard In-Reply-To: <87wsr2lqh0.fsf@sphinx.net.ru> References: <87wsr2lqh0.fsf@sphinx.net.ru> Message-ID: <4771CEE5.6000500@who-t.net> Dmitry Dzhus wrote: > Output of `X -version` follows: > > X.Org X Server 1.4.0.90 > Release Date: 5 September 2007 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 2.6.24-rc6-git1 i686 > Current Operating System: Linux storm 2.6.24-rc6-git1 #7 Tue Dec 25 10:46:49 MSK 2007 i686 > Build Date: 25 December 2007 02:40:37AM > > I'm using xf86-input-evdev of version 1.1.5. AFAIK these two are incompatible. server 1.4 requires evdev 1.2 or greater Cheers, Peter From mailinglists at who-t.net Tue Dec 25 19:59:01 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Wed, 26 Dec 2007 14:29:01 +1030 Subject: xf86PostMotionEvent caused server aborting In-Reply-To: <003a01c8463c$80db58e0$3201a8c0@lgw3dce7a2070b> References: <003a01c8463c$80db58e0$3201a8c0@lgw3dce7a2070b> Message-ID: <4771D185.6040903@who-t.net> antilife wrote: > ////////////////////////////////////////// > but xf86PostButtonEvent can not work, it caused server aborting: > ///////////////////////////////////////// > if ( (priv->zzzOldX != x) || (priv->zzzOldY != y)) { > xf86PostMotionEvent(device, 1, 0, 3, x, y, pressure); > } > ///////////////////////////////////////// > anybody who can help me? many thanks!!!!!!!! Please attach or paste your Xorg.0.log file, otherwise it's mostly guesswork. What server version do you use? Cheers, Peter From alexdeucher at gmail.com Tue Dec 25 21:09:11 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Wed, 26 Dec 2007 00:09:11 -0500 Subject: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: On Dec 25, 2007 9:38 AM, Jethro Tull wrote: > > > > > Date: Mon, 24 Dec 2007 11:36:41 -0500 > > From: alexdeucher at gmail.com > > To: heavytull at hotmail.com; xorg at lists.freedesktop.org > > Subject: Re: radeon dual head > > > > > >What version of the > > > > driver are you using? > > > how do you check this information? > > > > Take a look at your xorg log (usually /var/log/Xorg.0.log). you > > should see a line like this: > > (II) ATI: ATI driver wrapper (version 6.7.197) for chipsets: mach64, > > rage128, radeon > > > #less /var/log/Xorg.0.log > .... > (II) LoadModule: "radeon" > (II) Loading /usr/X11R6/lib/modules/drivers//radeon_drv.so > (II) Module radeon: vendor="X.Org Foundation" > compiled for 1.3.0, module version = 4.2.0 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 1.2 > (II) LoadModule: "ati" > (II) Loading /usr/X11R6/lib/modules/drivers//ati_drv.so > (II) Module ati: vendor="X.Org Foundation" > compiled for 1.3.0, module version = 6.6.192 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 1.2 > > > (II) ATI: ATI driver wrapper (version 6.6.192) for chipsets: mach64, > rage128, radeon > (II) Primary Device is: PCI 01:00:0 > (II) Loading sub module "radeon" > (II) LoadModule: "radeon" > (II) Reloading /usr/X11R6/lib/modules/drivers//radeon_drv.so > .... > you don't want the 6.6.19x series. that was a stepping stone series on the way to randr support. > > > > > > >The 6.7.19x series only supports multi-head via > > > > xrandr. zaphod mode is not suppored. If you want to use zaphod mode, > > > > you'll need either 6.6.3 or ati git master. > > > > As I said zaphod (screen based multi-head) only works with git master. > > if you are using an older version take a look at xrandr: > > http://www.intellinuxgraphics.com/dualhead.html > > > > > > > > > > > > by the way i would like to know if this is normal tthat drm is never > loaded. > > > > > > when i load it manually it says: > > > > > > root at slack12:/home/slackkk# modprobe drm > > > FATAL: Error inserting drm > > > (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot > allocate > > > memory > > > > > > > > > > > > but the X interface works well, Open GL screen savers are Ok, some are > slow. > > > google earth is not hard accelerated at all, it is awfully slow and runs > th > > > CPU at 100% > > > > In that case I suspect the drm isn't loaded and you are probably using > > SW rendering. Take a look at your xorg log or the output of glxinfo > > to be sure. > > > > #less /var/log/Xorg.0.log > .... > (II) RADEON(0): PCIE card detected > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: drmOpenMinor returns 9 > drmOpenByBusid: drmGetBusid reports > drmOpenDevice: node name is /dev/dri/card1 > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: Open failed > drmOpenByBusid: drmOpenMinor returns -19 > drmOpenDevice: node name is /dev/dri/card2 > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: Open failed > drmOpenByBusid: drmOpenMinor returns -19 > ..... yup looks like the drm isn't loaded. check the output of lsmod and dmesg. Alex From joel.bosveld at gmail.com Tue Dec 25 22:18:22 2007 From: joel.bosveld at gmail.com (Joel Bosveld) Date: Wed, 26 Dec 2007 15:18:22 +0900 Subject: Multi Pointer X MPX Build problem In-Reply-To: <47612FF9.6030400@tungstengraphics.com> References: <001301c83cef$b4007bc0$15b2a8c0@fuckup> <4760DDE7.60006@who-t.net> <47612FF9.6030400@tungstengraphics.com> Message-ID: <6e4dc1c0712252218i2969ce10t696e41cc443188e3@mail.gmail.com> On Dec 13, 2007 10:13 PM, Roland Scheidegger wrote: > Peter Hutterer wrote: > > Nikolas D?rfler wrote: > >> gcc -DHAVE_DIX_CONFIG_H -DNO_HW_ONLY_EXTS -DNO_MODULE_EXTS > >> -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes > >> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs > >> -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > >> -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE > >> -I/tmp/modular//include -I/tmp/modular//include/pixman-1 > >> -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 > >> -I/usr/lib/dbus-1.0/include -I../../include -I../../include > >> -I../../Xext -I../../composite -I../../damageext -I../../xfixes > >> -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage > >> -I../../render -I../../randr -I../../fb -g -O2 -o Xvfb InitInput.o > >> InitOutput.o dpmsstubs.o stubs.o miinitext.o > >> ../../fb/.libs/libfb.a ../../xfixes/.libs/libxfixes.a > >> ../../Xext/.libs/libXext.a ../../dbe/.libs/libdbe.a > >> ../../XTrap/.libs/libxtrap.a ../../record/.libs/librecord.a > >> ../../GL/glx/.libs/libglx.a ../../GL/mesa/.libs/libGLcore.a > >> ../../render/.libs/librender.a ../../randr/.libs/librand > > r. > >> a ../../damageext/.libs/libdamageext.a > >> ../../miext/damage/.libs/libdamage.a > >> ../../miext/shadow/.libs/libshadow.a ../../Xi/.libs/libXi.a > >> ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a > >> ../../composite/.libs/libcomposite.a ../../dix/.libs/libxpstubs.a > >> ../../os/.libs/libcwrapper.a libfbcmap.a ../../dix/.libs/libdix.a > >> ../../config/libconfig.a ../../mi/.libs/libmi.a > >> ../../os/.libs/libos.a -L/tmp/modular//lib -L/lib > >> /tmp/modular//lib/libXfont.so /usr/lib/libfreetype.so > >> /tmp/modular//lib/libXau.so /tmp/modular/lib/libfontenc.so -lz > >> /tmp/modular/lib/libpixman-1.so /usr/lib/libhal.so > >> /usr/lib/libusb.so -ldl -luuid -ldbus-1 > >> /tmp/modular//lib/libXdmcp.so -lcrypto -lm -lrt -Wl,--rpath > >> -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib -Wl,--rpath > >> -Wl,/tmp/modular//lib -Wl,--rpath -Wl,/tmp/modular/lib > >> ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function > >> `__glXDisp_ProgramParameter4fvNV': > >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5190: > >> undefined reference to `CALL_ProgramParameter4fvNV' > >> ../../GL/glx/.libs/libglx.a(indirect_dispatch.o): In function > >> `__glXDisp_ProgramParameter4dvNV': > >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch.c:5181: > >> undefined reference to `CALL_ProgramParameter4dvNV' > >> ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function > >> `__glXDispSwap_ProgramParameter4fvNV': > >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5346: > >> undefined reference to `CALL_ProgramParameter4fvNV' > >> ../../GL/glx/.libs/libglx.a(indirect_dispatch_swap.o): In function > >> `__glXDispSwap_ProgramParameter4dvNV': > >> /home/doerflen/mpx/xserver/GL/glx/indirect_dispatch_swap.c:5337: > >> undefined reference to `CALL_ProgramParameter4dvNV' > > > > tbh, I don't know if that is really an issue with MPX. I get the same > > error (I usually --disable-glx on configure). Not quite sure how to > > fix it, pulling master stuff now. If it happens there too, I'll have > > to defer to someone else :) > > > > These CALL_ProgramParameter4xyNV functions no longer exist (due to > changes which eliminated the corresponding gl functions, since they are > identical to some ARB functions). Regenerating the server glx protocol > (which was done for xserver master) from the mesa master branch (in the > glapi directory) should probably fix this (or pull in the glx changes > from xserver master). > > Roland > > I was wondering if the master branch of xserver was going to be merged into mpx again any time soon (as, if I understand correctly, this will fix the problem, and I tried merging it myself, but ended up with a fair number of conflicts, which I have (almost) no idea how to resolve (and if master is going to be merged into mpx again soon, I won't bother trying to resolve them, I will just wait)) Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: From techservio at gmail.com Tue Dec 25 23:07:54 2007 From: techservio at gmail.com (paul paul) Date: Wed, 26 Dec 2007 12:07:54 +0500 Subject: Blurred fonts under the X.org + Mesa + DRI Message-ID: X.org and Mesa were installed (from git) over the fresh installation of LFS. The video-card is Radeon 9600 with proper driver settings in the xorg.conf (radeon). The X window starts properly. Direct rendering is enabled and glxgears shows ~3000fps. According to the log-file the r300_dri driver is actually loaded and this is why Open-GL and DRI are functioning properly, I guess. Yet a huge problem exists in the work of the window managers. (I tried IceWM and KDE3). That is: fonts (including labels, texts and menu items) are blurred (as if they were cross-hatched). Snapshot: http://www.myfilestash.com/userfiles/techservio/snapshot2.jpg. If the driver is set into the "vesa" mode, the letters are displayed properly, but the direct rendering is obviously not supported. It must be noted that in the case of KDE4, letters, in general, are visualized properly, but in the GTK-based applications letters are still blurred . Did anyone experienced the same problem? If so what is the solution (if any, in the case of Radeon 9600 video-card)? I also tried to use the proprietary ATI driver. After the driver was installed ("fglrx" in the xorg.conf), X did not start. The following error message was issued: (II) Loading /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so dlopen: /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so: undefined symbol: miZeroLineScreenIndex (EE) Failed to load /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so (II) UnloadModule: "fglrx" (EE) Failed to load module "fglrx" (loader failed, 7) Does any one know about the nature of this error message? -------------- next part -------------- An HTML attachment was scrubbed... URL: From macslow at bangang.de Wed Dec 26 00:37:33 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Wed, 26 Dec 2007 09:37:33 +0100 Subject: GLX_EXT_texture_from_pixmap working on GeForce 8800 but not on i965 Message-ID: <1198658253.12578.39.camel@HAL9000> Greetings everybody! While trying to get gtk-gl-offscreen-1 working on something different than a GeForce 8800 driven by nvidia's proprietary driver I ran into problems on the i965 (using the driver that comes with Ubuntu 7.10). Initially I did not assume having any problems with this as I have compiz, which is using GLX_EXT_texture_from_pixmap, running successfully on both systems (stock Ubuntu 7.10, nothing from Xorg git installed). In order to understand the involved parts better I wrote a pure X11/GLX program (see attached tarball and screenshot). This program works on the nvidia-system but not on the intel one. But on the nvidia-system it only works correctly and allows resizing when run under metacity. Under compiz I get a white window. As soon as I try to resize the window, while running under compiz, I get a BadAlloc-error ("insufficient resources for operation") for glXCreatePixmap() and the program exits. Another odd observations is the value I get back from glXGetFBConfigAttrib() when querying for the attribute GLX_BIND_TO_TEXTURE_TARGETS_EXT. What I get back is 0x000020DF (oddly enough this is also the value of GLX_FRONT_RIGHT_EXT defined in GL/glxext.h). Although I would expect any bit-wise combination of... #define GLX_TEXTURE_1D_BIT_EXT 0x00000001 #define GLX_TEXTURE_2D_BIT_EXT 0x00000002 #define GLX_TEXTURE_RECTANGLE_BIT_EXT 0x00000004 On the intel-system I just get 0x00000000 for every FBconfig I tried, which is also a bit strange as it would mean that no texture-target is supported for GLX_EXT_texture_from_pixmap. To add to my confusion is the fact that glXGetFBConfigAttrib() is meant to be supported only if GLX 1.3 or better is available. But on the i965 only GLX 1.2 is reported, but all the GLXFBConfig-related calls work. Any help on this issue is much appreciated! Best regards... Mirco "MacSlow" M?ller -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.png Type: image/png Size: 35380 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: x11-tfp-test.tar.bz2 Type: application/x-bzip-compressed-tar Size: 8055 bytes Desc: not available URL: From mail at sphinx.net.ru Wed Dec 26 00:44:11 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Wed, 26 Dec 2007 11:44:11 +0300 Subject: Problems with evdev driver for keyboard References: <87wsr2lqh0.fsf@sphinx.net.ru> <4771CEE5.6000500@who-t.net> Message-ID: <878x3hu9pg.fsf@sphinx.net.ru> Peter Hutterer writes: >> Output of `X -version` follows: >> >> X.Org X Server 1.4.0.90 >> >> I'm using xf86-input-evdev of version 1.1.5. > > AFAIK these two are incompatible. > server 1.4 requires evdev 1.2 or greater > > Cheers, > Peter I've updated my evdev to 1.2 version. The configuration broke as evdev'd advanced device matching (using vendor or product name fields) support was deleted [1] (I don't know why, that was such a cool feature) so I had to switch to dirty config using plain `"Device"` option: Section "InputDevice" Identifier "MSnek" Driver "evdev" Option "CoreKeyboard" Option "Device" "/dev/input/event3" Option "XkbRules" "xorg" Option "XkbModel" "evdev" Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys" Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" Option "Pass" "3" EndSection Section "InputDevice" Identifier "MSnek1" Driver "evdev" Option "SendCoreEvents" Option "Device" "/dev/input/event4" Option "XkbRules" "xorg" Option "XkbModel" "evdev" Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys" Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt" Option "Pass" "3" EndSection It's all the same though, see last lines of X.org log: (II) evaluating device (Mouse1) (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (II) evaluating device (MSnek1) (II) XINPUT: Adding extended input device "MSnek1" (type: KEYBOARD) (II) evaluating device (MSnek) (II) XINPUT: Adding extended input device "MSnek" (type: KEYBOARD) (**) MSnek1: 1 valuators. (**) MSnek1: Configuring in Absolute mode. (**) MSnek1: Registering 18 buttons. evdev: leds are 0x0 for device 3 (II) MSnek1: Init evdev: leds are 0x0 for device 4 (II) MSnek: Init (--) Mouse1: PnP-detected protocol: "ExplorerPS/2" (II) Mouse1: ps2EnableDataReporting: succeeded (II) MSnek1: On (II) MSnek: On (II) MSnek1: Off (II) MSnek: Off (II) Open ACPI successful (/var/run/acpid.socket) (II) Mouse1: ps2EnableDataReporting: succeeded (II) MSnek1: On (II) MSnek: On (II) MSnek1: Off (II) MSnek: Off (II) MSnek: Off (II) MSnek1: Off Evdev devices still get switched off. Now I also cannot even enter my username in display manager. [1]: http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=a0ea7363f51ff6c2bb81006b7220b7daa9ee9221 -- Happy Hacking. Dmitry Dzhus http://sphinx.net.ru ? From drago01 at gmail.com Wed Dec 26 02:50:34 2007 From: drago01 at gmail.com (drago01) Date: Wed, 26 Dec 2007 11:50:34 +0100 Subject: GLX_EXT_texture_from_pixmap working on GeForce 8800 but not on i965 In-Reply-To: <1198658253.12578.39.camel@HAL9000> References: <1198658253.12578.39.camel@HAL9000> Message-ID: <477231FA.5060907@gmail.com> Mirco M?ller wrote: > Greetings everybody! > > While trying to get gtk-gl-offscreen-1 working on something different > than a GeForce 8800 driven by nvidia's proprietary driver I ran into > problems on the i965 (using the driver that comes with Ubuntu 7.10). > > Initially I did not assume having any problems with this as I have > compiz, which is using GLX_EXT_texture_from_pixmap, running successfully > on both systems (stock Ubuntu 7.10, nothing from Xorg git installed). > > In order to understand the involved parts better I wrote a pure X11/GLX > program (see attached tarball and screenshot). > > This program works on the nvidia-system but not on the intel one. But > on the nvidia-system it only works correctly and allows resizing when > run under metacity. Under compiz I get a white window. As soon as I try > to resize the window, while running under compiz, I get a BadAlloc-error > ("insufficient resources for operation") for glXCreatePixmap() and the > program exits. > > Another odd observations is the value I get back from > glXGetFBConfigAttrib() when querying for the attribute > GLX_BIND_TO_TEXTURE_TARGETS_EXT. What I get back is 0x000020DF (oddly > enough this is also the value of GLX_FRONT_RIGHT_EXT defined in > GL/glxext.h). Although I would expect any bit-wise combination of... > > #define GLX_TEXTURE_1D_BIT_EXT 0x00000001 > #define GLX_TEXTURE_2D_BIT_EXT 0x00000002 > #define GLX_TEXTURE_RECTANGLE_BIT_EXT 0x00000004 > > On the intel-system I just get 0x00000000 for every FBconfig I tried, > which is also a bit strange as it would mean that no texture-target is > supported for GLX_EXT_texture_from_pixmap. > > To add to my confusion is the fact that glXGetFBConfigAttrib() is meant > to be supported only if GLX 1.3 or better is available. But on the i965 > only GLX 1.2 is reported, but all the GLXFBConfig-related calls work. > > Any help on this issue is much appreciated! > have you tryed setting LIBGL_ALWAYS_INDIRECT=1 before starting your app? From michael-olbrich at web.de Wed Dec 26 02:55:56 2007 From: michael-olbrich at web.de (Michael Olbrich) Date: Wed, 26 Dec 2007 11:55:56 +0100 Subject: Problems with evdev driver for keyboard In-Reply-To: <87wsr2lqh0.fsf@sphinx.net.ru> References: <87wsr2lqh0.fsf@sphinx.net.ru> Message-ID: <20071226105556.GA24284@creature.apm.etc.tu-bs.de> On Tue, Dec 25, 2007 at 06:54:35PM +0300, Dmitry Dzhus wrote: > The bad thing is that keyboard stops working *right after* I type in > my login/password in GDM (that's for G desktop manager, I don't use > GNOME though). I *can* still zap the X server with Ctrl-Alt-Backspace > or switch to terminals using Ctrl-Alt-F1. That make thing even > weirder. What WM are you using? I had similar problems when KDE changed the XkbModel to something other than evdev. michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mail at sphinx.net.ru Wed Dec 26 03:35:35 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Wed, 26 Dec 2007 14:35:35 +0300 Subject: Problems with evdev driver for keyboard References: <87wsr2lqh0.fsf@sphinx.net.ru> <20071226105556.GA24284@creature.apm.etc.tu-bs.de> Message-ID: <87ve6lsn7c.fsf@sphinx.net.ru> Michael Olbrich writes: > On Tue, Dec 25, 2007 at 06:54:35PM +0300, Dmitry Dzhus wrote: >> The bad thing is that keyboard stops working *right after* I type in >> my login/password in GDM (that's for G desktop manager, I don't use >> GNOME though). I *can* still zap the X server with Ctrl-Alt-Backspace >> or switch to terminals using Ctrl-Alt-F1. That make thing even >> weirder. > > What WM are you using? I had similar problems when KDE changed the > XkbModel to something other than evdev. I use wmii. Weird thing is that GNOME _could_ see the keyboard and *almost* all of the extra keys with 1.1.5 evdev driver. Now I've upgraded to 1.2.0 evdev and keyboard doesn't work with it at all (currently I've rolled back to `keyboard` driver with `XkbModel` set to `microsoftprousb` and some of extra keys work even in wmii out of the box). -- Happy Hacking. http://sphinx.net.ru ? From mail at sphinx.net.ru Wed Dec 26 03:58:36 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Wed, 26 Dec 2007 14:58:36 +0300 Subject: Problems with evdev driver for keyboard References: <87wsr2lqh0.fsf@sphinx.net.ru> <4771CEE5.6000500@who-t.net> <878x3hu9pg.fsf@sphinx.net.ru> Message-ID: <87r6h9sm4z.fsf@sphinx.net.ru> Dmitry Dzhus writes: > I've updated my evdev to 1.2 version. The configuration broke as evdev'd > advanced device matching (using vendor or product name fields) support > was deleted [1] (I don't know why, that was such a cool feature) so I > had to switch to dirty config using plain `"Device"` option: I guess I've definitely missed some really serious stuff introduced in xorg 1.4 and evdev 1.2. Seems like now HAL should be used to configure my keyboard, and it looks like a way more flexible solution than globbing features which used to be built in the evdev driver. It's a pity `evdev(4x)` documentation is way behind the actual code. I also wonder if HAL dependency will affect the portability of X server (and the whole X infrastructure). -- Happy Hacking. http://sphinx.net.ru ? From mail at sphinx.net.ru Wed Dec 26 07:37:10 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Wed, 26 Dec 2007 18:37:10 +0300 Subject: Problems with evdev driver for keyboard References: <87wsr2lqh0.fsf@sphinx.net.ru> <4771CEE5.6000500@who-t.net> <878x3hu9pg.fsf@sphinx.net.ru> <87r6h9sm4z.fsf@sphinx.net.ru> Message-ID: <873atpo4bd.fsf@sphinx.net.ru> Seems like I've managed to write appropriate policy files for HAL. In `/etc/hal/fdi/policy/x11-input.fdi`: evdev xorg evdev evdev ,winkeys us,ru grp:caps_toggle,grp_led:caps,compose:ralt HAL daemon set all the values correctly: ~ $ hal-find-by-capability --capability 'input.keyboard' /org/freedesktop/Hal/devices/usb_device_45e_db_noserial_if1_logicaldev_input /org/freedesktop/Hal/devices/usb_device_45e_db_noserial_if0_logicaldev_input ~ $ hal-device usb_device_45e_db_noserial_if0_logicaldev_input | grep xkb input.xkb.model = 'evdev' (string) input.xkb.rules = 'xorg' (string) input.xkb.layout = 'us,ru' (string) input.xkb.options = 'grp:caps_toggle,grp_led:caps,compose:ralt' (string) input.xkb.variant = ',winkeys' (string) ~ $ hal-device usb_device_45e_db_noserial_if0_logicaldev_input | grep x11 input.x11_driver = 'evdev' (string) (the same for the second event device) In `xorg.conf` I've deleted all `InputDevice` sections and removed all references to them in `ServerLayout` section. I've also added `AllowEmptyInput` option to `ServerFlags`. GDM loads, I enter username and in window manager keyboard isn't working again. `Xorg.0.log` ends with: (**) PS2++ Logitech Wheel Mouse: always reports core events (II) PS2++ Logitech Wheel Mouse: Found 3 relative axes. (II) PS2++ Logitech Wheel Mouse: Configuring as pointer. (II) PS2++ Logitech Wheel Mouse: Found 4 mouse buttons (II) PS2++ Logitech Wheel Mouse: Configured 7 mouse buttons. (II) XINPUT: Adding extended input device "PS2++ Logitech Wheel Mouse" (type: MOUSE) (**) PS2++ Logitech Wheel Mouse: 2 valuators. (**) PS2++ Logitech Wheel Mouse: Configuring in Absolute mode. (**) PS2++ Logitech Wheel Mouse: Registering 7 buttons. (II) PS2++ Logitech Wheel Mouse: Init (II) PS2++ Logitech Wheel Mouse: On (**) Microsoft Natural? Ergonomic Keyboard 4000: always reports core events (II) Microsoft Natural? Ergonomic Keyboard 4000: Found 1 absolute axes. (II) Microsoft Natural? Ergonomic Keyboard 4000: Configuring as pointer. (II) Microsoft Natural? Ergonomic Keyboard 4000: Found 1 relative axes. (II) Microsoft Natural? Ergonomic Keyboard 4000: Configuring as pointer. (**) Microsoft Natural? Ergonomic Keyboard 4000: Configuring 1 absolute axes. (II) Microsoft Natural? Ergonomic Keyboard 4000: Checking button DIGI_STYLUS (74) (II) Microsoft Natural? Ergonomic Keyboard 4000: Checking bit 330 (EE) Microsoft Natural? Ergonomic Keyboard 4000: AbsoluteTouch: 'DIGI_Touch' does not exist. (II) Microsoft Natural? Ergonomic Keyboard 4000: Found 1 mouse buttons (II) Microsoft Natural? Ergonomic Keyboard 4000: Configured 18 mouse buttons. (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us,ru" (**) Option "xkb_variant" ",winkeys" (II) XINPUT: Adding extended input device "Microsoft Natural? Ergonomic Keyboard 4000" (type: KEYBOARD) (**) Microsoft Natural? Ergonomic Keyboard 4000: 1 valuators. (**) Microsoft Natural? Ergonomic Keyboard 4000: Configuring in Absolute mode. (**) Microsoft Natural? Ergonomic Keyboard 4000: Registering 18 buttons. evdev: leds are 0x0 for device 3 (II) Microsoft Natural? Ergonomic Keyboard 4000: Init (II) Microsoft Natural? Ergonomic Keyboard 4000: On (**) Microsoft Natural? Ergonomic Keyboard 4000: always reports core events (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us,ru" (**) Option "xkb_variant" ",winkeys" (II) XINPUT: Adding extended input device "Microsoft Natural? Ergonomic Keyboard 4000" (type: KEYBOARD) evdev: leds are 0x0 for device 4 (II) Microsoft Natural? Ergonomic Keyboard 4000: Init (II) Microsoft Natural? Ergonomic Keyboard 4000: On evdev: leds are 0x0 for device 3 evdev: leds are 0x0 for device 4 evdev: leds are 0x0 for device 3 evdev: leds are 0x0 for device 4 evdev: leds are 0x0 for device 3 evdev: leds are 0x0 for device 4 (II) Microsoft Natural? Ergonomic Keyboard 4000: Off (II) Microsoft Natural? Ergonomic Keyboard 4000: Off (II) PS2++ Logitech Wheel Mouse: Off It's also weird that last line says something about `Mouse: Off` but my mouse works quite okay even after I've logged in (in GDM). Lot's of LED chit-chat is also noticeable. Is is a bug in `evdev(4x)` driver or I've just misconfigured something? -- Happy Hacking. http://sphinx.net.ru ? From yacek87 at gmail.com Wed Dec 26 08:39:20 2007 From: yacek87 at gmail.com (Jacek Jablonski) Date: Wed, 26 Dec 2007 17:39:20 +0100 Subject: Compal FL90+ HorizSync VertRefresh Message-ID: <8ae29cf10712260839s7960e208n2978c71766e82e87@mail.gmail.com> Hi! I have bought Compal FL90+ laptop, but I can't find HorizSync and VertRefresh values for LCD anywhere for xorg.conf. I have received some data from manufacturer: http://img296.imageshack.us/img296/6982/tableky0.jpg are those values saved anywhere here? Please help, Jacek From alexdeucher at gmail.com Wed Dec 26 09:17:10 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Wed, 26 Dec 2007 12:17:10 -0500 Subject: Compal FL90+ HorizSync VertRefresh In-Reply-To: <8ae29cf10712260839s7960e208n2978c71766e82e87@mail.gmail.com> References: <8ae29cf10712260839s7960e208n2978c71766e82e87@mail.gmail.com> Message-ID: On Dec 26, 2007 11:39 AM, Jacek Jablonski wrote: > Hi! > I have bought Compal FL90+ laptop, but I can't find HorizSync and > VertRefresh values for LCD anywhere for xorg.conf. I have received > some data from manufacturer: > http://img296.imageshack.us/img296/6982/tableky0.jpg > > are those values saved anywhere here? The limits and supported modes are usually available in the monitor's edid via ddc. Most drivers can query the edid and will use it when setting up the modes for that monitor. What hardware are you using? Alex From moseley at hank.org Wed Dec 26 09:56:47 2007 From: moseley at hank.org (Bill Moseley) Date: Wed, 26 Dec 2007 09:56:47 -0800 Subject: Full screen only uses part of screen Message-ID: <20071226175647.GB7980@hank.org> I have a few old iMacs with a ATI 3D Rage Pro 215GP (they are run as thin clients via LTSP). When I run "full screen" games (e.g. Tux Typing, or Tux Math) only a small part of the inner screen is used. Any tricks to get full screen to work? I've attached lspci out for the card and the xorg.conf that is auto-generated. Only significant error is: (EE) AIGLX: Screen 0 is not DRI capable 00:12.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "probe_sparse" # [] #Option "accel" # [] #Option "crt_display" # [] #Option "composite_sync" # [] #Option "hw_cursor" # [] #Option "force_pci_mode" # [] #Option "dma_mode" # #Option "agp_mode" # #Option "agp_size" # #Option "local_textures" # [] #Option "buffer_size" # #Option "mmio_cache" # [] #Option "test_mmio_cache" # [] #Option "panel_display" # [] #Option "reference_clock" # #Option "shadow_fb" # [] #Option "sw_cursor" # [] #Option "AccelMethod" # #Option "RenderAccel" # [] Identifier "Card0" Driver "ati" VendorName "ATI Technologies Inc" BoardName "3D Rage Pro 215GP" BusID "PCI:0:18:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Modes "1024x768" Viewport 0 0 Depth 24 EndSubSection EndSection Section "DRI" Mode 0666 EndSection -- Bill Moseley moseley at hank.org From elupus at ecce.se Wed Dec 26 10:40:59 2007 From: elupus at ecce.se (elupus) Date: Wed, 26 Dec 2007 19:40:59 +0100 Subject: [PATCH] LVDS quirk for AOPEN MINIPC with 965GM References: Message-ID: <1oni3jx1fwakg$.febr4ixnbohl$.dlg@40tude.net> On Thu, 13 Dec 2007 22:19:16 +0100, elupus wrote: > Hi, > > Current quirk fix for the aopen device doesn't get all. I'm wondering if > the second quirk is really correct, as it seem to be PCI bus information > not the subsystem information. 0x8086 is atleast that for me, but i may be > totally of. > > In either case, here is a duplication of the previous quirk for the 945, > but for the 965 instead. > > Not that this fixes anything at all for my non working tv out, but hey :). > Maybe i could dump the tv output registers somehow since everything works > while bios boots. > > Regards > Joakim Bump.. Here's the lspci data 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: AOPEN Inc. Unknown device 062d Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fdb00000 (64-bit, non-prefetchable) [size=1M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at ff00 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 3 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) Subsystem: AOPEN Inc. Unknown device 062d Flags: bus master, fast devsel, latency 0 Memory at fde00000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3 From irwin at beluga.phys.uvic.ca Wed Dec 26 12:10:01 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 26 Dec 2007 12:10:01 -0800 (PST) Subject: [xorg] Intel 2.2.1 release planning In-Reply-To: <200712131127.40293.jbarnes@virtuousgeek.org> References: <200712131127.40293.jbarnes@virtuousgeek.org> Message-ID: On 2007-12-13 11:27-0800 Jesse Barnes wrote: > I'm trying to put together a 2.2.1 Intel driver release (was hoping for > this week but that might not happen) given that we had at least a > couple of major regressions in 2.2 relative to 2.1.1. The blocker bug > is 13493, and I'm interested in hearing if there are any other major > regressions that should be on the list, so please reply to this message > or to me personally and I'll see that they're added. > > The main problems so far seem to be the Xv crasher (13108) and the pipe > enable bug (13196) I introduced while fixing a crash on 8xx chips for > the 2.2 release. > > We already know about the EXA performance problems people have been > seeing, but unfortunately those fixes won't be ready for this release. > However, XAA is still available, so you can use "AccelMethod" "XAA" in > your xorg.conf if needed. Is there any additional news to report about this planned release, Jesse? I was very happy that the previous X lockup I got for 2.2.0 (for my ASUS P5K-V g33 chipset without ADD2 card) was solved by an earlier and also your latest patch attached to bug 13196. On one occasion for your earlier patch I did try switching to a console (with ctrl-ALT-F1 on KDE) which worked fine, but then when switching back to X, there were some strange X errors (certain KDE applications/windows froze) so I had to shutdown X (KDE logout) and start over with startx. I have been unable to reproduce the problem just now with your latest patch, but even if the problem still existed I would settle for the result since it is such an improvement over 2.2.0 where X was completely inaccessible to me. My own feeling is you should go ahead an release 2.2.1 so long as the vast majority of your testers find it is an improvement over 2.2.0 (as in my particular case) and it works on all the Intel chipsets personally available to you. Of course, you wont get widespread testing until you make the release so I realize you are in something of a catch 22, but if there is some screwup with certain chipsets for 2.2.1 there is always 2.2.2 to fix it. :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Wed Dec 26 13:54:39 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 26 Dec 2007 13:54:39 -0800 (PST) Subject: [xorg] Re: [xorg] Intel 2.2.1 release planning In-Reply-To: References: <200712131127.40293.jbarnes@virtuousgeek.org> Message-ID: On 2007-12-26 12:10-0800 Alan W. Irwin wrote: > Is there any additional news to report about this planned release, Jesse? > > I was very happy that the previous X lockup I got for 2.2.0 (for my ASUS > P5K-V g33 chipset without ADD2 card) was solved by an earlier and also your > latest patch attached to bug 13196. On one occasion for your earlier patch I > did try switching to a console (with ctrl-ALT-F1 on KDE) which worked fine, > but then when switching back to X, there were some strange X errors (certain > KDE applications/windows froze) so I had to shutdown X (KDE logout) and > start over with startx. I have been unable to reproduce the problem just > now with your latest patch, but even if the problem still existed I would > settle for the result since it is such an improvement over 2.2.0 where X was > completely inaccessible to me. Hmm. Just discovered that there still is a problem with switching to console and back. It was fine for a while (long enough to write the above), but then KDE became unreliable. In particular, kicker froze so the logout icon I have there quit working, I could not switch between desktops, etc. Eventually, I logged out of KDE another way (using the logout icon accessible from the right-click menu), but that didn't work cleanly so I had to do a lot of kills of KDE commands and also the startx command by hand afterwards. Note, KDE is normally completely reliable for me. For example, normally when I logout that cleanly kills all KDE and X tasks. I only run into the above kind of trouble if I switch to console and back to X (just once is required to show the problem, but it seems to take a few minutes after the switch back to X for the trouble to develop). Note, this is a production box so I don't want to be restarting X a lot since it interrupts my own work, but if you have one or two important tests you would like me to run to help get to the bottom of the console/X switching trouble on my Intel hardware, let me know. > My own feeling is you should go ahead an release 2.2.1 so long as the vast > majority of your testers find it is an improvement over 2.2.0 (as in my > particular case) and it works on all the Intel chipsets personally available > to you. Of course, you wont get widespread testing until you make the > release so I realize you are in something of a catch 22, but if there is > some screwup with certain chipsets for 2.2.1 there is always 2.2.2 to fix > it. :-) I will stick by this. Obviously your fixes are less than perfect for my particular hardware, but they are still much better than 2.2.0, and I can avoid switching to the console and back to X (which I do rarely in any case) until you get the fundamental switch problem sorted out. Normally, I can stay in X/KDE for a week without any signs of trouble except for the well-known memory leak in the latest (Debian unstable) X which consumes memory at the rate of roughly 2MB/hour or ~350MB/week. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From zhenyu.z.wang at intel.com Wed Dec 26 18:11:58 2007 From: zhenyu.z.wang at intel.com (Zhenyu Wang) Date: Thu, 27 Dec 2007 10:11:58 +0800 Subject: [PATCH] LVDS quirk for AOPEN MINIPC with 965GM In-Reply-To: <1oni3jx1fwakg$.febr4ixnbohl$.dlg@40tude.net> References: <1oni3jx1fwakg$.febr4ixnbohl$.dlg@40tude.net> Message-ID: <20071227021158.GA5272@zhen-devel.sh.intel.com> On 2007.12.26 19:40:59 +0000, elupus wrote: > > Not that this fixes anything at all for my non working tv out, but hey :). > > Maybe i could dump the tv output registers somehow since everything works > > while bios boots. You patch completely disabled TV out for Aopen 965 series, which seems not right, as it does have TV outputs. You may try to fire a bug and describe what's your TV problem anyway. From zhenyu.z.wang at intel.com Wed Dec 26 18:14:27 2007 From: zhenyu.z.wang at intel.com (Zhenyu Wang) Date: Thu, 27 Dec 2007 10:14:27 +0800 Subject: [PATCH] LVDS quirk for AOPEN MINIPC with 965GM In-Reply-To: <20071227021158.GA5272@zhen-devel.sh.intel.com> References: <1oni3jx1fwakg$.febr4ixnbohl$.dlg@40tude.net> <20071227021158.GA5272@zhen-devel.sh.intel.com> Message-ID: <20071227021427.GB5272@zhen-devel.sh.intel.com> On 2007.12.27 10:11:58 +0000, Zhenyu Wang wrote: > On 2007.12.26 19:40:59 +0000, elupus wrote: > > > Not that this fixes anything at all for my non working tv out, but hey :). > > > Maybe i could dump the tv output registers somehow since everything works > > > while bios boots. > > You patch completely disabled TV out for Aopen 965 series, which seems not > right, as it does have TV outputs. You may try to fire a bug and describe > what's your TV problem anyway. oops, your last work made me think it's a tv quirk... ok it's for lvds, so I think it's ok, will push it. Thanks. From davem at davemloft.net Wed Dec 26 22:19:00 2007 From: davem at davemloft.net (David Miller) Date: Wed, 26 Dec 2007 22:19:00 -0800 (PST) Subject: [PATCH]: Fix xserver SBUS build Message-ID: <20071226.221900.127204962.davem@davemloft.net> Please apply this patch to the xserver GIT tree. Actually this build bug is amusing because GIT changeset fe25f897c62bb324660217e15dbd3091c808dbba converted the first xf86getpagesize instance in this file but didn't get this second one. Thank you! >From 9d9f5693475dba0eea4caf7403030d21a8342229 Mon Sep 17 00:00:00 2001 From: David S. Miller Date: Tue, 25 Dec 2007 22:42:50 -0800 Subject: [PATCH] [SBUS]: Fix build, use getpagesize() instead of xf86getpagesize(). xf86getpagesize() was removed, but this one call site was not fixed up. Signed-off-by: David S. Miller --- hw/xfree86/os-support/bus/Sbus.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/os-support/bus/Sbus.c b/hw/xfree86/os-support/bus/Sbus.c index 2f0043f..ff257a8 100644 --- a/hw/xfree86/os-support/bus/Sbus.c +++ b/hw/xfree86/os-support/bus/Sbus.c @@ -585,7 +585,7 @@ xf86MapSbusMem(sbusDevicePtr psdp, unsigned long offset, unsigned long size) _X_EXPORT void xf86UnmapSbusMem(sbusDevicePtr psdp, pointer addr, unsigned long size) { - unsigned long mask = xf86getpagesize() - 1; + unsigned long mask = getpagesize() - 1; unsigned long base = (unsigned long)addr & ~mask; unsigned long len = (((unsigned long)addr + size + mask) & ~mask) - base; -- 1.5.4.rc1.23.g3a969 From jcristau at debian.org Wed Dec 26 22:38:00 2007 From: jcristau at debian.org (Julien Cristau) Date: Thu, 27 Dec 2007 07:38:00 +0100 Subject: [PATCH]: Fix xserver SBUS build In-Reply-To: <20071226.221900.127204962.davem@davemloft.net> References: <20071226.221900.127204962.davem@davemloft.net> Message-ID: <20071227063759.GB8081@patate.is-a-geek.org> On Wed, Dec 26, 2007 at 22:19:00 -0800, David Miller wrote: > > Please apply this patch to the xserver GIT tree. > Applied, thanks! Cheers, Julien From davem at davemloft.net Wed Dec 26 22:44:21 2007 From: davem at davemloft.net (David Miller) Date: Wed, 26 Dec 2007 22:44:21 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. Message-ID: <20071226.224421.194300876.davem@davemloft.net> This is a refresh of a bug fix patch that has been rotting in freedesktop bugzilla for more than a year. The short story is that during the conversion over to modular, the __GLX_ALIGN64 CPP define (as well as the necessary -mieee compiler option for Alpha) no longer gets set where it needs to, resulting in SIGBUS exceptions (and math accuracy problems on Alpha) for GL applications. The original patch author is Jurij Smakov Please apply to the xorg GIT tree, thanks! [GL]: Add GLX compile flags lost in modular X server changes. RISC chips that trap on unaligned loads and stores need to define __GLX_ALIGN64. This used to get added to the cflags in the old *.cf files but it no longer does in the modular X server. Also, Alpha needs to pass -mieee to the compiler as well. This is a simple backport of a patch that debian, and probably other distributions, have been applying forever. To the best of my knowledge the patch was written by Jurij Smakov. See debian bug number #388125. I just checked and this has been rotting for more than a year in freedesktop bugzilla as #8392. Signed-off-by: David S. Miller --- GL/glx/Makefile.am | 3 ++- configure.ac | 10 ++++++++++ hw/dmx/glxProxy/Makefile.am | 1 + 3 files changed, 13 insertions(+), 1 deletions(-) diff --git a/GL/glx/Makefile.am b/GL/glx/Makefile.am index 8eda153..4cf56e8 100644 --- a/GL/glx/Makefile.am +++ b/GL/glx/Makefile.am @@ -14,7 +14,8 @@ AM_CFLAGS = \ -I at MESA_SOURCE@/src/mesa/glapi \ -I at MESA_SOURCE@/src/mesa/main \ -DXFree86Server \ - @GLX_DEFINES@ + @GLX_DEFINES@ \ + @GLX_ARCH_DEFINES@ # none yet #sdk_HEADERS = diff --git a/configure.ac b/configure.ac index 0b718c9..0742040 100644 --- a/configure.ac +++ b/configure.ac @@ -304,6 +304,7 @@ case $host_cpu in *freebsd*) SYS_LIBS=-lio ;; *netbsd*) AC_DEFINE(USE_ALPHA_PIO, 1, [NetBSD PIO alpha IO]) ;; esac + GLX_ARCH_DEFINES="-D__GLX_ALIGN64 -mieee" ;; arm*) ARM_VIDEO=yes @@ -333,6 +334,7 @@ case $host_cpu in xorg_loader_sparcmuldiv="yes" SPARC64_VIDEO=yes BSD_ARCH_SOURCES="sparc64_video.c ioperm_noop.c" + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" ;; x86_64*|amd64*) use_x86_asm="yes" @@ -347,8 +349,16 @@ case $host_cpu in SYS_LIBS=-lamd64 ;; esac + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" + ;; + ia64*) + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" + ;; + s390*) + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" ;; esac +AC_SUBST(GLX_ARCH_DEFINES) dnl BSD *_video.c selection AM_CONDITIONAL(ALPHA_VIDEO, [test "x$ALPHA_VIDEO" = xyes]) diff --git a/hw/dmx/glxProxy/Makefile.am b/hw/dmx/glxProxy/Makefile.am index 1fbc8d7..f995498 100644 --- a/hw/dmx/glxProxy/Makefile.am +++ b/hw/dmx/glxProxy/Makefile.am @@ -32,6 +32,7 @@ libglxproxy_a_SOURCES = compsize.c \ unpack.h AM_CFLAGS = \ + @GLX_ARCH_DEFINES@ \ $(DIX_CFLAGS) \ -I$(top_srcdir)/hw/dmx \ -I$(top_srcdir)/include \ -- 1.5.4.rc1.23.g3a969 From daniel at fooishbar.org Wed Dec 26 23:43:52 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 27 Dec 2007 07:43:52 +0000 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071226.224421.194300876.davem@davemloft.net> References: <20071226.224421.194300876.davem@davemloft.net> Message-ID: <20071227074352.GB21019@fooishbar.org> On Wed, Dec 26, 2007 at 10:44:21PM -0800, David Miller wrote: > RISC chips that trap on unaligned loads and stores need to > define __GLX_ALIGN64. This used to get added to the cflags > in the old *.cf files but it no longer does in the modular > X server. This is the wrong approach for modular; instead of hardcoding a list of CPUs that throw errors on unaligned accesses, you could just check whether or not unaligned accesses work. > Also, Alpha needs to pass -mieee to the compiler as well. How portable is this? Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From davem at davemloft.net Wed Dec 26 23:56:44 2007 From: davem at davemloft.net (David Miller) Date: Wed, 26 Dec 2007 23:56:44 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227074352.GB21019@fooishbar.org> References: <20071226.224421.194300876.davem@davemloft.net> <20071227074352.GB21019@fooishbar.org> Message-ID: <20071226.235644.47002753.davem@davemloft.net> From: Daniel Stone Date: Thu, 27 Dec 2007 07:43:52 +0000 > On Wed, Dec 26, 2007 at 10:44:21PM -0800, David Miller wrote: > > RISC chips that trap on unaligned loads and stores need to > > define __GLX_ALIGN64. This used to get added to the cflags > > in the old *.cf files but it no longer does in the modular > > X server. > > This is the wrong approach for modular; instead of hardcoding a list of > CPUs that throw errors on unaligned accesses, you could just check > whether or not unaligned accesses work. I wish someone had said this over a year ago to Jurij instead of letting the patch and the issue rot all this time. > > Also, Alpha needs to pass -mieee to the compiler as well. > > How portable is this? I think it's widely usable on Alpha compilers. But that's not important because I think the way to fix this is to not continue deferring the bug fix until it's perfect, but rather to put something that fixes the crashes and misbehaviors into the tree now and refine it over time as needed. From daniel at fooishbar.org Thu Dec 27 00:22:18 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 27 Dec 2007 08:22:18 +0000 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071226.235644.47002753.davem@davemloft.net> References: <20071226.224421.194300876.davem@davemloft.net> <20071227074352.GB21019@fooishbar.org> <20071226.235644.47002753.davem@davemloft.net> Message-ID: <20071227082218.GC21019@fooishbar.org> On Wed, Dec 26, 2007 at 11:56:44PM -0800, David Miller wrote: > From: Daniel Stone > Date: Thu, 27 Dec 2007 07:43:52 +0000 > > > On Wed, Dec 26, 2007 at 10:44:21PM -0800, David Miller wrote: > > > RISC chips that trap on unaligned loads and stores need to > > > define __GLX_ALIGN64. This used to get added to the cflags > > > in the old *.cf files but it no longer does in the modular > > > X server. > > > > This is the wrong approach for modular; instead of hardcoding a list of > > CPUs that throw errors on unaligned accesses, you could just check > > whether or not unaligned accesses work. > > I wish someone had said this over a year ago to Jurij instead of > letting the patch and the issue rot all this time. Oddly enough, I don't read every single bug report that comes through, so attributing this one to ignorance rather than deliberate malice might be acceptably charitable here. > > > Also, Alpha needs to pass -mieee to the compiler as well. > > > > How portable is this? > > I think it's widely usable on Alpha compilers. > > But that's not important because I think the way to fix this is to not > continue deferring the bug fix until it's perfect, but rather to put > something that fixes the crashes and misbehaviors into the tree now > and refine it over time as needed. I don't disagree with you, but surely there's nothing wrong with trying to find things out in advance either. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From davem at davemloft.net Thu Dec 27 00:34:16 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 00:34:16 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227082218.GC21019@fooishbar.org> References: <20071227074352.GB21019@fooishbar.org> <20071226.235644.47002753.davem@davemloft.net> <20071227082218.GC21019@fooishbar.org> Message-ID: <20071227.003416.249664616.davem@davemloft.net> From: Daniel Stone Date: Thu, 27 Dec 2007 08:22:18 +0000 > Oddly enough, I don't read every single bug report that comes through, > so attributing this one to ignorance rather than deliberate malice might > be acceptably charitable here. It's a general sentiment and not directed at you specifically, sorry. I've had to really make a big fuss in the past to get a patch installed that kept the X server from eating people's IDE disks, and based upon some other experiences that seems to be par for the course. As another example, half the input drivers in the tree don't even build, and it's been like this for over two years. There has been some level of forward progress, but the regression is still mostly there. The person who checked in the input driver API changes that broke the driver builds gave a response something like "I implemented a real important feature, I don't have the time to fix up all of these kooky input drivers that no longer build." This kind of stuff, to me, is miles away from acceptable and I hope that this bug fix won't be handled like those cases. These bugs being fixed here are regressions of the modular tree conversion. I'm happy to reimplement this specific fix to be cleaner, but let's get the multi-year regression fixed to start off. Thanks. From xavier.bestel at free.fr Thu Dec 27 00:35:45 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Thu, 27 Dec 2007 09:35:45 +0100 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227074352.GB21019@fooishbar.org> References: <20071226.224421.194300876.davem@davemloft.net> <20071227074352.GB21019@fooishbar.org> Message-ID: <1198744545.4976.4.camel@skapc.parateam.prv> Le jeudi 27 d?cembre 2007 ? 07:43 +0000, Daniel Stone a ?crit : > On Wed, Dec 26, 2007 at 10:44:21PM -0800, David Miller wrote: > > RISC chips that trap on unaligned loads and stores need to > > define __GLX_ALIGN64. This used to get added to the cflags > > in the old *.cf files but it no longer does in the modular > > X server. > > This is the wrong approach for modular; instead of hardcoding a list of > CPUs that throw errors on unaligned accesses, you could just check > whether or not unaligned accesses work. Beware, not all archs generate a trap on unaligned access. Some have weird (uncorrectable) failure modes. Xav From mailinglists at who-t.net Thu Dec 27 00:37:07 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Thu, 27 Dec 2007 19:07:07 +1030 Subject: Multi Pointer X MPX Build problem In-Reply-To: <6e4dc1c0712252218i2969ce10t696e41cc443188e3@mail.gmail.com> References: <001301c83cef$b4007bc0$15b2a8c0@fuckup> <4760DDE7.60006@who-t.net> <47612FF9.6030400@tungstengraphics.com> <6e4dc1c0712252218i2969ce10t696e41cc443188e3@mail.gmail.com> Message-ID: <47736433.3080705@who-t.net> Joel Bosveld wrote: > I was wondering if the master branch of xserver was going to be merged into > mpx again any time soon (as, if I understand correctly, this will fix the > problem, and I tried merging it myself, but ended up with a fair number of > conflicts, which I have (almost) no idea how to resolve (and if master is > going to be merged into mpx again soon, I won't bother trying to resolve > them, I will just wait)) I have started, but it'll take me a while to fix everything up. The XACE rework was merged into master since, and causes a lot of conflicts where I have to make myself familiar with the code first. Cheers, Peter From davem at davemloft.net Thu Dec 27 00:43:00 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 00:43:00 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <1198744545.4976.4.camel@skapc.parateam.prv> References: <20071226.224421.194300876.davem@davemloft.net> <20071227074352.GB21019@fooishbar.org> <1198744545.4976.4.camel@skapc.parateam.prv> Message-ID: <20071227.004300.218132079.davem@davemloft.net> From: Xavier Bestel Date: Thu, 27 Dec 2007 09:35:45 +0100 > Le jeudi 27 d?cembre 2007 ? 07:43 +0000, Daniel Stone a ?crit : > > This is the wrong approach for modular; instead of hardcoding a list of > > CPUs that throw errors on unaligned accesses, you could just check > > whether or not unaligned accesses work. > > Beware, not all archs generate a trap on unaligned access. Some have > weird (uncorrectable) failure modes. Yes, I believe some ARM variants are like this, they just randomly crap into the memory location or destination register. From daniel at fooishbar.org Thu Dec 27 01:56:43 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Thu, 27 Dec 2007 09:56:43 +0000 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227.003416.249664616.davem@davemloft.net> References: <20071227074352.GB21019@fooishbar.org> <20071226.235644.47002753.davem@davemloft.net> <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> Message-ID: <20071227095643.GD21019@fooishbar.org> On Thu, Dec 27, 2007 at 12:34:16AM -0800, David Miller wrote: > From: Daniel Stone > Date: Thu, 27 Dec 2007 08:22:18 +0000 > > > Oddly enough, I don't read every single bug report that comes through, > > so attributing this one to ignorance rather than deliberate malice might > > be acceptably charitable here. > > It's a general sentiment and not directed at you specifically, sorry. > > I've had to really make a big fuss in the past to get a patch > installed that kept the X server from eating people's IDE disks, and > based upon some other experiences that seems to be par for the course. > > As another example, half the input drivers in the tree don't even > build, and it's been like this for over two years. There has been > some level of forward progress, but the regression is still mostly > there. http://bugs.freedesktop.org/show_bug.cgi?id=10262 which has been RESOLVED/FIXED since August? > I'm happy to reimplement this specific fix to be cleaner, but let's > get the multi-year regression fixed to start off. Well, the 'multi-year regression'[0] has been fixed for the past four months now, so ... Cheers, Daniel [0]: input-hotplug was merged into master (the unstable development branch) in November 2006; the body of drivers were fixed in March 2007, virtually all the drivers were fixed in August 2007, and the very last one was fixed in September 2007. I'm not holding this up as an example of brilliant development, but it's not a two-year regression, however you paint it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jaymz at artificial-stupidity.net Thu Dec 27 03:35:34 2007 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Thu, 27 Dec 2007 22:35:34 +1100 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227.004300.218132079.davem@davemloft.net>; from davem@davemloft.net on Thu, Dec 27, 2007 at 12:43:00AM -0800 References: <20071226.224421.194300876.davem@davemloft.net> <20071227074352.GB21019@fooishbar.org> <1198744545.4976.4.camel@skapc.parateam.prv> <20071227.004300.218132079.davem@davemloft.net> Message-ID: <20071227223534.D20387@artificial-stupidity.net> On Thu, Dec 27, 2007 at 12:43:00AM -0800, David Miller wrote: > From: Xavier Bestel > Date: Thu, 27 Dec 2007 09:35:45 +0100 > > > Le jeudi 27 d?cembre 2007 ? 07:43 +0000, Daniel Stone a ?crit : > > > This is the wrong approach for modular; instead of hardcoding a list of > > > CPUs that throw errors on unaligned accesses, you could just check > > > whether or not unaligned accesses work. > > > > Beware, not all archs generate a trap on unaligned access. Some have > > weird (uncorrectable) failure modes. > > Yes, I believe some ARM variants are like this, they just randomly > crap into the memory location or destination register. It's not random (it rotates the result in a specific way), but that's not the point - you can easily check for this bevaviour by doing something like: (warning: written into email client :-p. Bonus points if you modify it to check endian at the same time) int main() { char foop[5]; int *fleep=(int *)(foop+1) int j; foop[0]=0; fleep=0x12345678; j=*(int *)foop; return (j==0x00123456 || j==0x00785634); } --jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From voznyak at mail.ru Thu Dec 27 03:55:45 2007 From: voznyak at mail.ru (Egor Voznessenski) Date: Thu, 27 Dec 2007 11:55:45 +0000 (UTC) Subject: Tablet to screen coordinate conversion (again) References: Message-ID: Giuseppe Bilotta gmail.com> writes: > > Hello, > > having just fixed a bug that prevented the acecad driver I'm > maintaining from working at all with xorg 1.4, I hit the problem > discussed in this February thread: > http://lists.freedesktop.org/pipermail/xorg/2007-February/022126.html Hello, I wonder if you solved the problem - since I have the same with my FreeBSD wacom driver. Manual conversion seems to work but drawing in Gimp becomes too jerky. Of course the best way is to update the cursor in the way R6.9 did, probably old mipointer.c will work ;-) From giuseppe.bilotta at gmail.com Thu Dec 27 06:03:53 2007 From: giuseppe.bilotta at gmail.com (Giuseppe Bilotta) Date: Thu, 27 Dec 2007 15:03:53 +0100 Subject: Tablet to screen coordinate conversion (again) References: Message-ID: On Thursday 27 December 2007 12:55, Egor Voznessenski wrote: > Giuseppe Bilotta gmail.com> writes: > >> >> Hello, >> >> having just fixed a bug that prevented the acecad driver I'm >> maintaining from working at all with xorg 1.4, I hit the problem >> discussed in this February thread: >> http://lists.freedesktop.org/pipermail/xorg/2007-February/022126.html > > Hello, I wonder if you solved the problem - since I have the same with > my FreeBSD wacom driver. Manual conversion seems to work but drawing > in Gimp becomes too jerky. > Of course the best way is to update the cursor in the way R6.9 did, > probably old mipointer.c will work ;-) I'm doing the manual conversion http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-acecad.git;a=commit;h=0ee57c9d8048c3e80356a3eab18b6871a21a3a96 http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-acecad.git;a=commit;h=bf27c55a83a83fea4afe0499d1b2d592110e945a It sucks, but we can't do better unless X reverts to the old behaviour. -- Giuseppe "Oblomov" Bilotta From bamboo9527 at gmail.com Thu Dec 27 07:38:16 2007 From: bamboo9527 at gmail.com (antilife) Date: Thu, 27 Dec 2007 23:38:16 +0800 Subject: xf86PostMotionEvent caused server aborting References: <003a01c8463c$80db58e0$3201a8c0@lgw3dce7a2070b> <4771D185.6040903@who-t.net> Message-ID: <000e01c8489e$cd31ba40$3601a8c0@lgw3dce7a2070b> ----- Original Message ----- From: "Peter Hutterer" To: "antilife" Cc: Sent: Wednesday, December 26, 2007 11:59 AM Subject: Re: xf86PostMotionEvent caused server aborting > antilife wrote: >> ////////////////////////////////////////// >> but xf86PostButtonEvent can not work, it caused server aborting: >> ///////////////////////////////////////// >> if ( (priv->zzzOldX != x) || (priv->zzzOldY != y)) { >> xf86PostMotionEvent(device, 1, 0, 3, x, y, pressure); >> } >> ///////////////////////////////////////// >> anybody who can help me? many thanks!!!!!!!! > > Please attach or paste your Xorg.0.log file, otherwise it's mostly > guesswork. > What server version do you use? > > Cheers, > Peter Thanks for your reply.Below is my Xorg.0.log: X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.17-1.2174_FC5smp i686 [ELF] Current Operating System: Linux (none) 2.6.16.14 #333 Thu Jun 28 16:36:08 HKT 2l Build Date: 25 September 2006 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 1 00:00:08 2000 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Builtin Default fbdev Screen 0" (0) (**) | |-->Monitor "" (**) | |-->Device "Builtin Default fbdev Device 0" (WW) No monitor specified for screen "Builtin Default fbdev Screen 0". Using a default monitor configuration. (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xorg" (**) XKB: rules: "xorg" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "stylus" (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) using VT number 2 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B] [2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B] [2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) All system resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x00000000 - 0x00000000 (0x1) MX[B] [2] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [3] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) LoadModule: "hanwang" (II) Loading /usr/X11R6/lib/modules/input/hanwang_drv.o (II) Module hanwang: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) LoadModule: "shadowfb" (II) Loading /usr/X11R6/lib/modules/libshadowfb.a (II) Module shadowfb: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (II) LoadModule: "fbdev" (II) Loading /usr/X11R6/lib/modules/drivers/fbdev_drv.o (II) Module fbdev: vendor="X.Org Foundation" compiled for 6.8.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (II) LoadModule: "void" (II) Loading /usr/X11R6/lib/modules/input/void_drv.o (II) Module void: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) LoadModule: "keyboard" (II) Loading /usr/X11R6/lib/modules/input/keyboard_drv.o (II) Module keyboard: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) LoadModule: "hanwang" (II) Reloading /usr/X11R6/lib/modules/input/hanwang_drv.o (II) FBDEV: driver for framebuffer: fbdev (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 6.8.2, module version = 0.0.2 ABI class: X.Org Video Driver, version 0.7 (II) FBDEV(0): using /dev/fbdir/0 (II) Running in FRAMEBUFFER Mode (**) FBDEV(0): Depth 16, (--) framebuffer bpp 16 (==) FBDEV(0): RGB weight 565 (==) FBDEV(0): Default visual is TrueColor (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) (II) FBDEV(0): Hardware: IMX (vidmem: 210k) (**) FBDEV(0): Option "ShadowFB" "true" (**) FBDEV(0): Option "Rotate" "CW" (**) FBDEV(0): Option "fbdev" "/dev/fbdir/0" (**) FBDEV(0): Rotating screen clockwise (II) FBDEV(0): Checking Modes against framebuffer device... (II) FBDEV(0): mode "640x480" ok (II) FBDEV(0): Checking Modes against monitor... (--) FBDEV(0): Virtual size is 640x480 (pitch 640) (**) FBDEV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz (II) FBDEV(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsc (==) FBDEV(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (**) FBDEV(0): Using "Shadow Framebuffer" (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/X11R6/lib/modules/libshadow.a (II) Module shadow: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.2 (EE) FBDEV(0): FBIOPAN_DISPLAY: Invalid argument (II) FBDEV(0): Rotated display, disabling DGA (II) FBDEV(0): Enabling Driver rotation, disabling RandR (==) FBDEV(0): Backing store disabled (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "CoreKeyboard" (**) Keyboard0: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (**) Option "SendCoreEvents" (**) stylus: always reports core events (**) stylus serial device is /dev/ttySMX1 (II) XINPUT: Adding extended input device "stylus" (type: HANWANG) (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse0" (type: Void) (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap (**) Option "Device" "/dev/ttySMX1" (**) Option "BaudRate" "19200" (**) Option "StopBits" "1" (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "10" (**) Option "FlowControl" "Xoff" *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional informat. From Magnus.Vigerlof at home.se Thu Dec 27 08:24:42 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-1?q?Vigerl=F6f?=) Date: Thu, 27 Dec 2007 17:24:42 +0100 Subject: [PATCH] dix: Add scaling of X and Y on the reported pointer-events In-Reply-To: <200712191920.12653.Magnus.Vigerlof@home.se> References: <200712161853.46380.Magnus.Vigerlof@home.se> <476852D6.8030201@who-t.net> <200712191920.12653.Magnus.Vigerlof@home.se> Message-ID: <200712271724.42780.Magnus.Vigerlof@home.se> Add back the support for scaling the reported X and Y axis when reporting Motion- and Button-events. The two axis will only be scaled if there is a max-value that is not -1. Relative motion reports will use the last coordinates from the InputDevice if it translates into the same position as the core pointer to preseve the subpixel motion. --- We're getting more and more people who would like to see this scaling back, so if the following patch (or something like it) could be applied it would be very much appreciated. Comments about the previous patch (which doesn't include min- values in the calculation) can be found here: http://lists.freedesktop.org/archives/xorg/2007-December/031199.html Cheers Magnus dix/getevents.c | 59 ++++++++++++++++++++++++++++++++++++++++++------------ 1 files changed, 46 insertions(+), 13 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index 6e840d4..1cb2595 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -528,6 +528,7 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, DeviceIntPtr cp = inputInfo.pointer; int x = 0, y = 0; Bool coreOnly = (pDev == inputInfo.pointer); + ScreenPtr scr = miPointerGetScreen(pDev); /* Sanity checks. */ if (type != MotionNotify && type != ButtonPress && type != ButtonRelease) @@ -593,15 +594,35 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, valuators); if (pDev->coreEvents) { - if (first_valuator == 0 && num_valuators >= 1) - x = cp->valuator->lastx + valuators[0]; + /* Get and convert the core pointer coordinate space into + * device coordinates. Use the device coords if it translates + * into the same position as the core to preserve relative sub- + * pixel movements from the device. */ + int min = pDev->valuator->axes[0].min_value; + int max = pDev->valuator->axes[0].max_value; + if(max > 0) { + x = pDev->valuator->lastx; + if((int)((float)(x-min)*scr->width/(max-min+1)) != cp->valuator->lastx) + x = (int)((float)(cp->valuator->lastx)*(max-min+1)/scr->width)+min; + } else x = cp->valuator->lastx; - if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) - y = cp->valuator->lasty + valuators[1 - first_valuator]; + min = pDev->valuator->axes[1].min_value; + max = pDev->valuator->axes[1].max_value; + if(max > 0) { + y = pDev->valuator->lasty; + if((int)((float)(y-min)*scr->height/(max-min+1)) != cp->valuator->lasty) + y = (int)((float)(cp->valuator->lasty)*(max-min+1)/scr->height)+min; + } else y = cp->valuator->lasty; + + /* Add relative movement */ + if (first_valuator == 0 && num_valuators >= 1) + x += valuators[0]; + if (first_valuator <= 1 && num_valuators >= (2 - first_valuator)) + y += valuators[1 - first_valuator]; } else { if (first_valuator == 0 && num_valuators >= 1) @@ -620,11 +641,6 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, clipAxis(pDev, 0, &x); clipAxis(pDev, 1, &y); - /* This takes care of crossing screens for us, as well as clipping - * to the current screen. Right now, we only have one history buffer, - * so we don't set this for both the device and core.*/ - miPointerSetPosition(pDev, &x, &y, ms); - /* Drop x and y back into the valuators list, if they were originally * present. */ if (first_valuator == 0 && num_valuators >= 1) @@ -634,12 +650,29 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, updateMotionHistory(pDev, ms, first_valuator, num_valuators, valuators); + pDev->valuator->lastx = x; + pDev->valuator->lasty = y; + /* Convert the dev coord back to screen coord if we're + * sending core events */ + if (pDev->coreEvents) { + AxisInfoPtr ax = pDev->valuator->axes; + if(ax[0].max_value > 0) + x = (int)((float)(x-ax[0].min_value)*scr->width/ + (ax[0].max_value-ax[0].min_value+1)); + if(ax[1].max_value > 0) + y = (int)((float)(y-ax[1].min_value)*scr->height/ + (ax[1].max_value-ax[1].min_value+1)); + } + + /* This takes care of crossing screens for us, as well as clipping + * to the current screen. Right now, we only have one history buffer, + * so we don't set this for both the device and core.*/ + miPointerSetPosition(pDev, &x, &y, ms); + if (pDev->coreEvents) { cp->valuator->lastx = x; cp->valuator->lasty = y; } - pDev->valuator->lastx = x; - pDev->valuator->lasty = y; /* for some reason inputInfo.pointer does not have coreEvents set */ if (coreOnly || pDev->coreEvents) { @@ -677,8 +710,8 @@ GetPointerEvents(xEvent *events, DeviceIntPtr pDev, int type, int buttons, kbp->detail = pDev->button->map[buttons]; } - kbp->root_x = x; - kbp->root_y = y; + kbp->root_x = pDev->valuator->lastx; + kbp->root_y = pDev->valuator->lasty; events++; if (num_valuators) { -- 1.5.2.5 From Magnus.Vigerlof at home.se Thu Dec 27 08:29:59 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-1?q?Vigerl=F6f?=) Date: Thu, 27 Dec 2007 17:29:59 +0100 Subject: Tablet to screen coordinate conversion (again) In-Reply-To: References: Message-ID: <200712271729.59984.Magnus.Vigerlof@home.se> On torsdag 27 december 2007, Giuseppe Bilotta wrote: [...] > On Thursday 27 December 2007 12:55, Egor Voznessenski wrote: > > Giuseppe Bilotta gmail.com> writes: > >> Hello, > >> > >> having just fixed a bug that prevented the acecad driver I'm > >> maintaining from working at all with xorg 1.4, I hit the problem > >> discussed in this February thread: > >> http://lists.freedesktop.org/pipermail/xorg/2007-February/022126.html > > > > Hello, I wonder if you solved the problem - since I have the same with > > my FreeBSD wacom driver. Manual conversion seems to work but drawing > > in Gimp becomes too jerky. > > Of course the best way is to update the cursor in the way R6.9 did, > > probably old mipointer.c will work ;-) > > I'm doing the manual conversion > > http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-acecad.git;a=commit >;h=0ee57c9d8048c3e80356a3eab18b6871a21a3a96 > http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-acecad.git;a=commit >;h=bf27c55a83a83fea4afe0499d1b2d592110e945a > > It sucks, but we can't do better unless X reverts to the old behaviour. I've been working on something that will add the scaling again. We're getting people over at the linuxwacom list who want 'proper' reporting back too. Check my posts in December for more info: http://lists.freedesktop.org/archives/xorg/2007-December/ Cheers Magnus From giuseppe.bilotta at gmail.com Thu Dec 27 10:07:43 2007 From: giuseppe.bilotta at gmail.com (Giuseppe Bilotta) Date: Thu, 27 Dec 2007 19:07:43 +0100 Subject: [PATCH] dix: Add scaling of X and Y on the reported pointer-events References: <200712161853.46380.Magnus.Vigerlof@home.se> <476852D6.8030201@who-t.net> <200712191920.12653.Magnus.Vigerlof@home.se> <200712271724.42780.Magnus.Vigerlof@home.se> Message-ID: On Thursday 27 December 2007 17:24, Magnus Vigerl?f wrote: > (which doesn't include min- > values in the calculation) Why not? -- Giuseppe "Oblomov" Bilotta From knowtree at aloha.com Thu Dec 27 08:23:09 2007 From: knowtree at aloha.com (knowtree at aloha.com) Date: Thu, 27 Dec 2007 08:23:09 HST Subject: Tablet to screen coordinate conversion (again) Message-ID: <200712271823.lBRIN9bN028237@yoda.pixi.com> > [...] > > I've been working on something that will add the scaling again. We're getting > people over at the linuxwacom list who want 'proper' reporting back too. > Check my posts in December for more info: > http://lists.freedesktop.org/archives/xorg/2007-December/ > > Cheers > Magnus Where can I find the linuxwacom list? I'd appreciate any other such resources related to tablet input for X. Gary Dunn Open Slate Project http://openslate.net/ From jbarnes at virtuousgeek.org Thu Dec 27 11:01:44 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 27 Dec 2007 11:01:44 -0800 Subject: [xorg] Re: [xorg] Intel 2.2.1 release planning In-Reply-To: References: <200712131127.40293.jbarnes@virtuousgeek.org> Message-ID: <200712271101.44426.jbarnes@virtuousgeek.org> On Wednesday, December 26, 2007 1:54 pm Alan W. Irwin wrote: > Hmm. Just discovered that there still is a problem with switching to > console and back. It was fine for a while (long enough to write the > above), but then KDE became unreliable. In particular, kicker froze > so the logout icon I have there quit working, I could not switch > between desktops, etc. Eventually, I logged out of KDE another way > (using the logout icon accessible from the right-click menu), but > that didn't work cleanly so I had to do a lot of kills of KDE > commands and also the startx command by hand afterwards. This is with the git driver? > Note, KDE is normally completely reliable for me. For example, > normally when I logout that cleanly kills all KDE and X tasks. I > only run into the above kind of trouble if I switch to console and > back to X (just once is required to show the problem, but it seems to > take a few minutes after the switch back to X for the trouble to > develop). Note, this is a production box so I don't want to be > restarting X a lot since it interrupts my own work, but if you have > one or two important tests you would like me to run to help get to > the bottom of the console/X switching trouble on my Intel hardware, > let me know. Ok, thanks. > > My own feeling is you should go ahead an release 2.2.1 so long as > > the vast majority of your testers find it is an improvement over > > 2.2.0 (as in my particular case) and it works on all the Intel > > chipsets personally available to you. Of course, you wont get > > widespread testing until you make the release so I realize you are > > in something of a catch 22, but if there is some screwup with > > certain chipsets for 2.2.1 there is always 2.2.2 to fix it. :-) > > I will stick by this. Obviously your fixes are less than perfect for > my particular hardware, but they are still much better than 2.2.0, > and I can avoid switching to the console and back to X (which I do > rarely in any case) until you get the fundamental switch problem > sorted out. Normally, I can stay in X/KDE for a week without any > signs of trouble except for the well-known memory leak in the latest > (Debian unstable) X which consumes memory at the rate of roughly > 2MB/hour or ~350MB/week. I'm glad it's working better for you. I was hoping to do the release before Christmas, but we haven't yet resolved a few of the bugs I want fixed in this release. That combined with travelling means I haven't had much time to fix said bugs. Anyway, hopefully I'll be able to do the release in the first week or two of 2008. Thanks, Jesse From david.delaharpe.golden at gmail.com Thu Dec 27 11:32:43 2007 From: david.delaharpe.golden at gmail.com (David De La Harpe Golden) Date: Thu, 27 Dec 2007 19:32:43 +0000 Subject: [PATCH] dix: Add scaling of X and Y on the reported pointer-events In-Reply-To: References: <200712161853.46380.Magnus.Vigerlof@home.se> <476852D6.8030201@who-t.net> <200712191920.12653.Magnus.Vigerlof@home.se> <200712271724.42780.Magnus.Vigerlof@home.se> Message-ID: <8e24944a0712271132i62a1cc82xe3c5f04e8a27a142@mail.gmail.com> On 27/12/2007, Giuseppe Bilotta wrote: > On Thursday 27 December 2007 17:24, Magnus Vigerl?f wrote: > > > (which doesn't include min- > > values in the calculation) > > Why not? > [That was just talking about Magnus' *previous* patch. It was a bug in the previous patch] From techservio at gmail.com Thu Dec 27 12:11:27 2007 From: techservio at gmail.com (techservio) Date: Thu, 27 Dec 2007 12:11:27 -0800 (PST) Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today In-Reply-To: <1198228867.3126.48.camel@rousalka.dyndns.org> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> <20071221153644.64091709@KNIGHT> <1198228867.3126.48.camel@rousalka.dyndns.org> Message-ID: <14517916.post@talk.nabble.com> are you aware of any fixes for this bug? -- View this message in context: http://www.nabble.com/Re%3A-distorted-fonts-after-updating-xserver-and-video-drivers-to--the-GIT-HEAD-today-tp14316226p14517916.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. From Magnus.Vigerlof at home.se Thu Dec 27 12:40:13 2007 From: Magnus.Vigerlof at home.se (Magnus =?iso-8859-1?q?Vigerl=F6f?=) Date: Thu, 27 Dec 2007 21:40:13 +0100 Subject: Tablet to screen coordinate conversion (again) In-Reply-To: <200712271823.lBRIN9bN028237@yoda.pixi.com> References: <200712271823.lBRIN9bN028237@yoda.pixi.com> Message-ID: <200712272140.13887.Magnus.Vigerlof@home.se> On torsdag 27 december 2007, knowtree at aloha.com wrote: > > [...] > > > > I've been working on something that will add the scaling again. We're > getting > > people over at the linuxwacom list who want 'proper' reporting back too. > > Check my posts in December for more info: > > http://lists.freedesktop.org/archives/xorg/2007-December/ > > > > Cheers > > Magnus > > Where can I find the linuxwacom list? I'd appreciate any other such > resources related to tablet input for X. All lw-related resources can be found if you start here: http://linuxwacom.sourceforge.net/ Cheers Magnus From davem at davemloft.net Thu Dec 27 14:04:33 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 14:04:33 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227095643.GD21019@fooishbar.org> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> Message-ID: <20071227.140433.198915809.davem@davemloft.net> From: Daniel Stone Date: Thu, 27 Dec 2007 09:56:43 +0000 > On Thu, Dec 27, 2007 at 12:34:16AM -0800, David Miller wrote: > > As another example, half the input drivers in the tree don't even > > build, and it's been like this for over two years. There has been > > some level of forward progress, but the regression is still mostly > > there. > > http://bugs.freedesktop.org/show_bug.cgi?id=10262 which has been > RESOLVED/FIXED since August? Look at how it's like pulling teeth to get someone to fix build regressions they added, even downloading the drivers to do a test build seems to be considered a chore. Also note how many times that bug had to get closed and reopenned before it really was fixed. Finally, some of the input drivers currently don't build: xf86-input-elographics: gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/opt/XORG/include/xorg -I/opt/XORG/include/pixman-1 -I/opt/XORG/include -I../src -MT xf86Elo.lo -MD -MP -MF .deps/xf86Elo.Tpo -c xf86Elo.c -fPIC -DPIC -o .libs/xf86Elo.o xf86Elo.c:68:24: error: xf86_ansic.h: No such file or directory make[2]: *** [xf86Elo.lo] Error 1 xf86-input-magictouch: clude/pixman-1 -I/opt/XORG/include -I../src -MT xf86MagicTouch.lo -MD -MP -MF .deps/xf86MagicTouch.Tpo -c xf86MagicTouch.c -fPIC -DPIC -o .libs/xf86MagicTouch.o xf86MagicTouch.c:25:24: error: xf86_ansic.h: No such file or directory xf86MagicTouch.c: In function 'xf86MagicAllocate': xf86MagicTouch.c:1019: warning: assignment makes pointer from integer without a cast make[2]: *** [xf86MagicTouch.lo] Error 1 > I'm not holding this up as an example of brilliant development, > but it's not a two-year regression, however you paint it. Sure, it was a one-year regression. But a known build regression that lasts for a year, sucks. From mcepl at redhat.com Thu Dec 27 14:31:12 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 27 Dec 2007 23:31:12 +0100 Subject: Full screen only uses part of screen References: <20071226175647.GB7980@hank.org> Message-ID: On 2007-12-26, 17:56 GMT, Bill Moseley wrote: > When I run "full screen" games (e.g. Tux Typing, or Tux Math) > only a small part of the inner screen is used. Does this https://bugzilla.redhat.com/show_bug.cgi?id=389501 look familiar to you? Mat?j From hanasaki at gmail.com Thu Dec 27 15:37:27 2007 From: hanasaki at gmail.com (hanasaki jiji) Date: Thu, 27 Dec 2007 17:37:27 -0600 Subject: G35/33 X3500/3100 HDMI Message-ID: <3cfcba890712271537u56e55ae2tfd4b22b091cf0d11@mail.gmail.com> Which version of xorg is being referenced? I am looking at G35, G33 and G31 boards to run Debian etch and Ubuntu 7.10 gutsy on Are they supported? /// On Sunday, December 02, 2007 3:03 Alan W. Irwin wrote: > On 2007-12-02 22:04+0100 sim0n wrote: > > Thank you very much for your detailed information. > > I guess unless you say that the GMA 3100 basically works now I will > > have to go with a different solution :-(. > > Aside from the one-week outage due to an introduced issue in the > cutting-edge version of the driver, it has been working > well. I run KDE 3.x (i.e., 2D desktop) with no problems, and also > ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here is the > glxgears rating results as given by the offical > http://www.free3d.org/ script Yeah, and that outage was purely my fault. Prior to the 2.2 release, G33 worked fine, but I introduced the regression you found in fixing another bug for 8xx users. So in general, G33 should be in good shape (video, 3D and 2D and mode setting support for SDVO VGA, DVI, and builtin VGA & TV outputs). Jesse From davem at davemloft.net Thu Dec 27 15:42:29 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 15:42:29 -0800 (PST) Subject: [PATCH]: Fix sunffb driver build. Message-ID: <20071227.154229.49825569.davem@davemloft.net> This driver stopped building after all the devprivate work got merged into the xserver recently. The fix is easy because all the code that uses devprivates here could be just completely removed or reworked to get the private via the pScrn instead. Please apply to the xf86-video-sunffb GIT tree, thanks! [SUNFFB]: Fix build after devprivates rework. This driver uses devprivates of all kinds, but this is only done in deprecated and unused code so we can simply remove it all. DRM/DRI support has been commented out for years, and was done during the conversion over to XAA acceleration. This code would need to be essentially rewritten to work again, so we can just remove this stuff for now. The rest were either: 1) DRI/DRM related uses 2) the private allocation code 3) cases that could index to the pScrn to get the FFB private And that's all fixed up here. Signed-off-by: David S. Miller diff --git a/src/ffb.h b/src/ffb.h index cb21251..ea1b7fc 100644 --- a/src/ffb.h +++ b/src/ffb.h @@ -39,10 +39,6 @@ #include "ffb_regs.h" #include "xf86sbusBus.h" #include "ffb_dac.h" -#ifdef XF86DRI -#include "xf86drm.h" -#include "ffb_drishare.h" -#endif #ifndef DPMS_SERVER #define DPMS_SERVER #endif /* DPMS_SERVER */ @@ -97,14 +93,6 @@ typedef struct { unsigned int bits[32]; /* The stipple bits themselves */ } CreatorStippleRec, *CreatorStipplePtr; -typedef struct { - int type; - unsigned int linepat; - CreatorStipplePtr stipple; - void (*PolySegment)(DrawablePtr, GCPtr, int, xSegment *); - void (*Polylines)(DrawablePtr, GCPtr, int, int, DDXPointPtr); -} CreatorPrivGCRec, *CreatorPrivGCPtr; - /* WID and framebuffer controls are a property of the * window. */ @@ -135,12 +123,6 @@ enum ffb_chip_type { afb_m6 /* FCS Elite3D, 6 float chips */ }; -#ifdef XF86DRI -typedef struct { - int index; -} FFBConfigPrivRec, *FFBConfigPrivPtr; -#endif - typedef struct { unsigned short fifo_cache; unsigned short rp_active; @@ -221,16 +203,6 @@ typedef struct { void *I2C; struct ffb_dac_info dac_info; -#ifdef XF86DRI - void *pDRIInfo; - int numVisualConfigs; - void *pVisualConfigs; - FFBConfigPrivPtr pVisualConfigsPriv; - int drmSubFD; - Bool dri_enabled; - ffb_dri_state_t *pFfbSarea; -#endif - OptionInfoPtr Options; } FFBRec, *FFBPtr; @@ -261,18 +233,10 @@ extern void FFBWidFree(FFBPtr, unsigned int); extern unsigned int FFBWidUnshare(FFBPtr, unsigned int); extern unsigned int FFBWidReshare(FFBPtr, unsigned int); extern void FFBWidChangeBuffer(FFBPtr, unsigned int, int); -extern Bool FFBWidIsShared(FFBPtr pFfb, unsigned int wid); /* Accelerated double-buffering. */ extern Bool FFBDbePreInit(ScreenPtr); -#ifdef XF86DRI -/* DRI support */ -extern Bool FFBDRIScreenInit(ScreenPtr); -extern Bool FFBDRIFinishScreenInit(ScreenPtr); -extern void FFBDRICloseScreen(ScreenPtr); -#endif - /* The fastfill and pagefill buffer sizes change based upon * the resolution. */ @@ -290,24 +254,8 @@ extern struct fastfill_parms ffb_fastfill_parms[]; #define FFB_FFPARMS(__fpriv) (ffb_fastfill_parms[(__fpriv)->ffb_res]) -extern int CreatorScreenPrivateIndex; -extern int CreatorGCPrivateIndex; -extern int CreatorWindowPrivateIndex; - #define GET_FFB_FROM_SCRN(p) ((FFBPtr)((p)->driverPrivate)) -#define GET_FFB_FROM_SCREEN(s) \ -((FFBPtr)(s)->devPrivates[CreatorScreenPrivateIndex].ptr) - -#define CreatorGetGCPrivate(g) \ -((CreatorPrivGCPtr) (g)->devPrivates [CreatorGCPrivateIndex].ptr) - -#define CreatorGetWindowPrivate(w) \ -((CreatorPrivWinPtr) (w)->devPrivates[CreatorWindowPrivateIndex].ptr) - -#define CreatorSetWindowPrivate(w,p) \ -((w)->devPrivates[CreatorWindowPrivateIndex].ptr = (pointer) p) - #undef DEBUG_FFB #ifdef DEBUG_FFB diff --git a/src/ffb_accel.c b/src/ffb_accel.c index b9cb053..b8ad1d0 100644 --- a/src/ffb_accel.c +++ b/src/ffb_accel.c @@ -44,11 +44,6 @@ #include "ffb_loops.h" #include "ffb_regs.h" -int CreatorScreenPrivateIndex; -int CreatorGCPrivateIndex; -int CreatorWindowPrivateIndex; -int CreatorGeneration; - /* Indexed by ffb resolution enum. */ struct fastfill_parms ffb_fastfill_parms[] = { /* fsmall, psmall, ffh, ffw, pfh, pfw */ @@ -61,7 +56,8 @@ struct fastfill_parms ffb_fastfill_parms[] = { void CreatorVtChange (ScreenPtr pScreen, int enter) { - FFBPtr pFfb = GET_FFB_FROM_SCREEN (pScreen); + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + FFBPtr pFfb = GET_FFB_FROM_SCRN (pScrn); ffb_fbcPtr ffb = pFfb->regs; pFfb->rp_active = 1; @@ -847,22 +843,6 @@ Bool FFBAccelInit(ScreenPtr pScreen, FFBPtr pFfb) XAAInfoRecPtr infoRec; ffb_fbcPtr ffb = pFfb->regs; - if (serverGeneration != CreatorGeneration) { - CreatorScreenPrivateIndex = AllocateScreenPrivateIndex (); - if (CreatorScreenPrivateIndex == -1) - return FALSE; - CreatorGCPrivateIndex = AllocateGCPrivateIndex (); - CreatorWindowPrivateIndex = AllocateWindowPrivateIndex (); - CreatorGeneration = serverGeneration; - } - - if (!AllocateGCPrivate(pScreen, CreatorGCPrivateIndex, sizeof(CreatorPrivGCRec))) - return FALSE; - if (!AllocateWindowPrivate(pScreen, CreatorWindowPrivateIndex, 0)) - return FALSE; - - pScreen->devPrivates[CreatorScreenPrivateIndex].ptr = pFfb; - pFfb->xaa_fbc = (FFB_FBC_WB_A | FFB_FBC_WM_COMBINED | FFB_FBC_RB_A | FFB_FBC_WE_FORCEON | FFB_FBC_SB_BOTH | diff --git a/src/ffb_attr.c b/src/ffb_attr.c index 7b0d375..e1a3771 100644 --- a/src/ffb_attr.c +++ b/src/ffb_attr.c @@ -81,180 +81,3 @@ void __FFB_Attr_SFB_VAR(FFBPtr pFfb, unsigned int ppc, unsigned int ppc_mask, un ffb->rop = rop; ffb->pmask = pmask; } - -#define NEED_PPC 0x00000001 -#define NEED_PMASK 0x00000002 -#define NEED_ROP 0x00000004 -#define NEED_DRAWOP 0x00000008 -#define NEED_FG 0x00000010 -#define NEED_BG 0x00000020 -#define NEED_FBC 0x00000040 -#define NEED_WID 0x00000080 - -void __FFB_Attr_GC(FFBPtr pFfb, GCPtr pGC, WindowPtr pWin, unsigned int ppc, int drawop) -{ - ffb_fbcPtr ffb = pFfb->regs; - unsigned int rop, need_mask, need_count; - - need_mask = need_count = 0; - if ((pFfb->ppc_cache & FFB_PPC_GCMASK) != ppc) { - unsigned int newppc = pFfb->ppc_cache & ~FFB_PPC_GCMASK; - - newppc |= (ppc & FFB_PPC_GCMASK); - pFfb->ppc_cache = newppc; - need_mask |= NEED_PPC; - need_count++; - } - - if (pFfb->pmask_cache != pGC->planemask) { - pFfb->pmask_cache = pGC->planemask; - need_mask |= NEED_PMASK; - need_count++; - } - - rop = (pGC->alu | FFB_ROP_EDIT_BIT)|(FFB_ROP_NEW<<8); - if (pFfb->rop_cache != rop) { - pFfb->rop_cache = rop; - need_mask |= NEED_ROP; - need_count++; - } - - if (pFfb->drawop_cache != drawop) { - pFfb->drawop_cache = drawop; - need_mask |= NEED_DRAWOP; - need_count++; - } - - if (pFfb->fg_cache != pGC->fgPixel) { - pFfb->fg_cache = pGC->fgPixel; - need_mask |= NEED_FG; - need_count++; - } - - { - CreatorPrivWinPtr WinPriv = CreatorGetWindowPrivate(pWin); - unsigned int fbc = WinPriv->fbc_base; - - fbc &= ~FFB_FBC_XE_MASK; - fbc |= FFB_FBC_XE_OFF; - - if (pFfb->fbc_cache != fbc) { - pFfb->fbc_cache = fbc; - need_mask |= NEED_FBC; - need_count++; - } - - } - pFfb->rp_active = 1; - - FFBLOG(("WRATTRS_GC: PPC[%08x:%08x] PMSK[%08x] ROP[%08x] " - "DOP[%08x] FG[%08x] FBC[%08x]\n", - pFfb->ppc_cache & FFB_PPC_GCMASK, FFB_PPC_GCMASK, - pFfb->pmask_cache, pFfb->rop_cache, - pFfb->drawop_cache, pFfb->fg_cache, pFfb->fbc_cache)); - - FFBFifo(pFfb, need_count); - if (need_mask & NEED_PPC) - ffb->ppc = (pFfb->ppc_cache & FFB_PPC_GCMASK); - if (need_mask & NEED_PMASK) - ffb->pmask = pFfb->pmask_cache; - if (need_mask & NEED_ROP) - ffb->rop = pFfb->rop_cache; - if (need_mask & NEED_DRAWOP) - ffb->drawop = pFfb->drawop_cache; - if (need_mask & NEED_FG) - ffb->fg = pFfb->fg_cache; - if (need_mask & NEED_FBC) - ffb->fbc = pFfb->fbc_cache; -} - -void __FFB_Attr_FastfillWin(FFBPtr pFfb, WindowPtr pWin, - unsigned int ppc, unsigned int pixel) -{ - ffb_fbcPtr ffb = pFfb->regs; - unsigned int rop, need_mask, need_count; - - need_mask = need_count = 0; - if ((pFfb->ppc_cache & FFB_PPC_WINMASK) != ppc) { - unsigned int newppc = pFfb->ppc_cache & ~FFB_PPC_WINMASK; - - newppc |= (ppc & FFB_PPC_WINMASK); - pFfb->ppc_cache = newppc; - need_mask |= NEED_PPC; - need_count++; - } - - if (pFfb->pmask_cache != 0x00ffffff) { - pFfb->pmask_cache = 0x00ffffff; - need_mask |= NEED_PMASK; - need_count++; - } - - rop = FFB_ROP_NEW | (FFB_ROP_NEW<<8); - if (pFfb->rop_cache != rop) { - pFfb->rop_cache = rop; - need_mask |= NEED_ROP; - need_count++; - } - - if (pFfb->drawop_cache != FFB_DRAWOP_FASTFILL) { - pFfb->drawop_cache = FFB_DRAWOP_FASTFILL; - need_mask |= NEED_DRAWOP; - need_count++; - } - - if (pFfb->fg_cache != pixel) { - pFfb->fg_cache = pixel; - need_mask |= NEED_FG; - need_count++; - } - - { - CreatorPrivWinPtr pWinPriv = CreatorGetWindowPrivate(pWin); - unsigned int fbc = pWinPriv->fbc_base; - - if (pFfb->has_double_buffer) { - fbc &= ~FFB_FBC_WB_MASK; - fbc |= FFB_FBC_WB_AB; - } - fbc &= ~(FFB_FBC_XE_MASK | FFB_FBC_RGBE_MASK); - fbc |= FFB_FBC_XE_ON | FFB_FBC_RGBE_ON; - if (pFfb->ffb_res == ffb_res_high) - fbc |= FFB_FBC_WB_B; - - if (pFfb->fbc_cache != fbc) { - pFfb->fbc_cache = fbc; - need_mask |= NEED_FBC; - need_count++; - } - - if (pFfb->wid_cache != pWinPriv->wid) { - pFfb->wid_cache = pWinPriv->wid; - need_mask |= NEED_WID; - need_count++; - } - } - - pFfb->rp_active = 1; - - FFBLOG(("WRATTRS_GC: PPC[%08x:%08x] PMSK[%08x] ROP[%08x] DOP[%08x] FG[%08x] FBC[%08x] WID[%02x]\n", - pFfb->ppc_cache & FFB_PPC_WINMASK, FFB_PPC_WINMASK, - pFfb->pmask_cache, pFfb->rop_cache, - pFfb->drawop_cache, pFfb->fg_cache, pFfb->fbc_cache, pFfb->wid_cache)); - - FFBFifo(pFfb, need_count); - if (need_mask & NEED_PPC) - ffb->ppc = (pFfb->ppc_cache & FFB_PPC_WINMASK); - if (need_mask & NEED_PMASK) - ffb->pmask = pFfb->pmask_cache; - if (need_mask & NEED_ROP) - ffb->rop = pFfb->rop_cache; - if (need_mask & NEED_DRAWOP) - ffb->drawop = pFfb->drawop_cache; - if (need_mask & NEED_FG) - ffb->fg = pFfb->fg_cache; - if (need_mask & NEED_FBC) - ffb->fbc = pFfb->fbc_cache; - if (need_mask & NEED_WID) - ffb->wid = pFfb->wid_cache; -} diff --git a/src/ffb_dri.c b/src/ffb_dri.c deleted file mode 100644 index dd471d4..0000000 --- a/src/ffb_dri.c +++ /dev/null @@ -1,521 +0,0 @@ -/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/sunffb/ffb_dri.c,v 1.8 2001/04/18 14:52:42 dawes Exp $ - * Acceleration for the Creator and Creator3D framebuffer - DRI/DRM support. - * - * Copyright (C) 2000 David S. Miller (davem at redhat.com) - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to deal - * in the Software without restriction, including without limitation the rights - * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell - * copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * DAVID MILLER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN - * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION - * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - * - */ - -#ifdef HAVE_CONFIG_H -#include "config.h" -#endif - -#include - -#include "xf86.h" -#include "xf86_OSproc.h" -#include "xf86Priv.h" - -#include "xf86PciInfo.h" -#include "xf86Pci.h" - -#include "miline.h" - -#include "GL/glxtokens.h" - -#include "xf86drm.h" -#include "sarea.h" -#define _XF86DRI_SERVER_ -#include "dri.h" - -#include "GL/glxint.h" - -#include "ffb.h" -#include "ffb_regs.h" -#include "ffb_fifo.h" -#include "ffb_rcache.h" - -static char FFBKernelDriverName[] = "ffb"; -static char FFBClientDriverName[] = "ffb"; - -/* Forward declarations. */ -static Bool FFBDRICreateContext(ScreenPtr, VisualPtr, drm_context_t, - void *, DRIContextType); -static void FFBDRIDestroyContext(ScreenPtr, drm_context_t, DRIContextType); - -static void FFBDRIInitBuffers(WindowPtr, RegionPtr, CARD32); -static void FFBDRIMoveBuffers(WindowPtr, DDXPointRec, RegionPtr, CARD32); - -static void FFBDRISetDrawableIndex(WindowPtr, CARD32); - -/* XXX Why isn't this in a header somewhere? XXX */ -extern void GlxSetVisualConfigs(int nconfigs, __GLXvisualConfig *configs, - void **configprivs); - -static Bool -FFBDRIInitVisualConfigs(ScreenPtr pScreen) -{ - ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; - FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); - __GLXvisualConfig *pConfigs; - FFBConfigPrivPtr pFfbConfigs; - FFBConfigPrivPtr *pFfbConfigPtrs; - - pConfigs = (__GLXvisualConfig *) - xcalloc(sizeof(__GLXvisualConfig), 1); - if (!pConfigs) - return FALSE; - - pFfbConfigs = (FFBConfigPrivPtr) - xcalloc(sizeof(FFBConfigPrivRec), 1); - if (!pFfbConfigs) { - xfree(pConfigs); - return FALSE; - } - - pFfbConfigPtrs = (FFBConfigPrivPtr *) - xcalloc(sizeof(FFBConfigPrivPtr), 1); - if (!pFfbConfigPtrs) { - xfree(pConfigs); - xfree(pFfbConfigs); - return FALSE; - } - - pFfbConfigPtrs[0] = &pFfbConfigs[0]; - - pConfigs->vid = -1; - pConfigs->class = -1; - pConfigs->rgba = TRUE; - pConfigs->redSize = 8; - pConfigs->greenSize = 8; - pConfigs->blueSize = 8; - pConfigs->alphaSize = 0; - pConfigs->redMask = 0x000000ff; - pConfigs->greenMask = 0x0000ff00; - pConfigs->blueMask = 0x00ff0000; - pConfigs->alphaMask = 0; - pConfigs->accumRedSize = 0; - pConfigs->accumGreenSize = 0; - pConfigs->accumBlueSize = 0; - pConfigs->accumAlphaSize = 0; - pConfigs->doubleBuffer = TRUE; - pConfigs->stereo = FALSE; - pConfigs->bufferSize = 32; - pConfigs->depthSize = 16; - pConfigs->stencilSize = 0; - pConfigs->auxBuffers = 0; - pConfigs->level = 0; - pConfigs->visualRating = GLX_NONE; - pConfigs->transparentPixel = GLX_NONE; - pConfigs->transparentRed = 0; - pConfigs->transparentGreen = 0; - pConfigs->transparentBlue = 0; - pConfigs->transparentAlpha = 0; - pConfigs->transparentIndex = 0; - - pFfb->numVisualConfigs = 1; - pFfb->pVisualConfigs = pConfigs; - pFfb->pVisualConfigsPriv = pFfbConfigs; - - GlxSetVisualConfigs(1, pConfigs, (void **)pFfbConfigPtrs); - - return TRUE; -} - -static void -init_ffb_sarea(FFBPtr pFfb, ffb_dri_state_t *pFfbSarea) -{ - int i; - - pFfbSarea->flags = 0; - - switch (pFfb->ffb_type) { - case ffb2_prototype: - case ffb2_vertical: - case ffb2_vertical_plus: - case ffb2_horizontal: - case ffb2_horizontal_plus: - pFfbSarea->flags |= FFB_DRI_FFB2; - break; - - default: - break; - }; - - if (pFfb->ffb_type == ffb2_vertical_plus || - pFfb->ffb_type == ffb2_horizontal_plus) - pFfbSarea->flags |= FFB_DRI_FFB2PLUS; - - if (pFfb->dac_info.flags & FFB_DAC_PAC1) - pFfbSarea->flags |= FFB_DRI_PAC1; - - if (pFfb->dac_info.flags & FFB_DAC_PAC2) - pFfbSarea->flags |= FFB_DRI_PAC2; - - for (i = 0; i < FFB_DRI_NWIDS; i++) - pFfbSarea->wid_table[i] = 0; -} - -#define FFB_DFB24_POFF 0x02000000UL -#define FFB_DFB24_SIZE 0x01000000UL - -#define FFB_FBC_REGS_POFF 0x00600000UL -#define FFB_FBC_REGS_SIZE 0x00002000UL - -#define FFB_DAC_POFF 0x00400000UL -#define FFB_DAC_SIZE 0x00002000UL - -#define FFB_SFB8R_POFF 0x04000000UL -#define FFB_SFB8R_SIZE 0x00400000UL - -#define FFB_SFB32_POFF 0x05000000UL -#define FFB_SFB32_SIZE 0x01000000UL - -#define FFB_SFB64_POFF 0x06000000UL -#define FFB_SFB64_SIZE 0x02000000UL - -Bool -FFBDRIScreenInit(ScreenPtr pScreen) -{ - ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; - FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); - DRIInfoPtr pDRIInfo; - FFBDRIPtr pFfbDRI; - - /* Check that the GLX, DRI, and DRM modules have been loaded by testing - * for canonical symbols in each module. - */ - if (!xf86LoaderCheckSymbol("GlxSetVisualConfigs")) - return FALSE; - if (!xf86LoaderCheckSymbol("drmAvailable")) - return FALSE; - if (!xf86LoaderCheckSymbol("DRIQueryVersion")) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "FFBDRIScreenInit failed (libdri.a too old)\n"); - return FALSE; - } - - /* Check the DRI version */ - { - int major, minor, patch; - DRIQueryVersion(&major, &minor, &patch); - if (major != DRIINFO_MAJOR_VERSION || minor < DRIINFO_MINOR_VERSION) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] FFBDRIScreenInit failed because of a version mismatch.\n" - "[dri] libdri version is %d.%d.%d but version %d.%d.x is needed.\n" - "[dri] Disabling DRI.\n", - major, minor, patch, - DRIINFO_MAJOR_VERSION, DRIINFO_MINOR_VERSION); - return FALSE; - } - } - - pDRIInfo = DRICreateInfoRec(); - if (pDRIInfo == NULL) - return FALSE; - - pFfb->pDRIInfo = pDRIInfo; - - pDRIInfo->drmDriverName = FFBKernelDriverName; - pDRIInfo->clientDriverName = FFBClientDriverName; - - pDRIInfo->ddxDriverMajorVersion = 0; - pDRIInfo->ddxDriverMinorVersion = 1; - pDRIInfo->ddxDriverPatchVersion = 1; - - pDRIInfo->busIdString = xalloc(64); /* Freed in DRIDestroyInfoRec */ - sprintf(pDRIInfo->busIdString, "SBUS:%s", pFfb->psdp->device); - - /* Dumb rendering port for now... */ - pDRIInfo->frameBufferPhysicalAddress = FFB_DFB24_POFF; - pDRIInfo->frameBufferSize = FFB_DFB24_SIZE; - pDRIInfo->frameBufferStride = (2048 * 4); - - /* XXX */ - pDRIInfo->ddxDrawableTableEntry = 15; - pDRIInfo->maxDrawableTableEntry = 15; - pDRIInfo->SAREASize = (SAREA_MAX + (0x2000 - 1)) & ~(0x2000 - 1); - - pFfbDRI = (FFBDRIPtr) xcalloc(sizeof(FFBDRIRec), 1); - if (pFfbDRI == NULL) { - DRIDestroyInfoRec(pFfb->pDRIInfo); - return FALSE; - } - - pDRIInfo->devPrivate = pFfbDRI; - pDRIInfo->devPrivateSize = sizeof(*pFfbDRI); - pDRIInfo->contextSize = 0; /* kernel does ctx swaps */ - - pDRIInfo->CreateContext = FFBDRICreateContext; - pDRIInfo->DestroyContext = FFBDRIDestroyContext; - pDRIInfo->InitBuffers = FFBDRIInitBuffers; - pDRIInfo->MoveBuffers = FFBDRIMoveBuffers; - pDRIInfo->SetDrawableIndex = FFBDRISetDrawableIndex; - - /* Our InitBuffers depends heavily on this setting. */ - pDRIInfo->bufferRequests = DRI_3D_WINDOWS_ONLY; - - pDRIInfo->createDummyCtx = TRUE; - pDRIInfo->createDummyCtxPriv = FALSE; - - if (!DRIScreenInit(pScreen, pDRIInfo, &(pFfb->drmSubFD))) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] DRIScreenInit failed. Disabling DRI.\n"); - DRIDestroyInfoRec(pFfb->pDRIInfo); - xfree(pFfbDRI); - return FALSE; - } - -#if 000 /* XXX this should be cleaned up and used */ - /* Check the ffb DRM version */ - version = drmGetVersion(info->drmFD); - if (version) { - if (version->version_major != 1 || - version->version_minor < 0) { - /* incompatible drm version */ - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] FFBDRIScreenInit failed because of a version mismatch.\n" - "[dri] ffb.o kernel module version is %d.%d.%d but version 1.0.x is needed.\n" - "[dri] Disabling the DRI.\n", - version->version_major, - version->version_minor, - version->version_patchlevel); - drmFreeVersion(version); - R128DRICloseScreen(pScreen); - return FALSE; - } - drmFreeVersion(version); - } -#endif - - pFfb->pFfbSarea = DRIGetSAREAPrivate(pScreen); - init_ffb_sarea(pFfb, pFfb->pFfbSarea); - - /* Setup device specific direct rendering memory maps. */ - if (drmAddMap(pFfb->drmSubFD, - FFB_FBC_REGS_POFF, FFB_FBC_REGS_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hFbcRegs) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sFbcRegs = FFB_FBC_REGS_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] FBC Register handle = 0x%08x\n", - pFfbDRI->hFbcRegs); - - if (drmAddMap(pFfb->drmSubFD, - FFB_DAC_POFF, FFB_DAC_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hDacRegs) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sDacRegs = FFB_DAC_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] DAC Register handle = 0x%08x\n", - pFfbDRI->hDacRegs); - - /* Now add maps for the "Smart" views of the framebuffer. */ - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB8R_POFF, FFB_SFB8R_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb8r) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb8r = FFB_SFB8R_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB8R handle = 0x%08x\n", - pFfbDRI->hSfb8r); - - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB32_POFF, FFB_SFB32_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb32) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb32 = FFB_SFB32_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB32 handle = 0x%08x\n", - pFfbDRI->hSfb32); - - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB64_POFF, FFB_SFB64_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb64) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb64 = FFB_SFB64_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB64 handle = 0x%08x\n", - pFfbDRI->hSfb64); - - /* Setup visual configurations. */ - if (!FFBDRIInitVisualConfigs(pScreen)) { - DRICloseScreen(pScreen); - return FALSE; - } - - xf86DrvMsg(pScrn->scrnIndex, X_INFO, - "[drm] Visual configs initialized\n"); - - return TRUE; -} - -void -FFBDRICloseScreen(ScreenPtr pScreen) -{ - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - - DRICloseScreen(pScreen); - - if (pFfb->pDRIInfo) { - DRIInfoPtr pDRIInfo = pFfb->pDRIInfo; - - if (pDRIInfo->devPrivate) - xfree(pDRIInfo->devPrivate); - DRIDestroyInfoRec(pDRIInfo); - pFfb->pDRIInfo = NULL; - } - - if (pFfb->pVisualConfigs) { - xfree(pFfb->pVisualConfigs); - pFfb->pVisualConfigs = NULL; - } - if (pFfb->pVisualConfigsPriv) { - xfree(pFfb->pVisualConfigsPriv); - pFfb->pVisualConfigsPriv = NULL; - } -} - -static Bool -FFBDRICreateContext(ScreenPtr pScreen, VisualPtr visual, drm_context_t hwContext, - void *pVisualConfigPriv, DRIContextType context) -{ - /* Nothing to do... */ - return TRUE; -} - -static void -FFBDRIDestroyContext(ScreenPtr pScreen, drm_context_t hwContext, DRIContextType context) -{ - /* Nothing to do... */ -} - -Bool -FFBDRIFinishScreenInit(ScreenPtr pScreen) -{ - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - DRIInfoPtr pDRIInfo = pFfb->pDRIInfo; - FFBDRIPtr pFfbDRI = (FFBDRIPtr) pDRIInfo->devPrivate; - int i; - - /* This belongs in the kernel. I'm sorry, the rest - * of the current DRI switching mechanisms just suck. - */ - pDRIInfo->driverSwapMethod = DRI_KERNEL_SWAP; - - /* Copy over the fast/page filling parameters now that - * acceleration has been fully setup. - */ - pFfbDRI->disable_pagefill = pFfb->disable_pagefill; - pFfbDRI->fastfill_small_area = FFB_FFPARMS(pFfb).fastfill_small_area; - pFfbDRI->pagefill_small_area = FFB_FFPARMS(pFfb).pagefill_small_area; - pFfbDRI->fastfill_height = FFB_FFPARMS(pFfb).fastfill_height; - pFfbDRI->fastfill_width = FFB_FFPARMS(pFfb).fastfill_width; - pFfbDRI->pagefill_height = FFB_FFPARMS(pFfb).pagefill_height; - pFfbDRI->pagefill_width = FFB_FFPARMS(pFfb).pagefill_width; - for (i = 0; i < 0x800; i++) - pFfbDRI->Pf_AlignTab[i] = pFfb->Pf_AlignTab[i]; - - return DRIFinishScreenInit(pScreen); -} - -static void -FFBDRIInitBuffers(WindowPtr pWin, RegionPtr prgn, CARD32 index) -{ - ScreenPtr pScreen = pWin->drawable.pScreen; - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - CreatorPrivWinPtr pFfbPrivWin = CreatorGetWindowPrivate(pWin); - ffb_fbcPtr ffb = pFfb->regs; - unsigned int fbc; - BoxPtr pBox; - int nBox; - - fbc = pFfbPrivWin->fbc_base; - fbc = (fbc & ~FFB_FBC_WB_MASK) | FFB_FBC_WB_AB; - fbc = (fbc & ~FFB_FBC_XE_MASK) | FFB_FBC_XE_ON; - fbc = (fbc & ~FFB_FBC_RGBE_MASK) | FFB_FBC_RGBE_OFF; - - pBox = REGION_RECTS(prgn); - nBox = (int) REGION_NUM_RECTS(prgn); - FFB_WRITE_ROP(pFfb, ffb, (FFB_ROP_NEW | (FFB_ROP_NEW << 8))); - FFB_WRITE_PPC(pFfb, ffb, - (FFB_PPC_APE_DISABLE | FFB_PPC_CS_CONST | FFB_PPC_XS_WID), - (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK | FFB_PPC_XS_MASK)); - FFB_WRITE_PMASK(pFfb, ffb, ~0); - FFB_WRITE_DRAWOP(pFfb, ffb, FFB_DRAWOP_RECTANGLE); - FFB_WRITE_FBC(pFfb, ffb, fbc); - FFB_WRITE_WID(pFfb, ffb, FFB_WID_WIN(pWin)); - - while(nBox--) { - register int x, y, w, h; - - x = pBox->x1; - y = pBox->y1; - w = (pBox->x2 - x); - h = (pBox->y2 - y); - FFBFifo(pFfb, 4); - FFB_WRITE64(&ffb->by, y, x); - FFB_WRITE64_2(&ffb->bh, h, w); - pBox++; - } - pFfb->rp_active = 1; - FFBSync(pFfb, ffb); -} - -static void -FFBDRIMoveBuffers(WindowPtr pParent, DDXPointRec ptOldOrg, - RegionPtr prgnSrc, CARD32 index) -{ -} - -static void -FFBDRISetDrawableIndex(WindowPtr pWin, CARD32 index) -{ - ScreenPtr pScreen = pWin->drawable.pScreen; - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - CreatorPrivWinPtr pFfbPrivWin = CreatorGetWindowPrivate(pWin); - unsigned int wid; - - if (FFBWidIsShared(pFfb, pFfbPrivWin->wid)) { - wid = FFBWidUnshare(pFfb, pFfbPrivWin->wid); - if (wid == (unsigned int) -1) - return; - - ErrorF("FFB: Allocated WID %x for DRI window.\n", wid); - pFfbPrivWin->wid = wid; - - /* Now update the SAREA. */ - pFfb->pFfbSarea->wid_table[index] = wid; - } -} diff --git a/src/ffb_drishare.h b/src/ffb_drishare.h deleted file mode 100644 index d4f4a08..0000000 --- a/src/ffb_drishare.h +++ /dev/null @@ -1,48 +0,0 @@ -/* $XFree86$ */ - -#ifndef _FFB_DRISHARE_H -#define _FFB_DRISHARE_H - -typedef struct ffb_dri_state { - int flags; -#define FFB_DRI_FFB2 0x00000001 -#define FFB_DRI_FFB2PLUS 0x00000002 -#define FFB_DRI_PAC1 0x00000004 -#define FFB_DRI_PAC2 0x00000008 - - /* Indexed by DRI drawable id. */ -#define FFB_DRI_NWIDS 64 - unsigned int wid_table[FFB_DRI_NWIDS]; -} ffb_dri_state_t; - -#define FFB_DRISHARE(SAREA) \ - ((ffb_dri_state_t *) (((char *)(SAREA)) + sizeof(drm_sarea_t))) - -typedef struct { - drm_handle_t hFbcRegs; - drmSize sFbcRegs; - - drm_handle_t hDacRegs; - drmSize sDacRegs; - - drm_handle_t hSfb8r; - drmSize sSfb8r; - - drm_handle_t hSfb32; - drmSize sSfb32; - - drm_handle_t hSfb64; - drmSize sSfb64; - - /* Fastfill/Pagefill parameters. */ - unsigned char disable_pagefill; - int fastfill_small_area; - int pagefill_small_area; - int fastfill_height; - int fastfill_width; - int pagefill_height; - int pagefill_width; - short Pf_AlignTab[0x800]; -} FFBDRIRec, *FFBDRIPtr; - -#endif /* !(_FFB_DRISHARE_H) */ diff --git a/src/ffb_driver.c b/src/ffb_driver.c index a720612..5e329e8 100644 --- a/src/ffb_driver.c +++ b/src/ffb_driver.c @@ -432,22 +432,6 @@ FFBPreInit(ScrnInfoPtr pScrn, int flags) return FALSE; } -#if 0 -/*#ifdef XF86DRI*/ -/* - * Loading this automatically isn't compatible - * to the behavior of other drivers - */ - if (xf86LoadSubModule(pScrn, "drm") == NULL) { - FFBFreeRec(pScrn); - return FALSE; - } - - if (xf86LoadSubModule(pScrn, "dri") == NULL) { - FFBFreeRec(pScrn); - return FALSE; - } -#endif /********************* set up clock and mode stuff @@ -740,21 +724,6 @@ FFBScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) if (!miSetPixmapDepths()) return FALSE; -#if 0 /*def XF86DRI*/ - if (pFfb->ffb_type != afb_m3 && pFfb->ffb_type != afb_m6 && - pFfb->NoAccel == FALSE) { - pFfb->dri_enabled = FFBDRIScreenInit(pScreen); - if (pFfb->dri_enabled == TRUE) - xf86Msg(X_INFO, "%s: DRM initialized\n", - pFfb->psdp->device); - else - xf86Msg(X_INFO, "%s: DRM setup failed\n", - pFfb->psdp->device); - } else { - pFfb->dri_enabled = FALSE; - } -#endif - /* * Call the framebuffer layer's ScreenInit function, and fill in other * pScreen fields. @@ -832,21 +801,6 @@ FFBScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) if (!pFfb->NoAccel) FFB_InitDGA(pScreen); -#if 0 /*def XF86DRI*/ - if (pFfb->dri_enabled) { - /* Now that mi, fb, drm and others have done their thing, - * complete the DRI setup. - */ - pFfb->dri_enabled = FFBDRIFinishScreenInit(pScreen); - if (pFfb->dri_enabled) - xf86Msg(X_INFO, "%s: DRM finish setup complete\n", - pFfb->psdp->device); - else - xf86Msg(X_INFO, "%s: DRM finish setup failed\n", - pFfb->psdp->device); - } -#endif - xf86DPMSInit(pScreen, FFBDPMSSet, 0); pFfb->CloseScreen = pScreen->CloseScreen; @@ -948,11 +902,6 @@ FFBCloseScreen(int scrnIndex, ScreenPtr pScreen) ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); -#if 0 /*def XF86DRI*/ - if (pFfb->dri_enabled) - FFBDRICloseScreen(pScreen); -#endif - /* Restore kernel ramdac state before we unmap registers. */ FFBDacFini(pFfb); @@ -1010,7 +959,9 @@ FFBSaveScreen(ScreenPtr pScreen, int mode) done in "ffb_dac.c" `for aesthetic reasons.' */ { - return FFBDacSaveScreen(GET_FFB_FROM_SCREEN(pScreen), mode); + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + + return FFBDacSaveScreen(GET_FFB_FROM_SCRN(pScrn), mode); } static void diff --git a/src/ffb_rcache.h b/src/ffb_rcache.h index a9bac9b..f8c17b9 100644 --- a/src/ffb_rcache.h +++ b/src/ffb_rcache.h @@ -147,57 +147,8 @@ extern void __FFB_Attr_Raw(FFBPtr pFfb, #define FFB_PPC_GCMASK (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK) -/* This is for loading the FFB attributes for the case where - * where most of the values come directly from the graphics - * context and only the PPC and DRAWOP are variable. - */ -extern void __FFB_Attr_GC(FFBPtr pFfb, GCPtr pGC, WindowPtr pWin, - unsigned int ppc, int drawop); - -#define FFB_ATTR_GC(__fpriv, __pgc, __pwin, __ppc, __drawop) \ -do { CreatorPrivWinPtr __winpriv = CreatorGetWindowPrivate(__pwin); \ - unsigned int __rop = ((__pgc)->alu | FFB_ROP_EDIT_BIT); \ - unsigned int __fbc = ((__winpriv)->fbc_base); \ - __fbc &= ~FFB_FBC_XE_MASK; \ - __fbc |= FFB_FBC_XE_OFF; \ - __rop |= (FFB_ROP_NEW << 8); \ - if ((((__fpriv)->ppc_cache & FFB_PPC_GCMASK) != (__ppc))|| \ - ((__fpriv)->pmask_cache != ((__pgc)->planemask)) || \ - ((__fpriv)->rop_cache != (__rop)) || \ - ((__fpriv)->drawop_cache != (__drawop)) || \ - ((__fpriv)->fg_cache != ((__pgc)->fgPixel)) || \ - ((__fpriv)->fbc_cache != __fbc)) \ - __FFB_Attr_GC(__fpriv, __pgc, __pwin, __ppc, __drawop); \ -} while(0) - #define FFB_PPC_WINMASK (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK | FFB_PPC_XS_MASK) -extern void __FFB_Attr_FastfillWin(FFBPtr pFfb, WindowPtr pWin, - unsigned int ppc, unsigned int pixel); - -#define FFB_ATTR_FFWIN(__fpriv, __pwin, __ppc, __pixel) \ -do { CreatorPrivWinPtr __winpriv = CreatorGetWindowPrivate(__pwin); \ - unsigned int ___ppc = (__ppc) | FFB_PPC_XS_WID; \ - unsigned int __fbc = (__winpriv)->fbc_base; \ - unsigned int __rop = (FFB_ROP_NEW|(FFB_ROP_NEW<<8)); \ - if((__fpriv)->has_double_buffer) { \ - __fbc &= ~FFB_FBC_WB_MASK; \ - __fbc |= FFB_FBC_WB_AB; \ - } \ - __fbc &= ~(FFB_FBC_XE_MASK | FFB_FBC_RGBE_MASK); \ - __fbc |= FFB_FBC_XE_ON | FFB_FBC_RGBE_ON; \ - if (pFfb->ffb_res == ffb_res_high) \ - __fbc |= FFB_FBC_WB_B; \ - if ((((__fpriv)->ppc_cache & FFB_PPC_WINMASK) != (___ppc))|| \ - ((__fpriv)->pmask_cache != 0x00ffffff) || \ - ((__fpriv)->rop_cache!= __rop) || \ - ((__fpriv)->drawop_cache != FFB_DRAWOP_FASTFILL) || \ - ((__fpriv)->fg_cache != (__pixel)) || \ - ((__fpriv)->fbc_cache != __fbc) || \ - ((__fpriv)->wid_cache != ((__winpriv)->wid))) \ - __FFB_Attr_FastfillWin(__fpriv, __pwin, ___ppc, __pixel);\ -} while (0) - /* We have to be careful when copying windows around. For that * case we will use either VIS copies or hw accelerated VSCROLL. * All of the planes needs to be copied in the framebuffer from @@ -327,7 +278,4 @@ do { unsigned int __rop = (FFB_ROP_OLD | (FFB_ROP_OLD << 8)); \ } \ } while(0) -#define FFB_FBC_WIN(pWin) CreatorGetWindowPrivate(pWin)->fbc_base -#define FFB_WID_WIN(pWin) CreatorGetWindowPrivate(pWin)->wid - #endif /* FFBRCACHE_H */ diff --git a/src/ffb_wid.c b/src/ffb_wid.c index 294a4f1..f9a13a8 100644 --- a/src/ffb_wid.c +++ b/src/ffb_wid.c @@ -449,20 +449,3 @@ FFBWidChangeBuffer(FFBPtr pFfb, unsigned int wid, int visible) update_wids(pFfb, index); } } - -/* Used by DRI part of driver. */ -Bool -FFBWidIsShared(FFBPtr pFfb, unsigned int wid) -{ - ffb_dac_info_t *p = &pFfb->dac_info; - ffb_wid_pool_t *table = &p->wid_table; - int index = wid >> table->wid_shift; - - if (index < 0 || index >= table->num_wids) - return TRUE; - - if (table->wid_pool[index].canshare == TRUE) - return TRUE; - - return FALSE; -} From davem at davemloft.net Thu Dec 27 15:47:02 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 15:47:02 -0800 (PST) Subject: [PATCH]: Fix sunffb driver build. In-Reply-To: <20071227.154229.49825569.davem@davemloft.net> References: <20071227.154229.49825569.davem@davemloft.net> Message-ID: <20071227.154702.58187586.davem@davemloft.net> From: David Miller Date: Thu, 27 Dec 2007 15:42:29 -0800 (PST) > [SUNFFB]: Fix build after devprivates rework. > > This driver uses devprivates of all kinds, but this is > only done in deprecated and unused code so we can simply > remove it all. > > DRM/DRI support has been commented out for years, and was > done during the conversion over to XAA acceleration. This > code would need to be essentially rewritten to work again, > so we can just remove this stuff for now. > > The rest were either: > > 1) DRI/DRM related uses > 2) the private allocation code > 3) cases that could index to the pScrn to get the FFB private > > And that's all fixed up here. > > Signed-off-by: David S. Miller Sorry, I forgot to remove the ffb_dri.c/ffb_drishare.h references in src/Makefile.am, please use this patch instead, thanks! [SUNFFB]: Fix build after devprivates rework. This driver uses devprivates of all kinds, but this is only done in deprecated and unused code so we can simply remove it all. DRM/DRI support has been commented out for years, and was done during the conversion over to XAA acceleration. This code would need to be essentially rewritten to work again, so we can just remove this stuff for now. The rest were either: 1) DRI/DRM related uses 2) the private allocation code 3) cases that could index to the pScrn to get the FFB private And that's all fixed up here. Signed-off-by: David S. Miller diff --git a/src/Makefile.am b/src/Makefile.am index f1832bc..3e10f3a 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -48,9 +48,3 @@ sunffb_drv_la_SOURCES = \ ffb_regs.h \ ffb_wid.c \ $(SPARC_ASM_SRC) - -if DRI -sunffb_drv_la_SOURCES += \ - ffb_dri.c \ - ffb_drishare.h -endif diff --git a/src/ffb.h b/src/ffb.h index cb21251..ea1b7fc 100644 --- a/src/ffb.h +++ b/src/ffb.h @@ -39,10 +39,6 @@ #include "ffb_regs.h" #include "xf86sbusBus.h" #include "ffb_dac.h" -#ifdef XF86DRI -#include "xf86drm.h" -#include "ffb_drishare.h" -#endif #ifndef DPMS_SERVER #define DPMS_SERVER #endif /* DPMS_SERVER */ @@ -97,14 +93,6 @@ typedef struct { unsigned int bits[32]; /* The stipple bits themselves */ } CreatorStippleRec, *CreatorStipplePtr; -typedef struct { - int type; - unsigned int linepat; - CreatorStipplePtr stipple; - void (*PolySegment)(DrawablePtr, GCPtr, int, xSegment *); - void (*Polylines)(DrawablePtr, GCPtr, int, int, DDXPointPtr); -} CreatorPrivGCRec, *CreatorPrivGCPtr; - /* WID and framebuffer controls are a property of the * window. */ @@ -135,12 +123,6 @@ enum ffb_chip_type { afb_m6 /* FCS Elite3D, 6 float chips */ }; -#ifdef XF86DRI -typedef struct { - int index; -} FFBConfigPrivRec, *FFBConfigPrivPtr; -#endif - typedef struct { unsigned short fifo_cache; unsigned short rp_active; @@ -221,16 +203,6 @@ typedef struct { void *I2C; struct ffb_dac_info dac_info; -#ifdef XF86DRI - void *pDRIInfo; - int numVisualConfigs; - void *pVisualConfigs; - FFBConfigPrivPtr pVisualConfigsPriv; - int drmSubFD; - Bool dri_enabled; - ffb_dri_state_t *pFfbSarea; -#endif - OptionInfoPtr Options; } FFBRec, *FFBPtr; @@ -261,18 +233,10 @@ extern void FFBWidFree(FFBPtr, unsigned int); extern unsigned int FFBWidUnshare(FFBPtr, unsigned int); extern unsigned int FFBWidReshare(FFBPtr, unsigned int); extern void FFBWidChangeBuffer(FFBPtr, unsigned int, int); -extern Bool FFBWidIsShared(FFBPtr pFfb, unsigned int wid); /* Accelerated double-buffering. */ extern Bool FFBDbePreInit(ScreenPtr); -#ifdef XF86DRI -/* DRI support */ -extern Bool FFBDRIScreenInit(ScreenPtr); -extern Bool FFBDRIFinishScreenInit(ScreenPtr); -extern void FFBDRICloseScreen(ScreenPtr); -#endif - /* The fastfill and pagefill buffer sizes change based upon * the resolution. */ @@ -290,24 +254,8 @@ extern struct fastfill_parms ffb_fastfill_parms[]; #define FFB_FFPARMS(__fpriv) (ffb_fastfill_parms[(__fpriv)->ffb_res]) -extern int CreatorScreenPrivateIndex; -extern int CreatorGCPrivateIndex; -extern int CreatorWindowPrivateIndex; - #define GET_FFB_FROM_SCRN(p) ((FFBPtr)((p)->driverPrivate)) -#define GET_FFB_FROM_SCREEN(s) \ -((FFBPtr)(s)->devPrivates[CreatorScreenPrivateIndex].ptr) - -#define CreatorGetGCPrivate(g) \ -((CreatorPrivGCPtr) (g)->devPrivates [CreatorGCPrivateIndex].ptr) - -#define CreatorGetWindowPrivate(w) \ -((CreatorPrivWinPtr) (w)->devPrivates[CreatorWindowPrivateIndex].ptr) - -#define CreatorSetWindowPrivate(w,p) \ -((w)->devPrivates[CreatorWindowPrivateIndex].ptr = (pointer) p) - #undef DEBUG_FFB #ifdef DEBUG_FFB diff --git a/src/ffb_accel.c b/src/ffb_accel.c index b9cb053..b8ad1d0 100644 --- a/src/ffb_accel.c +++ b/src/ffb_accel.c @@ -44,11 +44,6 @@ #include "ffb_loops.h" #include "ffb_regs.h" -int CreatorScreenPrivateIndex; -int CreatorGCPrivateIndex; -int CreatorWindowPrivateIndex; -int CreatorGeneration; - /* Indexed by ffb resolution enum. */ struct fastfill_parms ffb_fastfill_parms[] = { /* fsmall, psmall, ffh, ffw, pfh, pfw */ @@ -61,7 +56,8 @@ struct fastfill_parms ffb_fastfill_parms[] = { void CreatorVtChange (ScreenPtr pScreen, int enter) { - FFBPtr pFfb = GET_FFB_FROM_SCREEN (pScreen); + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + FFBPtr pFfb = GET_FFB_FROM_SCRN (pScrn); ffb_fbcPtr ffb = pFfb->regs; pFfb->rp_active = 1; @@ -847,22 +843,6 @@ Bool FFBAccelInit(ScreenPtr pScreen, FFBPtr pFfb) XAAInfoRecPtr infoRec; ffb_fbcPtr ffb = pFfb->regs; - if (serverGeneration != CreatorGeneration) { - CreatorScreenPrivateIndex = AllocateScreenPrivateIndex (); - if (CreatorScreenPrivateIndex == -1) - return FALSE; - CreatorGCPrivateIndex = AllocateGCPrivateIndex (); - CreatorWindowPrivateIndex = AllocateWindowPrivateIndex (); - CreatorGeneration = serverGeneration; - } - - if (!AllocateGCPrivate(pScreen, CreatorGCPrivateIndex, sizeof(CreatorPrivGCRec))) - return FALSE; - if (!AllocateWindowPrivate(pScreen, CreatorWindowPrivateIndex, 0)) - return FALSE; - - pScreen->devPrivates[CreatorScreenPrivateIndex].ptr = pFfb; - pFfb->xaa_fbc = (FFB_FBC_WB_A | FFB_FBC_WM_COMBINED | FFB_FBC_RB_A | FFB_FBC_WE_FORCEON | FFB_FBC_SB_BOTH | diff --git a/src/ffb_attr.c b/src/ffb_attr.c index 7b0d375..e1a3771 100644 --- a/src/ffb_attr.c +++ b/src/ffb_attr.c @@ -81,180 +81,3 @@ void __FFB_Attr_SFB_VAR(FFBPtr pFfb, unsigned int ppc, unsigned int ppc_mask, un ffb->rop = rop; ffb->pmask = pmask; } - -#define NEED_PPC 0x00000001 -#define NEED_PMASK 0x00000002 -#define NEED_ROP 0x00000004 -#define NEED_DRAWOP 0x00000008 -#define NEED_FG 0x00000010 -#define NEED_BG 0x00000020 -#define NEED_FBC 0x00000040 -#define NEED_WID 0x00000080 - -void __FFB_Attr_GC(FFBPtr pFfb, GCPtr pGC, WindowPtr pWin, unsigned int ppc, int drawop) -{ - ffb_fbcPtr ffb = pFfb->regs; - unsigned int rop, need_mask, need_count; - - need_mask = need_count = 0; - if ((pFfb->ppc_cache & FFB_PPC_GCMASK) != ppc) { - unsigned int newppc = pFfb->ppc_cache & ~FFB_PPC_GCMASK; - - newppc |= (ppc & FFB_PPC_GCMASK); - pFfb->ppc_cache = newppc; - need_mask |= NEED_PPC; - need_count++; - } - - if (pFfb->pmask_cache != pGC->planemask) { - pFfb->pmask_cache = pGC->planemask; - need_mask |= NEED_PMASK; - need_count++; - } - - rop = (pGC->alu | FFB_ROP_EDIT_BIT)|(FFB_ROP_NEW<<8); - if (pFfb->rop_cache != rop) { - pFfb->rop_cache = rop; - need_mask |= NEED_ROP; - need_count++; - } - - if (pFfb->drawop_cache != drawop) { - pFfb->drawop_cache = drawop; - need_mask |= NEED_DRAWOP; - need_count++; - } - - if (pFfb->fg_cache != pGC->fgPixel) { - pFfb->fg_cache = pGC->fgPixel; - need_mask |= NEED_FG; - need_count++; - } - - { - CreatorPrivWinPtr WinPriv = CreatorGetWindowPrivate(pWin); - unsigned int fbc = WinPriv->fbc_base; - - fbc &= ~FFB_FBC_XE_MASK; - fbc |= FFB_FBC_XE_OFF; - - if (pFfb->fbc_cache != fbc) { - pFfb->fbc_cache = fbc; - need_mask |= NEED_FBC; - need_count++; - } - - } - pFfb->rp_active = 1; - - FFBLOG(("WRATTRS_GC: PPC[%08x:%08x] PMSK[%08x] ROP[%08x] " - "DOP[%08x] FG[%08x] FBC[%08x]\n", - pFfb->ppc_cache & FFB_PPC_GCMASK, FFB_PPC_GCMASK, - pFfb->pmask_cache, pFfb->rop_cache, - pFfb->drawop_cache, pFfb->fg_cache, pFfb->fbc_cache)); - - FFBFifo(pFfb, need_count); - if (need_mask & NEED_PPC) - ffb->ppc = (pFfb->ppc_cache & FFB_PPC_GCMASK); - if (need_mask & NEED_PMASK) - ffb->pmask = pFfb->pmask_cache; - if (need_mask & NEED_ROP) - ffb->rop = pFfb->rop_cache; - if (need_mask & NEED_DRAWOP) - ffb->drawop = pFfb->drawop_cache; - if (need_mask & NEED_FG) - ffb->fg = pFfb->fg_cache; - if (need_mask & NEED_FBC) - ffb->fbc = pFfb->fbc_cache; -} - -void __FFB_Attr_FastfillWin(FFBPtr pFfb, WindowPtr pWin, - unsigned int ppc, unsigned int pixel) -{ - ffb_fbcPtr ffb = pFfb->regs; - unsigned int rop, need_mask, need_count; - - need_mask = need_count = 0; - if ((pFfb->ppc_cache & FFB_PPC_WINMASK) != ppc) { - unsigned int newppc = pFfb->ppc_cache & ~FFB_PPC_WINMASK; - - newppc |= (ppc & FFB_PPC_WINMASK); - pFfb->ppc_cache = newppc; - need_mask |= NEED_PPC; - need_count++; - } - - if (pFfb->pmask_cache != 0x00ffffff) { - pFfb->pmask_cache = 0x00ffffff; - need_mask |= NEED_PMASK; - need_count++; - } - - rop = FFB_ROP_NEW | (FFB_ROP_NEW<<8); - if (pFfb->rop_cache != rop) { - pFfb->rop_cache = rop; - need_mask |= NEED_ROP; - need_count++; - } - - if (pFfb->drawop_cache != FFB_DRAWOP_FASTFILL) { - pFfb->drawop_cache = FFB_DRAWOP_FASTFILL; - need_mask |= NEED_DRAWOP; - need_count++; - } - - if (pFfb->fg_cache != pixel) { - pFfb->fg_cache = pixel; - need_mask |= NEED_FG; - need_count++; - } - - { - CreatorPrivWinPtr pWinPriv = CreatorGetWindowPrivate(pWin); - unsigned int fbc = pWinPriv->fbc_base; - - if (pFfb->has_double_buffer) { - fbc &= ~FFB_FBC_WB_MASK; - fbc |= FFB_FBC_WB_AB; - } - fbc &= ~(FFB_FBC_XE_MASK | FFB_FBC_RGBE_MASK); - fbc |= FFB_FBC_XE_ON | FFB_FBC_RGBE_ON; - if (pFfb->ffb_res == ffb_res_high) - fbc |= FFB_FBC_WB_B; - - if (pFfb->fbc_cache != fbc) { - pFfb->fbc_cache = fbc; - need_mask |= NEED_FBC; - need_count++; - } - - if (pFfb->wid_cache != pWinPriv->wid) { - pFfb->wid_cache = pWinPriv->wid; - need_mask |= NEED_WID; - need_count++; - } - } - - pFfb->rp_active = 1; - - FFBLOG(("WRATTRS_GC: PPC[%08x:%08x] PMSK[%08x] ROP[%08x] DOP[%08x] FG[%08x] FBC[%08x] WID[%02x]\n", - pFfb->ppc_cache & FFB_PPC_WINMASK, FFB_PPC_WINMASK, - pFfb->pmask_cache, pFfb->rop_cache, - pFfb->drawop_cache, pFfb->fg_cache, pFfb->fbc_cache, pFfb->wid_cache)); - - FFBFifo(pFfb, need_count); - if (need_mask & NEED_PPC) - ffb->ppc = (pFfb->ppc_cache & FFB_PPC_WINMASK); - if (need_mask & NEED_PMASK) - ffb->pmask = pFfb->pmask_cache; - if (need_mask & NEED_ROP) - ffb->rop = pFfb->rop_cache; - if (need_mask & NEED_DRAWOP) - ffb->drawop = pFfb->drawop_cache; - if (need_mask & NEED_FG) - ffb->fg = pFfb->fg_cache; - if (need_mask & NEED_FBC) - ffb->fbc = pFfb->fbc_cache; - if (need_mask & NEED_WID) - ffb->wid = pFfb->wid_cache; -} diff --git a/src/ffb_dri.c b/src/ffb_dri.c deleted file mode 100644 index dd471d4..0000000 --- a/src/ffb_dri.c +++ /dev/null @@ -1,521 +0,0 @@ -/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/sunffb/ffb_dri.c,v 1.8 2001/04/18 14:52:42 dawes Exp $ - * Acceleration for the Creator and Creator3D framebuffer - DRI/DRM support. - * - * Copyright (C) 2000 David S. Miller (davem at redhat.com) - * - * Permission is hereby granted, free of charge, to any person obtaining a copy - * of this software and associated documentation files (the "Software"), to deal - * in the Software without restriction, including without limitation the rights - * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell - * copies of the Software, and to permit persons to whom the Software is - * furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * DAVID MILLER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN - * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION - * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - * - */ - -#ifdef HAVE_CONFIG_H -#include "config.h" -#endif - -#include - -#include "xf86.h" -#include "xf86_OSproc.h" -#include "xf86Priv.h" - -#include "xf86PciInfo.h" -#include "xf86Pci.h" - -#include "miline.h" - -#include "GL/glxtokens.h" - -#include "xf86drm.h" -#include "sarea.h" -#define _XF86DRI_SERVER_ -#include "dri.h" - -#include "GL/glxint.h" - -#include "ffb.h" -#include "ffb_regs.h" -#include "ffb_fifo.h" -#include "ffb_rcache.h" - -static char FFBKernelDriverName[] = "ffb"; -static char FFBClientDriverName[] = "ffb"; - -/* Forward declarations. */ -static Bool FFBDRICreateContext(ScreenPtr, VisualPtr, drm_context_t, - void *, DRIContextType); -static void FFBDRIDestroyContext(ScreenPtr, drm_context_t, DRIContextType); - -static void FFBDRIInitBuffers(WindowPtr, RegionPtr, CARD32); -static void FFBDRIMoveBuffers(WindowPtr, DDXPointRec, RegionPtr, CARD32); - -static void FFBDRISetDrawableIndex(WindowPtr, CARD32); - -/* XXX Why isn't this in a header somewhere? XXX */ -extern void GlxSetVisualConfigs(int nconfigs, __GLXvisualConfig *configs, - void **configprivs); - -static Bool -FFBDRIInitVisualConfigs(ScreenPtr pScreen) -{ - ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; - FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); - __GLXvisualConfig *pConfigs; - FFBConfigPrivPtr pFfbConfigs; - FFBConfigPrivPtr *pFfbConfigPtrs; - - pConfigs = (__GLXvisualConfig *) - xcalloc(sizeof(__GLXvisualConfig), 1); - if (!pConfigs) - return FALSE; - - pFfbConfigs = (FFBConfigPrivPtr) - xcalloc(sizeof(FFBConfigPrivRec), 1); - if (!pFfbConfigs) { - xfree(pConfigs); - return FALSE; - } - - pFfbConfigPtrs = (FFBConfigPrivPtr *) - xcalloc(sizeof(FFBConfigPrivPtr), 1); - if (!pFfbConfigPtrs) { - xfree(pConfigs); - xfree(pFfbConfigs); - return FALSE; - } - - pFfbConfigPtrs[0] = &pFfbConfigs[0]; - - pConfigs->vid = -1; - pConfigs->class = -1; - pConfigs->rgba = TRUE; - pConfigs->redSize = 8; - pConfigs->greenSize = 8; - pConfigs->blueSize = 8; - pConfigs->alphaSize = 0; - pConfigs->redMask = 0x000000ff; - pConfigs->greenMask = 0x0000ff00; - pConfigs->blueMask = 0x00ff0000; - pConfigs->alphaMask = 0; - pConfigs->accumRedSize = 0; - pConfigs->accumGreenSize = 0; - pConfigs->accumBlueSize = 0; - pConfigs->accumAlphaSize = 0; - pConfigs->doubleBuffer = TRUE; - pConfigs->stereo = FALSE; - pConfigs->bufferSize = 32; - pConfigs->depthSize = 16; - pConfigs->stencilSize = 0; - pConfigs->auxBuffers = 0; - pConfigs->level = 0; - pConfigs->visualRating = GLX_NONE; - pConfigs->transparentPixel = GLX_NONE; - pConfigs->transparentRed = 0; - pConfigs->transparentGreen = 0; - pConfigs->transparentBlue = 0; - pConfigs->transparentAlpha = 0; - pConfigs->transparentIndex = 0; - - pFfb->numVisualConfigs = 1; - pFfb->pVisualConfigs = pConfigs; - pFfb->pVisualConfigsPriv = pFfbConfigs; - - GlxSetVisualConfigs(1, pConfigs, (void **)pFfbConfigPtrs); - - return TRUE; -} - -static void -init_ffb_sarea(FFBPtr pFfb, ffb_dri_state_t *pFfbSarea) -{ - int i; - - pFfbSarea->flags = 0; - - switch (pFfb->ffb_type) { - case ffb2_prototype: - case ffb2_vertical: - case ffb2_vertical_plus: - case ffb2_horizontal: - case ffb2_horizontal_plus: - pFfbSarea->flags |= FFB_DRI_FFB2; - break; - - default: - break; - }; - - if (pFfb->ffb_type == ffb2_vertical_plus || - pFfb->ffb_type == ffb2_horizontal_plus) - pFfbSarea->flags |= FFB_DRI_FFB2PLUS; - - if (pFfb->dac_info.flags & FFB_DAC_PAC1) - pFfbSarea->flags |= FFB_DRI_PAC1; - - if (pFfb->dac_info.flags & FFB_DAC_PAC2) - pFfbSarea->flags |= FFB_DRI_PAC2; - - for (i = 0; i < FFB_DRI_NWIDS; i++) - pFfbSarea->wid_table[i] = 0; -} - -#define FFB_DFB24_POFF 0x02000000UL -#define FFB_DFB24_SIZE 0x01000000UL - -#define FFB_FBC_REGS_POFF 0x00600000UL -#define FFB_FBC_REGS_SIZE 0x00002000UL - -#define FFB_DAC_POFF 0x00400000UL -#define FFB_DAC_SIZE 0x00002000UL - -#define FFB_SFB8R_POFF 0x04000000UL -#define FFB_SFB8R_SIZE 0x00400000UL - -#define FFB_SFB32_POFF 0x05000000UL -#define FFB_SFB32_SIZE 0x01000000UL - -#define FFB_SFB64_POFF 0x06000000UL -#define FFB_SFB64_SIZE 0x02000000UL - -Bool -FFBDRIScreenInit(ScreenPtr pScreen) -{ - ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; - FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); - DRIInfoPtr pDRIInfo; - FFBDRIPtr pFfbDRI; - - /* Check that the GLX, DRI, and DRM modules have been loaded by testing - * for canonical symbols in each module. - */ - if (!xf86LoaderCheckSymbol("GlxSetVisualConfigs")) - return FALSE; - if (!xf86LoaderCheckSymbol("drmAvailable")) - return FALSE; - if (!xf86LoaderCheckSymbol("DRIQueryVersion")) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "FFBDRIScreenInit failed (libdri.a too old)\n"); - return FALSE; - } - - /* Check the DRI version */ - { - int major, minor, patch; - DRIQueryVersion(&major, &minor, &patch); - if (major != DRIINFO_MAJOR_VERSION || minor < DRIINFO_MINOR_VERSION) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] FFBDRIScreenInit failed because of a version mismatch.\n" - "[dri] libdri version is %d.%d.%d but version %d.%d.x is needed.\n" - "[dri] Disabling DRI.\n", - major, minor, patch, - DRIINFO_MAJOR_VERSION, DRIINFO_MINOR_VERSION); - return FALSE; - } - } - - pDRIInfo = DRICreateInfoRec(); - if (pDRIInfo == NULL) - return FALSE; - - pFfb->pDRIInfo = pDRIInfo; - - pDRIInfo->drmDriverName = FFBKernelDriverName; - pDRIInfo->clientDriverName = FFBClientDriverName; - - pDRIInfo->ddxDriverMajorVersion = 0; - pDRIInfo->ddxDriverMinorVersion = 1; - pDRIInfo->ddxDriverPatchVersion = 1; - - pDRIInfo->busIdString = xalloc(64); /* Freed in DRIDestroyInfoRec */ - sprintf(pDRIInfo->busIdString, "SBUS:%s", pFfb->psdp->device); - - /* Dumb rendering port for now... */ - pDRIInfo->frameBufferPhysicalAddress = FFB_DFB24_POFF; - pDRIInfo->frameBufferSize = FFB_DFB24_SIZE; - pDRIInfo->frameBufferStride = (2048 * 4); - - /* XXX */ - pDRIInfo->ddxDrawableTableEntry = 15; - pDRIInfo->maxDrawableTableEntry = 15; - pDRIInfo->SAREASize = (SAREA_MAX + (0x2000 - 1)) & ~(0x2000 - 1); - - pFfbDRI = (FFBDRIPtr) xcalloc(sizeof(FFBDRIRec), 1); - if (pFfbDRI == NULL) { - DRIDestroyInfoRec(pFfb->pDRIInfo); - return FALSE; - } - - pDRIInfo->devPrivate = pFfbDRI; - pDRIInfo->devPrivateSize = sizeof(*pFfbDRI); - pDRIInfo->contextSize = 0; /* kernel does ctx swaps */ - - pDRIInfo->CreateContext = FFBDRICreateContext; - pDRIInfo->DestroyContext = FFBDRIDestroyContext; - pDRIInfo->InitBuffers = FFBDRIInitBuffers; - pDRIInfo->MoveBuffers = FFBDRIMoveBuffers; - pDRIInfo->SetDrawableIndex = FFBDRISetDrawableIndex; - - /* Our InitBuffers depends heavily on this setting. */ - pDRIInfo->bufferRequests = DRI_3D_WINDOWS_ONLY; - - pDRIInfo->createDummyCtx = TRUE; - pDRIInfo->createDummyCtxPriv = FALSE; - - if (!DRIScreenInit(pScreen, pDRIInfo, &(pFfb->drmSubFD))) { - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] DRIScreenInit failed. Disabling DRI.\n"); - DRIDestroyInfoRec(pFfb->pDRIInfo); - xfree(pFfbDRI); - return FALSE; - } - -#if 000 /* XXX this should be cleaned up and used */ - /* Check the ffb DRM version */ - version = drmGetVersion(info->drmFD); - if (version) { - if (version->version_major != 1 || - version->version_minor < 0) { - /* incompatible drm version */ - xf86DrvMsg(pScreen->myNum, X_ERROR, - "[dri] FFBDRIScreenInit failed because of a version mismatch.\n" - "[dri] ffb.o kernel module version is %d.%d.%d but version 1.0.x is needed.\n" - "[dri] Disabling the DRI.\n", - version->version_major, - version->version_minor, - version->version_patchlevel); - drmFreeVersion(version); - R128DRICloseScreen(pScreen); - return FALSE; - } - drmFreeVersion(version); - } -#endif - - pFfb->pFfbSarea = DRIGetSAREAPrivate(pScreen); - init_ffb_sarea(pFfb, pFfb->pFfbSarea); - - /* Setup device specific direct rendering memory maps. */ - if (drmAddMap(pFfb->drmSubFD, - FFB_FBC_REGS_POFF, FFB_FBC_REGS_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hFbcRegs) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sFbcRegs = FFB_FBC_REGS_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] FBC Register handle = 0x%08x\n", - pFfbDRI->hFbcRegs); - - if (drmAddMap(pFfb->drmSubFD, - FFB_DAC_POFF, FFB_DAC_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hDacRegs) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sDacRegs = FFB_DAC_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] DAC Register handle = 0x%08x\n", - pFfbDRI->hDacRegs); - - /* Now add maps for the "Smart" views of the framebuffer. */ - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB8R_POFF, FFB_SFB8R_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb8r) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb8r = FFB_SFB8R_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB8R handle = 0x%08x\n", - pFfbDRI->hSfb8r); - - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB32_POFF, FFB_SFB32_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb32) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb32 = FFB_SFB32_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB32 handle = 0x%08x\n", - pFfbDRI->hSfb32); - - if (drmAddMap(pFfb->drmSubFD, - FFB_SFB64_POFF, FFB_SFB64_SIZE, - DRM_REGISTERS, 0, &pFfbDRI->hSfb64) < 0) { - DRICloseScreen(pScreen); - return FALSE; - } - pFfbDRI->sSfb64 = FFB_SFB64_SIZE; - - xf86DrvMsg(pScreen->myNum, X_INFO, - "[drm] SFB64 handle = 0x%08x\n", - pFfbDRI->hSfb64); - - /* Setup visual configurations. */ - if (!FFBDRIInitVisualConfigs(pScreen)) { - DRICloseScreen(pScreen); - return FALSE; - } - - xf86DrvMsg(pScrn->scrnIndex, X_INFO, - "[drm] Visual configs initialized\n"); - - return TRUE; -} - -void -FFBDRICloseScreen(ScreenPtr pScreen) -{ - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - - DRICloseScreen(pScreen); - - if (pFfb->pDRIInfo) { - DRIInfoPtr pDRIInfo = pFfb->pDRIInfo; - - if (pDRIInfo->devPrivate) - xfree(pDRIInfo->devPrivate); - DRIDestroyInfoRec(pDRIInfo); - pFfb->pDRIInfo = NULL; - } - - if (pFfb->pVisualConfigs) { - xfree(pFfb->pVisualConfigs); - pFfb->pVisualConfigs = NULL; - } - if (pFfb->pVisualConfigsPriv) { - xfree(pFfb->pVisualConfigsPriv); - pFfb->pVisualConfigsPriv = NULL; - } -} - -static Bool -FFBDRICreateContext(ScreenPtr pScreen, VisualPtr visual, drm_context_t hwContext, - void *pVisualConfigPriv, DRIContextType context) -{ - /* Nothing to do... */ - return TRUE; -} - -static void -FFBDRIDestroyContext(ScreenPtr pScreen, drm_context_t hwContext, DRIContextType context) -{ - /* Nothing to do... */ -} - -Bool -FFBDRIFinishScreenInit(ScreenPtr pScreen) -{ - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - DRIInfoPtr pDRIInfo = pFfb->pDRIInfo; - FFBDRIPtr pFfbDRI = (FFBDRIPtr) pDRIInfo->devPrivate; - int i; - - /* This belongs in the kernel. I'm sorry, the rest - * of the current DRI switching mechanisms just suck. - */ - pDRIInfo->driverSwapMethod = DRI_KERNEL_SWAP; - - /* Copy over the fast/page filling parameters now that - * acceleration has been fully setup. - */ - pFfbDRI->disable_pagefill = pFfb->disable_pagefill; - pFfbDRI->fastfill_small_area = FFB_FFPARMS(pFfb).fastfill_small_area; - pFfbDRI->pagefill_small_area = FFB_FFPARMS(pFfb).pagefill_small_area; - pFfbDRI->fastfill_height = FFB_FFPARMS(pFfb).fastfill_height; - pFfbDRI->fastfill_width = FFB_FFPARMS(pFfb).fastfill_width; - pFfbDRI->pagefill_height = FFB_FFPARMS(pFfb).pagefill_height; - pFfbDRI->pagefill_width = FFB_FFPARMS(pFfb).pagefill_width; - for (i = 0; i < 0x800; i++) - pFfbDRI->Pf_AlignTab[i] = pFfb->Pf_AlignTab[i]; - - return DRIFinishScreenInit(pScreen); -} - -static void -FFBDRIInitBuffers(WindowPtr pWin, RegionPtr prgn, CARD32 index) -{ - ScreenPtr pScreen = pWin->drawable.pScreen; - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - CreatorPrivWinPtr pFfbPrivWin = CreatorGetWindowPrivate(pWin); - ffb_fbcPtr ffb = pFfb->regs; - unsigned int fbc; - BoxPtr pBox; - int nBox; - - fbc = pFfbPrivWin->fbc_base; - fbc = (fbc & ~FFB_FBC_WB_MASK) | FFB_FBC_WB_AB; - fbc = (fbc & ~FFB_FBC_XE_MASK) | FFB_FBC_XE_ON; - fbc = (fbc & ~FFB_FBC_RGBE_MASK) | FFB_FBC_RGBE_OFF; - - pBox = REGION_RECTS(prgn); - nBox = (int) REGION_NUM_RECTS(prgn); - FFB_WRITE_ROP(pFfb, ffb, (FFB_ROP_NEW | (FFB_ROP_NEW << 8))); - FFB_WRITE_PPC(pFfb, ffb, - (FFB_PPC_APE_DISABLE | FFB_PPC_CS_CONST | FFB_PPC_XS_WID), - (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK | FFB_PPC_XS_MASK)); - FFB_WRITE_PMASK(pFfb, ffb, ~0); - FFB_WRITE_DRAWOP(pFfb, ffb, FFB_DRAWOP_RECTANGLE); - FFB_WRITE_FBC(pFfb, ffb, fbc); - FFB_WRITE_WID(pFfb, ffb, FFB_WID_WIN(pWin)); - - while(nBox--) { - register int x, y, w, h; - - x = pBox->x1; - y = pBox->y1; - w = (pBox->x2 - x); - h = (pBox->y2 - y); - FFBFifo(pFfb, 4); - FFB_WRITE64(&ffb->by, y, x); - FFB_WRITE64_2(&ffb->bh, h, w); - pBox++; - } - pFfb->rp_active = 1; - FFBSync(pFfb, ffb); -} - -static void -FFBDRIMoveBuffers(WindowPtr pParent, DDXPointRec ptOldOrg, - RegionPtr prgnSrc, CARD32 index) -{ -} - -static void -FFBDRISetDrawableIndex(WindowPtr pWin, CARD32 index) -{ - ScreenPtr pScreen = pWin->drawable.pScreen; - FFBPtr pFfb = GET_FFB_FROM_SCREEN(pScreen); - CreatorPrivWinPtr pFfbPrivWin = CreatorGetWindowPrivate(pWin); - unsigned int wid; - - if (FFBWidIsShared(pFfb, pFfbPrivWin->wid)) { - wid = FFBWidUnshare(pFfb, pFfbPrivWin->wid); - if (wid == (unsigned int) -1) - return; - - ErrorF("FFB: Allocated WID %x for DRI window.\n", wid); - pFfbPrivWin->wid = wid; - - /* Now update the SAREA. */ - pFfb->pFfbSarea->wid_table[index] = wid; - } -} diff --git a/src/ffb_drishare.h b/src/ffb_drishare.h deleted file mode 100644 index d4f4a08..0000000 --- a/src/ffb_drishare.h +++ /dev/null @@ -1,48 +0,0 @@ -/* $XFree86$ */ - -#ifndef _FFB_DRISHARE_H -#define _FFB_DRISHARE_H - -typedef struct ffb_dri_state { - int flags; -#define FFB_DRI_FFB2 0x00000001 -#define FFB_DRI_FFB2PLUS 0x00000002 -#define FFB_DRI_PAC1 0x00000004 -#define FFB_DRI_PAC2 0x00000008 - - /* Indexed by DRI drawable id. */ -#define FFB_DRI_NWIDS 64 - unsigned int wid_table[FFB_DRI_NWIDS]; -} ffb_dri_state_t; - -#define FFB_DRISHARE(SAREA) \ - ((ffb_dri_state_t *) (((char *)(SAREA)) + sizeof(drm_sarea_t))) - -typedef struct { - drm_handle_t hFbcRegs; - drmSize sFbcRegs; - - drm_handle_t hDacRegs; - drmSize sDacRegs; - - drm_handle_t hSfb8r; - drmSize sSfb8r; - - drm_handle_t hSfb32; - drmSize sSfb32; - - drm_handle_t hSfb64; - drmSize sSfb64; - - /* Fastfill/Pagefill parameters. */ - unsigned char disable_pagefill; - int fastfill_small_area; - int pagefill_small_area; - int fastfill_height; - int fastfill_width; - int pagefill_height; - int pagefill_width; - short Pf_AlignTab[0x800]; -} FFBDRIRec, *FFBDRIPtr; - -#endif /* !(_FFB_DRISHARE_H) */ diff --git a/src/ffb_driver.c b/src/ffb_driver.c index a720612..5e329e8 100644 --- a/src/ffb_driver.c +++ b/src/ffb_driver.c @@ -432,22 +432,6 @@ FFBPreInit(ScrnInfoPtr pScrn, int flags) return FALSE; } -#if 0 -/*#ifdef XF86DRI*/ -/* - * Loading this automatically isn't compatible - * to the behavior of other drivers - */ - if (xf86LoadSubModule(pScrn, "drm") == NULL) { - FFBFreeRec(pScrn); - return FALSE; - } - - if (xf86LoadSubModule(pScrn, "dri") == NULL) { - FFBFreeRec(pScrn); - return FALSE; - } -#endif /********************* set up clock and mode stuff @@ -740,21 +724,6 @@ FFBScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) if (!miSetPixmapDepths()) return FALSE; -#if 0 /*def XF86DRI*/ - if (pFfb->ffb_type != afb_m3 && pFfb->ffb_type != afb_m6 && - pFfb->NoAccel == FALSE) { - pFfb->dri_enabled = FFBDRIScreenInit(pScreen); - if (pFfb->dri_enabled == TRUE) - xf86Msg(X_INFO, "%s: DRM initialized\n", - pFfb->psdp->device); - else - xf86Msg(X_INFO, "%s: DRM setup failed\n", - pFfb->psdp->device); - } else { - pFfb->dri_enabled = FALSE; - } -#endif - /* * Call the framebuffer layer's ScreenInit function, and fill in other * pScreen fields. @@ -832,21 +801,6 @@ FFBScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) if (!pFfb->NoAccel) FFB_InitDGA(pScreen); -#if 0 /*def XF86DRI*/ - if (pFfb->dri_enabled) { - /* Now that mi, fb, drm and others have done their thing, - * complete the DRI setup. - */ - pFfb->dri_enabled = FFBDRIFinishScreenInit(pScreen); - if (pFfb->dri_enabled) - xf86Msg(X_INFO, "%s: DRM finish setup complete\n", - pFfb->psdp->device); - else - xf86Msg(X_INFO, "%s: DRM finish setup failed\n", - pFfb->psdp->device); - } -#endif - xf86DPMSInit(pScreen, FFBDPMSSet, 0); pFfb->CloseScreen = pScreen->CloseScreen; @@ -948,11 +902,6 @@ FFBCloseScreen(int scrnIndex, ScreenPtr pScreen) ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; FFBPtr pFfb = GET_FFB_FROM_SCRN(pScrn); -#if 0 /*def XF86DRI*/ - if (pFfb->dri_enabled) - FFBDRICloseScreen(pScreen); -#endif - /* Restore kernel ramdac state before we unmap registers. */ FFBDacFini(pFfb); @@ -1010,7 +959,9 @@ FFBSaveScreen(ScreenPtr pScreen, int mode) done in "ffb_dac.c" `for aesthetic reasons.' */ { - return FFBDacSaveScreen(GET_FFB_FROM_SCREEN(pScreen), mode); + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + + return FFBDacSaveScreen(GET_FFB_FROM_SCRN(pScrn), mode); } static void diff --git a/src/ffb_rcache.h b/src/ffb_rcache.h index a9bac9b..f8c17b9 100644 --- a/src/ffb_rcache.h +++ b/src/ffb_rcache.h @@ -147,57 +147,8 @@ extern void __FFB_Attr_Raw(FFBPtr pFfb, #define FFB_PPC_GCMASK (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK) -/* This is for loading the FFB attributes for the case where - * where most of the values come directly from the graphics - * context and only the PPC and DRAWOP are variable. - */ -extern void __FFB_Attr_GC(FFBPtr pFfb, GCPtr pGC, WindowPtr pWin, - unsigned int ppc, int drawop); - -#define FFB_ATTR_GC(__fpriv, __pgc, __pwin, __ppc, __drawop) \ -do { CreatorPrivWinPtr __winpriv = CreatorGetWindowPrivate(__pwin); \ - unsigned int __rop = ((__pgc)->alu | FFB_ROP_EDIT_BIT); \ - unsigned int __fbc = ((__winpriv)->fbc_base); \ - __fbc &= ~FFB_FBC_XE_MASK; \ - __fbc |= FFB_FBC_XE_OFF; \ - __rop |= (FFB_ROP_NEW << 8); \ - if ((((__fpriv)->ppc_cache & FFB_PPC_GCMASK) != (__ppc))|| \ - ((__fpriv)->pmask_cache != ((__pgc)->planemask)) || \ - ((__fpriv)->rop_cache != (__rop)) || \ - ((__fpriv)->drawop_cache != (__drawop)) || \ - ((__fpriv)->fg_cache != ((__pgc)->fgPixel)) || \ - ((__fpriv)->fbc_cache != __fbc)) \ - __FFB_Attr_GC(__fpriv, __pgc, __pwin, __ppc, __drawop); \ -} while(0) - #define FFB_PPC_WINMASK (FFB_PPC_APE_MASK | FFB_PPC_CS_MASK | FFB_PPC_XS_MASK) -extern void __FFB_Attr_FastfillWin(FFBPtr pFfb, WindowPtr pWin, - unsigned int ppc, unsigned int pixel); - -#define FFB_ATTR_FFWIN(__fpriv, __pwin, __ppc, __pixel) \ -do { CreatorPrivWinPtr __winpriv = CreatorGetWindowPrivate(__pwin); \ - unsigned int ___ppc = (__ppc) | FFB_PPC_XS_WID; \ - unsigned int __fbc = (__winpriv)->fbc_base; \ - unsigned int __rop = (FFB_ROP_NEW|(FFB_ROP_NEW<<8)); \ - if((__fpriv)->has_double_buffer) { \ - __fbc &= ~FFB_FBC_WB_MASK; \ - __fbc |= FFB_FBC_WB_AB; \ - } \ - __fbc &= ~(FFB_FBC_XE_MASK | FFB_FBC_RGBE_MASK); \ - __fbc |= FFB_FBC_XE_ON | FFB_FBC_RGBE_ON; \ - if (pFfb->ffb_res == ffb_res_high) \ - __fbc |= FFB_FBC_WB_B; \ - if ((((__fpriv)->ppc_cache & FFB_PPC_WINMASK) != (___ppc))|| \ - ((__fpriv)->pmask_cache != 0x00ffffff) || \ - ((__fpriv)->rop_cache!= __rop) || \ - ((__fpriv)->drawop_cache != FFB_DRAWOP_FASTFILL) || \ - ((__fpriv)->fg_cache != (__pixel)) || \ - ((__fpriv)->fbc_cache != __fbc) || \ - ((__fpriv)->wid_cache != ((__winpriv)->wid))) \ - __FFB_Attr_FastfillWin(__fpriv, __pwin, ___ppc, __pixel);\ -} while (0) - /* We have to be careful when copying windows around. For that * case we will use either VIS copies or hw accelerated VSCROLL. * All of the planes needs to be copied in the framebuffer from @@ -327,7 +278,4 @@ do { unsigned int __rop = (FFB_ROP_OLD | (FFB_ROP_OLD << 8)); \ } \ } while(0) -#define FFB_FBC_WIN(pWin) CreatorGetWindowPrivate(pWin)->fbc_base -#define FFB_WID_WIN(pWin) CreatorGetWindowPrivate(pWin)->wid - #endif /* FFBRCACHE_H */ diff --git a/src/ffb_wid.c b/src/ffb_wid.c index 294a4f1..f9a13a8 100644 --- a/src/ffb_wid.c +++ b/src/ffb_wid.c @@ -449,20 +449,3 @@ FFBWidChangeBuffer(FFBPtr pFfb, unsigned int wid, int visible) update_wids(pFfb, index); } } - -/* Used by DRI part of driver. */ -Bool -FFBWidIsShared(FFBPtr pFfb, unsigned int wid) -{ - ffb_dac_info_t *p = &pFfb->dac_info; - ffb_wid_pool_t *table = &p->wid_table; - int index = wid >> table->wid_shift; - - if (index < 0 || index >= table->num_wids) - return TRUE; - - if (table->wid_pool[index].canshare == TRUE) - return TRUE; - - return FALSE; -} From moseley at hank.org Thu Dec 27 16:02:29 2007 From: moseley at hank.org (Bill Moseley) Date: Thu, 27 Dec 2007 16:02:29 -0800 Subject: Full screen only uses part of screen In-Reply-To: References: <20071226175647.GB7980@hank.org> Message-ID: <20071228000229.GA1855@hank.org> On Thu, Dec 27, 2007 at 11:31:12PM +0100, Matej Cepl wrote: > On 2007-12-26, 17:56 GMT, Bill Moseley wrote: > > When I run "full screen" games (e.g. Tux Typing, or Tux Math) > > only a small part of the inner screen is used. > > Does this https://bugzilla.redhat.com/show_bug.cgi?id=389501 look > familiar to you? No, it doesn't. Should it? I guess xscreensaver takes over the entire screen, too, but I'm not running Xinerama. Or are you saying that when moving into full-screen mode the xserver is reporting the incorrect geometry? I guess I don't follow the connection. -- Bill Moseley moseley at hank.org From davem at davemloft.net Thu Dec 27 16:08:59 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 16:08:59 -0800 (PST) Subject: [PATCH]: Fix sunleo driver build. Message-ID: <20071227.160859.209924860.davem@davemloft.net> More fallout from the recent devprivates rework. Please apply to the xf86-video-sunleo GIT tree, thanks! [SUNLEO]: Fix build after devprivates rework. The screen private isn't needed, neither is the window private, so remove those. Convert LEO's GC private over to the new devprivate APIs. Signed-off-by: David S. Miller diff --git a/src/leo.h b/src/leo.h index b3454a0..94dc103 100644 --- a/src/leo.h +++ b/src/leo.h @@ -84,23 +84,12 @@ typedef struct { OptionInfoPtr Options; } LeoRec, *LeoPtr; -extern int LeoScreenPrivateIndex; -extern int LeoGCPrivateIndex; -extern int LeoWindowPrivateIndex; +extern DevPrivateKey LeoGCPrivateKey; #define GET_LEO_FROM_SCRN(p) ((LeoPtr)((p)->driverPrivate)) -#define LeoGetScreenPrivate(s) \ -((LeoPtr) (s)->devPrivates[LeoScreenPrivateIndex].ptr) - #define LeoGetGCPrivate(g) \ -((LeoPrivGCPtr) (g)->devPrivates [LeoGCPrivateIndex].ptr) - -#define LeoGetWindowPrivate(w) \ -((LeoStipplePtr) (w)->devPrivates[LeoWindowPrivateIndex].ptr) - -#define LeoSetWindowPrivate(w,p) \ -((w)->devPrivates[LeoWindowPrivateIndex].ptr = (pointer) p) + ((LeoPrivGCPtr) dixLookupPrivate(&(g)->devPrivates, LeoGCPrivateKey)) extern int leoRopTable[]; diff --git a/src/leo_accel.c b/src/leo_accel.c index 149c6c8..20f58c0 100644 --- a/src/leo_accel.c +++ b/src/leo_accel.c @@ -42,9 +42,7 @@ #include "leo.h" -int LeoScreenPrivateIndex; -int LeoGCPrivateIndex; -int LeoWindowPrivateIndex; +DevPrivateKey LeoGCPrivateKey; int LeoGeneration; int leoRopTable[16] = { @@ -68,7 +66,8 @@ int leoRopTable[16] = { void LeoVtChange (ScreenPtr pScreen, int enter) { - LeoPtr pLeo = LeoGetScreenPrivate (pScreen); + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN (pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; @@ -100,19 +99,12 @@ Bool LeoAccelInit (ScreenPtr pScreen, LeoPtr pLeo) LeoDraw *ld0; if (serverGeneration != LeoGeneration) { - LeoScreenPrivateIndex = AllocateScreenPrivateIndex (); - if (LeoScreenPrivateIndex == -1) return FALSE; - LeoGCPrivateIndex = AllocateGCPrivateIndex (); - LeoWindowPrivateIndex = AllocateWindowPrivateIndex (); + if (!dixRequestPrivate(LeoGCPrivateKey, + sizeof(LeoPrivGCRec))) + return FALSE; LeoGeneration = serverGeneration; } - /* Allocate private structures holding pointer to both videoRAM and control registers. - We do not have to map these by ourselves, because the XServer did it for us; we - only copy the pointers to out structures. */ - if (!AllocateGCPrivate(pScreen, LeoGCPrivateIndex, sizeof(LeoPrivGCRec))) return FALSE; - if (!AllocateWindowPrivate(pScreen, LeoWindowPrivateIndex, 0)) return FALSE; - pScreen->devPrivates[LeoScreenPrivateIndex].ptr = pLeo; pLeo->lc0 = lc0 = (LeoCommand0 *) ((char *)pLeo->fb + LEO_LC0_VOFF); pLeo->ld0 = ld0 = (LeoDraw *) ((char *)pLeo->fb + LEO_LD0_VOFF); diff --git a/src/leo_checks.c b/src/leo_checks.c index 27e80a8..e2565b2 100644 --- a/src/leo_checks.c +++ b/src/leo_checks.c @@ -129,7 +129,9 @@ int LeoCheckFill (GCPtr pGC, DrawablePtr pDrawable) { LeoPrivGCPtr gcPriv = LeoGetGCPrivate (pGC); - LeoPtr pLeo = LeoGetScreenPrivate(pDrawable->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoStipplePtr stipple; unsigned int alu; int xrot, yrot; diff --git a/src/leo_frect.c b/src/leo_frect.c index e3a65fb..dc5a17a 100644 --- a/src/leo_frect.c +++ b/src/leo_frect.c @@ -39,7 +39,9 @@ void LeoPolyFillRect(DrawablePtr pDrawable, GCPtr pGC, int nrectFill, xRectangle *prectInit) { - LeoPtr pLeo = LeoGetScreenPrivate (pDrawable->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; xRectangle *prect; @@ -166,7 +168,9 @@ LeoPolyFillRect(DrawablePtr pDrawable, GCPtr pGC, int nrectFill, xRectangle *pre void LeoPolyFillRect1Rect(DrawablePtr pDrawable, GCPtr pGC, int nrectFill, xRectangle *prectInit) { - LeoPtr pLeo = LeoGetScreenPrivate (pDrawable->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; xRectangle *prect; diff --git a/src/leo_frectsp.c b/src/leo_frectsp.c index c860a26..f0e55c4 100644 --- a/src/leo_frectsp.c +++ b/src/leo_frectsp.c @@ -39,7 +39,9 @@ void LeoPolyFillStippledRect(DrawablePtr pDrawable, GCPtr pGC, int nrectFill, xRectangle *prectInit) { - LeoPtr pLeo = LeoGetScreenPrivate (pDrawable->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoPrivGCPtr gcPriv = LeoGetGCPrivate (pGC); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; diff --git a/src/leo_fspans.c b/src/leo_fspans.c index ad375d9..ccc9132 100644 --- a/src/leo_fspans.c +++ b/src/leo_fspans.c @@ -42,7 +42,9 @@ LeoFillSpansSolid (DrawablePtr pDrawable, GCPtr pGC, int n, DDXPointPtr ppt, int *pwidth, int fSorted) { - LeoPtr pLeo = LeoGetScreenPrivate (pGC->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; int numRects, *pwidthFree; diff --git a/src/leo_fspanssp.c b/src/leo_fspanssp.c index 26d27e4..4124337 100644 --- a/src/leo_fspanssp.c +++ b/src/leo_fspanssp.c @@ -43,7 +43,9 @@ LeoFillSpansStippled (DrawablePtr pDrawable, GCPtr pGC, int *pwidth, int fSorted) { LeoPrivGCPtr gcPriv = LeoGetGCPrivate (pGC); - LeoPtr pLeo = LeoGetScreenPrivate (pGC->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; int numRects, *pwidthFree; diff --git a/src/leo_glyph.c b/src/leo_glyph.c index 9399325..21a42d0 100644 --- a/src/leo_glyph.c +++ b/src/leo_glyph.c @@ -42,7 +42,9 @@ void LeoPolyGlyphBlt (DrawablePtr pDrawable, GCPtr pGC, int x, int y, unsigned int nglyph, CharInfoPtr *ppci, pointer pGlyphBase) { - LeoPtr pLeo = LeoGetScreenPrivate (pGC->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; RegionPtr clip; @@ -167,7 +169,9 @@ void LeoTEGlyphBlt (DrawablePtr pDrawable, GCPtr pGC, int x, int y, unsigned int nglyph, CharInfoPtr *ppci, pointer pGlyphBase) { - LeoPtr pLeo = LeoGetScreenPrivate (pGC->pScreen); + ScreenPtr pScreen = pDrawable->pScreen; + ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum]; + LeoPtr pLeo = GET_LEO_FROM_SCRN(pScrn); LeoCommand0 *lc0 = pLeo->lc0; LeoDraw *ld0 = pLeo->ld0; RegionPtr clip; From davem at davemloft.net Thu Dec 27 16:36:27 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 16:36:27 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227223534.D20387@artificial-stupidity.net> References: <1198744545.4976.4.camel@skapc.parateam.prv> <20071227.004300.218132079.davem@davemloft.net> <20071227223534.D20387@artificial-stupidity.net> Message-ID: <20071227.163627.195037633.davem@davemloft.net> From: Jaymz Julian Date: Thu, 27 Dec 2007 22:35:34 +1100 > It's not random (it rotates the result in a specific way), but that's not the > point - you can easily check for this bevaviour by doing something like: > > (warning: written into email client :-p. Bonus points if you modify > it to check endian at the same time) Actually we can't implement this as a run-time check, I just tried. The problem is that we can't handle cross-compilation cases properly. Having a default for things that enable or disable features because of a lack of a run-time check during cross-compilation is one thing, but having to make a choice which might result in emitting incorrect code is not OK. One could argue that we could add the cpu-type check in the cross-compilation case, but if we need the hard-coded cpu list for correctness in all cases anyways, there is no point to the run-time check at all. Therefore, I think the original patch is the way to go, explicitly adding cases per cpu type to xserver/configure.ac Could someone please therefore check my patch in? Here it is again for reference. Thanks! [GL]: Add GLX compile flags lost in modular X server changes. RISC chips that trap on unaligned loads and stores need to define __GLX_ALIGN64. This used to get added to the cflags in the old *.cf files but it no longer does in the modular X server. Also, Alpha needs to pass -mieee to the compiler as well. This is a simple backport of a patch that debian, and probably other distributions, have been applying forever. To the best of my knowledge the patch was written by Jurij Smakov. See debian bug number #388125. I just checked and this has been rotting for more than a year in freedesktop bugzilla as #8392. Signed-off-by: David S. Miller --- GL/glx/Makefile.am | 3 ++- configure.ac | 10 ++++++++++ hw/dmx/glxProxy/Makefile.am | 1 + 3 files changed, 13 insertions(+), 1 deletions(-) diff --git a/GL/glx/Makefile.am b/GL/glx/Makefile.am index 8eda153..4cf56e8 100644 --- a/GL/glx/Makefile.am +++ b/GL/glx/Makefile.am @@ -14,7 +14,8 @@ AM_CFLAGS = \ -I at MESA_SOURCE@/src/mesa/glapi \ -I at MESA_SOURCE@/src/mesa/main \ -DXFree86Server \ - @GLX_DEFINES@ + @GLX_DEFINES@ \ + @GLX_ARCH_DEFINES@ # none yet #sdk_HEADERS = diff --git a/configure.ac b/configure.ac index 0b718c9..0742040 100644 --- a/configure.ac +++ b/configure.ac @@ -304,6 +304,7 @@ case $host_cpu in *freebsd*) SYS_LIBS=-lio ;; *netbsd*) AC_DEFINE(USE_ALPHA_PIO, 1, [NetBSD PIO alpha IO]) ;; esac + GLX_ARCH_DEFINES="-D__GLX_ALIGN64 -mieee" ;; arm*) ARM_VIDEO=yes @@ -333,6 +334,7 @@ case $host_cpu in xorg_loader_sparcmuldiv="yes" SPARC64_VIDEO=yes BSD_ARCH_SOURCES="sparc64_video.c ioperm_noop.c" + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" ;; x86_64*|amd64*) use_x86_asm="yes" @@ -347,8 +349,16 @@ case $host_cpu in SYS_LIBS=-lamd64 ;; esac + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" + ;; + ia64*) + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" + ;; + s390*) + GLX_ARCH_DEFINES="-D__GLX_ALIGN64" ;; esac +AC_SUBST(GLX_ARCH_DEFINES) dnl BSD *_video.c selection AM_CONDITIONAL(ALPHA_VIDEO, [test "x$ALPHA_VIDEO" = xyes]) diff --git a/hw/dmx/glxProxy/Makefile.am b/hw/dmx/glxProxy/Makefile.am index 1fbc8d7..f995498 100644 --- a/hw/dmx/glxProxy/Makefile.am +++ b/hw/dmx/glxProxy/Makefile.am @@ -32,6 +32,7 @@ libglxproxy_a_SOURCES = compsize.c \ unpack.h AM_CFLAGS = \ + @GLX_ARCH_DEFINES@ \ $(DIX_CFLAGS) \ -I$(top_srcdir)/hw/dmx \ -I$(top_srcdir)/include \ From davem at davemloft.net Thu Dec 27 16:37:22 2007 From: davem at davemloft.net (David Miller) Date: Thu, 27 Dec 2007 16:37:22 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227223534.D20387@artificial-stupidity.net> References: <1198744545.4976.4.camel@skapc.parateam.prv> <20071227.004300.218132079.davem@davemloft.net> <20071227223534.D20387@artificial-stupidity.net> Message-ID: <20071227.163722.22965792.davem@davemloft.net> From: Jaymz Julian Date: Thu, 27 Dec 2007 22:35:34 +1100 > int main() > { > char foop[5]; > int *fleep=(int *)(foop+1) > int j; > foop[0]=0; > fleep=0x12345678; > j=*(int *)foop; > return (j==0x00123456 || j==0x00785634); > } FWIW, the one I came up with was: int main(void) { union { unsigned int val; unsigned char val_bytes[4]; } endian_test; unsigned short *p; unsigned int test_val; int big_endian = 0; endian_test.val = 0x01020304; if (endian_test.val_bytes[0] == 0x01) big_endian = 1; p = (unsigned short *) &endian_test.val_bytes[1]; *p = 0x0506; if (big_endian) test_val = 0x01050604; else test_val = 0x01060504; if (endian_test.val != test_val) return 1; return 0; } From pcpa at mandriva.com.br Thu Dec 27 18:31:51 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Fri, 28 Dec 2007 00:31:51 -0200 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227.140433.198915809.davem@davemloft.net> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> Message-ID: <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> Quoting David Miller : > From: Daniel Stone > Date: Thu, 27 Dec 2007 09:56:43 +0000 > >> On Thu, Dec 27, 2007 at 12:34:16AM -0800, David Miller wrote: >> > As another example, half the input drivers in the tree don't even >> > build, and it's been like this for over two years. There has been >> > some level of forward progress, but the regression is still mostly >> > there. >> >> http://bugs.freedesktop.org/show_bug.cgi?id=10262 which has been >> RESOLVED/FIXED since August? > > Look at how it's like pulling teeth to get someone to fix build > regressions they added, even downloading the drivers to do a test > build seems to be considered a chore. > > Also note how many times that bug had to get closed and reopenned > before it really was fixed. Finally, some of the input drivers > currently don't build: > > xf86-input-elographics: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/opt/XORG/include/xorg > -I/opt/XORG/include/pixman-1 -I/opt/XORG/include -I../src -MT > xf86Elo.lo -MD -MP -MF .deps/xf86Elo.Tpo -c xf86Elo.c -fPIC -DPIC -o > .libs/xf86Elo.o > xf86Elo.c:68:24: error: xf86_ansic.h: No such file or directory > make[2]: *** [xf86Elo.lo] Error 1 > > xf86-input-magictouch: > > clude/pixman-1 -I/opt/XORG/include -I../src -MT xf86MagicTouch.lo -MD > -MP -MF .deps/xf86MagicTouch.Tpo -c xf86MagicTouch.c -fPIC -DPIC -o > .libs/xf86MagicTouch.o > xf86MagicTouch.c:25:24: error: xf86_ansic.h: No such file or directory > xf86MagicTouch.c: In function 'xf86MagicAllocate': > xf86MagicTouch.c:1019: warning: assignment makes pointer from integer > without a cast > make[2]: *** [xf86MagicTouch.lo] Error 1 > >> I'm not holding this up as an example of brilliant development, >> but it's not a two-year regression, however you paint it. > > Sure, it was a one-year regression. > > But a known build regression that lasts for a year, sucks. The xf86 libcwrapper support was removed around one month ago. Almost funny it was when I posted about it, talking that it should be fixed, as it was broken for quite some time, anyway, the only real use of the libcwrapper was for binary only drivers, where problems should be solved in the server, but binary only distributors usually use other methods to try to resolve incompatibilites betwen Linux distros. And binary only drivers that work on different operating systems, on the same arch and using GNU tools, is more of a dream... You can get the input modules to build if you checkout server-1.4-branch or tag xorg-server-1.4, and probably others. But you will get runtime crashes on like half them, due to unresolved symbols, and I believe those that don't have unresolved symbols aren't working properly, due to the X Input Hotplug rework. I have been away from Linux for quite some time, but I am working on trying to get a stable set of packages for Mandriva. Other problems that exist are things like the vga driver not working, this is something that should not have been broken literally for years. If you check the existing video modules, there are other problems, mainly due to not compiling with more verbose gcc warnings neither using any tools to check for things like unresolved symbols (I am using a perl script that parses the output of "objdmup -t -T -w --demangle" and cross references symbols and "simulates" loading of shared libraries), i.e. things like modules with missing symbols (function calls) that are actually macros, but the proper headers were not included, C files declaring "extern" functions that don't exist, etc. More than half of the git modules don't have a tag also, so it is impossible to checkout a specific "official" release. Currently I am tagging my own mirror of freedesktop, but I need to review these tags, as several of them probably don't match the released tarballs, and this isn't really an easy job (and I am doing it kind of like in a rush...), but I hope to post the proper git commits and suggested tag names soon or later (most have the format -). Enough ranting :-) Paulo From Alan.Coopersmith at Sun.COM Thu Dec 27 22:16:57 2007 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Thu, 27 Dec 2007 22:16:57 -0800 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> Message-ID: <477494D9.5020108@sun.com> pcpa at mandriva.com.br wrote: > If you check the > existing video modules, there are other problems, mainly due to not > compiling with more verbose gcc warnings neither using any tools to check > for things like unresolved symbols (I am using a perl script that parses > the output of "objdmup -t -T -w --demangle" and cross references symbols > and "simulates" loading of shared libraries), i.e. things like modules with > missing symbols (function calls) that are actually macros, but the proper > headers were not included, C files declaring "extern" functions that don't > exist, etc. I haven't had a chance to update our Solaris builds to 1.4 yet, but we're building 1.3 and all the drivers we ship (most, but not all, of the video & input drivers) with -z defs using a mapfile for the Xorg exported symbols generated at build time with nm. I did find a couple of unresolvable symbols that way, but they were all fixed before 1.4. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From irwin at beluga.phys.uvic.ca Thu Dec 27 22:50:47 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 27 Dec 2007 22:50:47 -0800 (PST) Subject: Intel 2.2.1 release planning In-Reply-To: <200712271101.44426.jbarnes@virtuousgeek.org> References: <200712131127.40293.jbarnes@virtuousgeek.org> <200712271101.44426.jbarnes@virtuousgeek.org> Message-ID: On 2007-12-27 11:01-0800 Jesse Barnes wrote: > On Wednesday, December 26, 2007 1:54 pm Alan W. Irwin wrote: >> Hmm. Just discovered that there still is a problem with switching to >> console and back. It was fine for a while (long enough to write the >> above), but then KDE became unreliable. In particular, kicker froze >> so the logout icon I have there quit working, I could not switch >> between desktops, etc. Eventually, I logged out of KDE another way >> (using the logout icon accessible from the right-click menu), but >> that didn't work cleanly so I had to do a lot of kills of KDE >> commands and also the startx command by hand afterwards. > > This is with the git driver? Its with your "Let PLLs settle longer" patch to the 2.2.0 version of i830_driver.c at https://bugs.freedesktop.org/show_bug.cgi?id=13196. If that patch does not correspond to the git version, I would be happy to use git directly to get i830_driver.c (but in that case I would need an exact recipe from you to obtain the git version since I am not that familiar with git). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Thu Dec 27 23:14:56 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 27 Dec 2007 23:14:56 -0800 (PST) Subject: G35/33 X3500/3100 HDMI In-Reply-To: <3cfcba890712271537u56e55ae2tfd4b22b091cf0d11@mail.gmail.com> References: <3cfcba890712271537u56e55ae2tfd4b22b091cf0d11@mail.gmail.com> Message-ID: [reordered chronologically] > On Sunday, December 02, 2007 3:03 Alan W. Irwin wrote: >> Aside from the one-week outage due to an introduced issue in the >> cutting-edge version of the driver, it has been working >> well. I run KDE 3.x (i.e., 2D desktop) with no problems, and also >> ppracer (a.k.a. tuxracer) and foobillard for 3D games. Here is the >> glxgears rating results as given by the offical >> http://www.free3d.org/ script > On 2007-12-27 17:37-0600 hanasaki jiji wrote: > Which version of xorg is being referenced? > The remarks above were for my ASUS P5K-V with g33 chipset and no ADD2 card on the Debian testing version of X. X also mostly runs fine with my hardware on a patched version (see latest patch at https://bugs.freedesktop.org/show_bug.cgi?id=13196) of the Debian unstable version of X. > I am looking at G35, G33 and G31 boards to run Debian etch and Ubuntu > 7.10 gutsy on > Are they supported? I don't know at all for G35 or G31 and not for sure for G33 since I have not tried X on Debian etch or Ubuntu 7.10 for my G33 hardware. If one or both of those distro versions have version 2:2.1.0-2 (or close to it) of the xserver-xorg-video-intel package (that version is the Debian testing version) you should at least be okay with G33. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From linux at arcoscom.com Fri Dec 28 00:48:43 2007 From: linux at arcoscom.com (ArcosCom Linux User) Date: Fri, 28 Dec 2007 09:48:43 +0100 (CET) Subject: Problems with two S3 video devices. Message-ID: <34974.10.1.1.10.1198831723.squirrel@www.arcoscom.com> Hi, I'm having problems in an old PC with 2 S3 video devices. Sorry for the long e-mail, but here is all the config files and log files output. The X's start fine, and gnome too. I have the 2 screens working fine, but when I launch some programs, the xserver restart without any type of screen message. I don't know what is the problem, because VNC extension works fine, screen0 runs fine at 800x600 and screen1 runs fine at 1024x768. The 2 video devices uses the same driver s3virge. The first is a PCI (the principal screen) and the second is an AGP device (the secondary screen). Could anyone help me in diagnose and solve this problem? Thanks!! ========================================================== lspci output: 00:08.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) (prog-if 00 [VGA]) Subsystem: S3 Inc. ViRGE/DX Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at d8000000 (32-bit, non-prefetchable) [size=64M] [virtual] Expansion ROM at 30120000 [disabled] [size=64K] 01:00.0 VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 02) (prog-if 00 [VGA]) Subsystem: S3 Inc. Trio3D/2X Flags: bus master, medium devsel, latency 32 Memory at d0000000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at 30000000 [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Capabilities: [80] AGP version 1.0 ================================================================= This is the xorg.conf file content: Section "ServerLayout" Identifier "Multihead layout" Screen 0 "Screen0" LeftOf "Screen1" Screen 1 "Screen1" 0 0 InputDevice "Keyboard0" "CoreKeyboard" Option "Xinerama" "off" Option "Clone" "on" EndSection Section "Module" Load "vnc" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "es" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName "Monitor 1024x768" HorizSync 31.5 - 80.0 VertRefresh 30.0 - 100.0 Option "dpms" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor 1024x768" HorizSync 31.5 - 80.0 VertRefresh 30.0 - 100.0 Option "dpms" EndSection Section "Device" Identifier "Videocard0" Driver "s3virge" VendorName "Videocard Vendor" BoardName "S3 Inc. ViRGE/DX or /GX" BusID "PCI:0:8:0" Option "pci_burst" "on" Option "pci_retry" "on" EndSection Section "Device" Identifier "Videocard1" Driver "s3virge" VendorName "Videocard Vendor" BoardName "S3 Inc. 86c368 [Trio 3D/2X]" BusID "PCI:1:0:0" Option "pci_burst" "on" Option "pci_retry" "on" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Viewport 0 0 Depth 8 Modes "1024x768" "800x600" EndSubSection Option "UserPasswdVerifier" "VncAuth" Option "PasswordFile" "/root/.vnc/passwd" Option "httpd" "/usr/share/vnc/classes/" Option "ClientWaitTimeMillis" "300000" Option "deferUpdate" "100" Option "DisconnectClients" "off" Option "AllwaysShared" "on" Option "IdleTimeout" "300" Option "desktop" "screen0" EndSection Section "Screen" Identifier "Screen1" Device "Videocard1" Monitor "Monitor1" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Viewport 0 0 Depth 16 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Viewport 0 0 Depth 8 Modes "1024x768" "800x600" EndSubSection Option "UserPasswdVerifier" "VncAuth" Option "PasswordFile" "/root/.vnc/passwd" Option "httpd" "/usr/share/vnc/classes/" Option "ClientWaitTimeMillis" "300000" Option "deferUpdate" "100" Option "DisconnectClients" "off" Option "AllwaysShared" "on" Option "IdleTimeout" "300" Option "desktop" "screen1" EndSection ============================================================= This is the Xorg.0.log.old output: X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Linux 2.6.9-42.0.3.ELsmp i686 Red Hat, Inc. Current Operating System: Linux acpc08.arcoscom 2.6.18-53.1.4.1.el5_ArcosCom #1 SMP Wed Dec 5 08:29:14 CET 2007 i686 Build Date: 10 November 2007 Build ID: xorg-x11-server 1.1.1-48.26.el5 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Thu Dec 27 09:56:31 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Multihead layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Screen "Screen1" (1) (**) | |-->Monitor "Monitor1" (**) | |-->Device "Videocard1" (**) |-->Input Device "Keyboard0" (==) |-->Input Device "" (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. (==) No FontPath specified. Using compiled-in default. (==) FontPath set to: unix/:7100, built-ins (==) RgbPath set to "/usr/share/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (**) Option "Xinerama" "off" (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,0691 card 0000,0000 rev c4 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,8598 card 0000,0000 rev 00 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 1106,0686 card 1106,0000 rev 40 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 1106,0571 card 0000,0000 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00 (II) PCI: 00:07:4: chip 1106,3057 card 0000,0000 rev 40 class 06,00,00 hdr 00 (II) PCI: 00:08:0: chip 5333,8a01 card 5333,8a01 rev 01 class 03,00,00 hdr 00 (II) PCI: 00:09:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:0a:0: chip 10b7,9055 card 10b7,9055 rev 24 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 5333,8a13 card 5333,8a13 rev 02 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0x30000000 - 0x300fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:7:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(0:8:0) S3 Inc. ViRGE/DX or /GX rev 1, Mem @ 0xd8000000/26 (--) PCI: (1:0:0) S3 Inc. 86c368 [Trio 3D/2X] rev 2, Mem @ 0xd0000000/26 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xdd000000 from 0xdd7fffff to 0xdcffffff (II) Active PCI resource ranges: [0] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [1] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [2] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [3] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [4] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [5] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [6] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [7] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] (II) Inactive PCI resource ranges: [0] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [1] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [2] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [3] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [4] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [5] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [6] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [7] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] (II) Inactive PCI resource ranges after removing overlaps: [0] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] (II) LoadModule: "vnc" (II) Loading /usr/lib/xorg/modules/extensions/libvnc.so (II) Module vnc: vendor="RealVNC Ltd" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension VNC (II) LoadModule: "s3virge" (II) Loading /usr/lib/xorg/modules/drivers/s3virge_drv.so (II) Module s3virge: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.9.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.0 (II) LoadModule: "kbd" (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.6 (II) LoadModule: "mouse" (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.6 (II) S3VIRGE: driver (version 1.9.1) for S3 ViRGE chipsets: virge, 86C325, virge vx, 86C988, virge dx, virge gx, 86C375, 86C385, virge gx2, 86C357, virge mx, 86C260, virge mx+, 86C280, trio 3d, 86C365, trio 3d/2x, 86C362, 86C368 (II) Primary Device is: PCI 00:08:0 (--) Chipset virge dx found (--) Chipset trio 3d/2x found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) [8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [11] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B] [12] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [13] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [17] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [18] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [19] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [20] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] [21] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [22] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] [23] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B] [24] 1 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Setting vga for screen 1. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules/libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 7.1.1, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.0 (**) S3VIRGE(0): Depth 24, (--) framebuffer bpp 24 (==) S3VIRGE(0): RGB weight 888 (==) S3VIRGE(0): Default visual is TrueColor (**) S3VIRGE(0): Option "pci_burst" "on" (**) S3VIRGE(0): Option "pci_retry" "on" (**) S3VIRGE(0): Option: pci_burst - PCI burst read enabled (**) S3VIRGE(0): Option: pci_retry (==) S3VIRGE(0): Using HW Cursor (==) S3VIRGE(0): Using fb. (==) S3VIRGE(0): mx_cr3a_fix. (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/lib/xorg/modules/libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 ABI class: X.Org Video Driver, version 1.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules/libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) S3VIRGE(0): initializing int10 (II) S3VIRGE(0): Primary V_BIOS segment is: 0xc000 (II) S3VIRGE(0): VESA BIOS detected (II) S3VIRGE(0): VESA VBE Version 1.2 (II) S3VIRGE(0): VESA VBE Total Mem: 2048 kB (II) S3VIRGE(0): VESA VBE OEM: S3 Incorporated. 86C375/86C385 (--) S3VIRGE(0): Chipset: "virge dx" (==) S3VIRGE(0): XVideo supported. (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/lib/xorg/modules/libddc.so (II) Module ddc: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (--) S3VIRGE(0): No DDC signal (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Loading /usr/lib/xorg/modules/libi2c.so (II) Module i2c: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.0 (II) S3VIRGE(0): I2C bus "I2C bus" initialized. (II) S3VIRGE(0): I2C device "I2C bus:ddc2" registered at address 0xA0. (II) S3VIRGE(0): I2C device "I2C bus:ddc2" removed. (==) S3VIRGE(0): Using gamma correction (1.0, 1.0, 1.0) (--) S3VIRGE(0): videoram: 2048k (--) S3VIRGE(0): Detected current MCLK value of 45.102 MHz (II) S3VIRGE(0): Monitor0: Using hsync range of 31.50-80.00 kHz (II) S3VIRGE(0): Monitor0: Using vrefresh range of 30.00-100.00 Hz (II) S3VIRGE(0): Clock range: 10.00 to 270.00 MHz (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x960" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x960" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "640x480" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "640x512" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1792x1344" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "896x672" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1792x1344" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "896x672" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1856x1392" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "928x696" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1856x1392" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "928x696" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1152x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "576x432" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1440x900" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1600x1024" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "840x525" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "840x525" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x540" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x540" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory for mode) (II) S3VIRGE(0): Not using mode "1024x768" (no mode of this name) (II) S3VIRGE(0): Not using default mode "960x600" (width too large for virtual size) (II) S3VIRGE(0): Not using default mode "832x624" (width too large for virtual size) (II) S3VIRGE(0): Not using default mode "960x540" (width too large for virtual size) (II) S3VIRGE(0): Not using default mode "960x540" (width too large for virtual size) (II) S3VIRGE(0): Not using default mode "840x525" (width too large for virtual size) (II) S3VIRGE(0): Not using default mode "840x525" (width too large for virtual size) (--) S3VIRGE(0): Virtual size is 800x600 (pitch 800) (**) S3VIRGE(0): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz (II) S3VIRGE(0): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (**) S3VIRGE(0): Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz (II) S3VIRGE(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (**) S3VIRGE(0): Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz (II) S3VIRGE(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (**) S3VIRGE(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) S3VIRGE(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) S3VIRGE(0): Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) S3VIRGE(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) S3VIRGE(0): Default mode "700x525": 72.5 MHz, 76.5 kHz, 70.1 Hz (D) (II) S3VIRGE(0): Modeline "700x525" 72.53 700 748 824 948 525 525 527 546 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) (II) S3VIRGE(0): Modeline "700x525" 75.50 700 732 828 980 525 525 527 550 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "700x525" 61.00 700 744 820 940 525 526 532 541 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "640x512" 67.50 640 648 720 844 512 512 514 533 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "640x512" 54.00 640 664 720 844 512 512 514 533 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "720x450": 53.2 MHz, 55.9 kHz, 59.9 Hz (D) (II) S3VIRGE(0): Modeline "720x450" 53.25 720 760 836 952 450 451 454 467 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz (II) S3VIRGE(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (**) S3VIRGE(0): Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz (II) S3VIRGE(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (**) S3VIRGE(0): Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz (II) S3VIRGE(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (**) S3VIRGE(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) S3VIRGE(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) S3VIRGE(0): Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "640x480" 54.00 640 688 744 900 480 480 482 500 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz (II) S3VIRGE(0): Modeline "720x400" 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (**) S3VIRGE(0): Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) S3VIRGE(0): Modeline "640x400" 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (**) S3VIRGE(0): Default mode "640x400": 61.7 MHz, 71.4 kHz, 85.0 Hz (D) (II) S3VIRGE(0): Modeline "640x400" 61.69 640 684 752 864 400 400 402 420 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x400": 53.6 MHz, 62.6 kHz, 75.1 Hz (D) (II) S3VIRGE(0): Modeline "640x400" 53.60 640 680 748 856 400 400 402 417 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x400": 49.4 MHz, 58.3 kHz, 70.1 Hz (D) (II) S3VIRGE(0): Modeline "640x400" 49.45 640 676 744 848 400 400 402 416 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x400": 41.7 MHz, 49.7 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "640x400" 41.73 640 672 740 840 400 400 402 414 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 60.75 576 608 672 784 432 432 434 455 doublescan +hsync -vsync (**) S3VIRGE(0): Default mode "576x432": 59.8 MHz, 77.1 kHz, 85.1 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 59.83 576 612 676 776 432 432 434 453 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 54.00 576 608 672 800 432 432 434 450 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "576x432": 52.5 MHz, 67.6 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 52.49 576 612 676 776 432 432 434 451 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "576x432": 48.4 MHz, 63.0 kHz, 70.0 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 48.38 576 612 672 768 432 432 434 450 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "576x432": 40.8 MHz, 53.7 kHz, 60.1 Hz (D) (II) S3VIRGE(0): Modeline "576x432" 40.81 576 608 668 760 432 432 434 447 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x384": 59.3 MHz, 68.6 kHz, 85.1 Hz (D) (II) S3VIRGE(0): Modeline "640x384" 59.27 640 684 752 864 384 384 386 403 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x384": 51.5 MHz, 60.2 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "640x384" 51.49 640 680 748 856 384 384 386 401 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x384": 47.5 MHz, 56.0 kHz, 70.0 Hz (D) (II) S3VIRGE(0): Modeline "640x384" 47.49 640 676 744 848 384 384 386 400 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x384": 40.1 MHz, 47.7 kHz, 60.1 Hz (D) (II) S3VIRGE(0): Modeline "640x384" 40.07 640 672 740 840 384 384 386 397 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x360": 55.0 MHz, 64.3 kHz, 85.0 Hz (D) (II) S3VIRGE(0): Modeline "640x360" 55.01 640 680 748 856 360 360 362 378 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x360": 47.8 MHz, 56.4 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "640x360" 47.83 640 676 744 848 360 360 362 376 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x360": 44.5 MHz, 52.5 kHz, 70.0 Hz (D) (II) S3VIRGE(0): Modeline "640x360" 44.52 640 676 744 848 360 360 362 375 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x360": 37.2 MHz, 44.8 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "640x360" 37.24 640 668 736 832 360 360 362 373 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) S3VIRGE(0): Modeline "640x350" 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (**) S3VIRGE(0): Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) (II) S3VIRGE(0): Modeline "576x384" 32.50 576 589 657 736 384 385 388 403 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) (II) S3VIRGE(0): Modeline "512x384" 47.25 512 536 584 688 384 384 386 404 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) (II) S3VIRGE(0): Modeline "512x384" 39.40 512 520 568 656 384 384 386 400 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) (II) S3VIRGE(0): Modeline "512x384" 37.50 512 524 592 664 384 385 388 403 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) (II) S3VIRGE(0): Modeline "512x384" 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "512x384": 22.4 MHz, 35.5 kHz, 86.6 Hz (D) (II) S3VIRGE(0): Modeline "512x384" 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) (II) S3VIRGE(0): Modeline "416x312" 28.64 416 432 464 576 312 312 314 333 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) (II) S3VIRGE(0): Modeline "400x300" 28.15 400 416 448 524 300 300 302 315 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) (II) S3VIRGE(0): Modeline "400x300" 24.75 400 408 448 528 300 300 302 312 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) (II) S3VIRGE(0): Modeline "400x300" 25.00 400 428 488 520 300 318 321 333 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) (II) S3VIRGE(0): Modeline "400x300" 20.00 400 420 484 528 300 300 302 314 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) (II) S3VIRGE(0): Modeline "400x300" 18.00 400 412 448 512 300 300 301 312 doublescan +hsync +vsync (**) S3VIRGE(0): Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) (II) S3VIRGE(0): Modeline "320x240" 18.00 320 348 376 416 240 240 242 254 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) (II) S3VIRGE(0): Modeline "320x240" 15.75 320 328 360 420 240 240 242 250 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) (II) S3VIRGE(0): Modeline "320x240" 15.75 320 332 352 416 240 244 245 260 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) (II) S3VIRGE(0): Modeline "320x240" 12.60 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (**) S3VIRGE(0): Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) (II) S3VIRGE(0): Modeline "360x200" 17.75 360 378 414 468 200 200 202 223 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) S3VIRGE(0): Modeline "320x200" 15.75 320 336 368 416 200 200 202 222 doublescan -hsync +vsync (**) S3VIRGE(0): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) S3VIRGE(0): Modeline "320x175" 15.75 320 336 368 416 175 191 192 222 doublescan +hsync -vsync (==) S3VIRGE(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules/libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/lib/xorg/modules/libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/lib/xorg/modules/libramdac.so (II) Module ramdac: vendor="X.Org Foundation" compiled for 7.1.1, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.0 (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Reloading /usr/lib/xorg/modules/libvgahw.so (II) S3VIRGE(1): Creating default Display subsection in Screen section "Screen1" for depth/fbbpp 24/24 (**) S3VIRGE(1): Depth 24, (--) framebuffer bpp 24 (==) S3VIRGE(1): RGB weight 888 (==) S3VIRGE(1): Default visual is TrueColor (**) S3VIRGE(1): Option "pci_burst" "on" (**) S3VIRGE(1): Option "pci_retry" "on" (**) S3VIRGE(1): Option: pci_burst - PCI burst read enabled (**) S3VIRGE(1): Option: pci_retry (==) S3VIRGE(1): Using HW Cursor (==) S3VIRGE(1): Using fb. (==) S3VIRGE(1): mx_cr3a_fix. (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Reloading /usr/lib/xorg/modules/libvbe.so (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) S3VIRGE(1): initializing int10 (II) Attempted to read BIOS 64KB from /sys/bus/pci/devices/0000:01:00.0/rom: got 32KB (II) S3VIRGE(1): VESA BIOS detected (II) S3VIRGE(1): VESA VBE Version 2.0 (II) S3VIRGE(1): VESA VBE Total Mem: 4096 kB (II) S3VIRGE(1): VESA VBE OEM: S3 Incorporated. 86C362 (II) S3VIRGE(1): VESA VBE OEM Software Rev: 1.1 (II) S3VIRGE(1): VESA VBE OEM Vendor: S3 Incorporated. (II) S3VIRGE(1): VESA VBE OEM Product: Trio3D/2X (II) S3VIRGE(1): VESA VBE OEM Product Rev: Rev C (--) S3VIRGE(1): Chipset: "trio 3d/2x" (==) S3VIRGE(1): XVideo supported. (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/lib/xorg/modules/libddc.so (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/lib/xorg/modules/libddc.so (II) S3VIRGE(1): VESA VBE DDC supported (II) S3VIRGE(1): VESA VBE DDC Level 2 (II) S3VIRGE(1): VESA VBE DDC transfer in appr. 1 sec. (II) S3VIRGE(1): VESA VBE DDC read successfully (II) S3VIRGE(1): Manufacturer: TAT Model: 31d7 Serial#: 630247 (II) S3VIRGE(1): Year: 2001 Week: 52 (II) S3VIRGE(1): EDID Version: 1.3 (II) S3VIRGE(1): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) S3VIRGE(1): Sync: Separate (II) S3VIRGE(1): Max H-Image Size [cm]: horiz.: 32 vert.: 24 (II) S3VIRGE(1): Gamma: 2.77 (II) S3VIRGE(1): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) S3VIRGE(1): First detailed timing is preferred mode (II) S3VIRGE(1): redX: 0.630 redY: 0.340 greenX: 0.280 greenY: 0.601 (II) S3VIRGE(1): blueX: 0.145 blueY: 0.061 whiteX: 0.281 whiteY: 0.311 (II) S3VIRGE(1): Supported VESA Video Modes: (II) S3VIRGE(1): 720x400 at 70Hz (II) S3VIRGE(1): 640x480 at 60Hz (II) S3VIRGE(1): 640x480 at 75Hz (II) S3VIRGE(1): 800x600 at 60Hz (II) S3VIRGE(1): 800x600 at 75Hz (II) S3VIRGE(1): 1024x768 at 60Hz (II) S3VIRGE(1): 1024x768 at 70Hz (II) S3VIRGE(1): 1024x768 at 75Hz (II) S3VIRGE(1): Manufacturer's mask: 0 (II) S3VIRGE(1): Supported Future Video Modes: (II) S3VIRGE(1): #0: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) S3VIRGE(1): #1: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) S3VIRGE(1): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) S3VIRGE(1): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) S3VIRGE(1): Supported additional Video Mode: (II) S3VIRGE(1): clock: 94.5 MHz Image Size: 306 x 230 mm (II) S3VIRGE(1): h_active: 1024 h_sync: 1072 h_sync_end 1168 h_blank_end 1376 h_border: 0 (II) S3VIRGE(1): v_active: 768 v_sync: 769 v_sync_end 772 v_blanking: 808 v_border: 0 (II) S3VIRGE(1): Ranges: V min: 50 V max: 120 Hz, H min: 30 H max: 70 kHz, (II) S3VIRGE(1): Serial No: 80H152630247 (II) S3VIRGE(1): Monitor name: TATUNG C7ES (II) S3VIRGE(1): EDID (in hex): (II) S3VIRGE(1): 00ffffffffffff005034d731e79d0900 (II) S3VIRGE(1): 340b0103682018b1ea4f22a157479925 (II) S3VIRGE(1): 0f484fa54e0031594559615981800101 (II) S3VIRGE(1): 010101010101ea240060410028303060 (II) S3VIRGE(1): 130032e61000001e000000fd0032781e (II) S3VIRGE(1): 46ff000a202020202020000000ff0038 (II) S3VIRGE(1): 30483135323633303234370a000000fc (II) S3VIRGE(1): 00544154554e4720433745530a200007 (II) S3VIRGE(1): Using hsync ranges from config file (II) S3VIRGE(1): Using vrefresh ranges from config file (II) S3VIRGE(1): Printing DDC gathered Modelines: (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) S3VIRGE(1): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (II) S3VIRGE(1): Modeline "640x480" 35.00 640 664 728 816 480 483 487 507 -hsync +vsync (II) S3VIRGE(1): Modeline "800x600" 56.75 800 848 928 1056 600 603 607 633 -hsync +vsync (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1096 1200 1376 768 771 775 809 -hsync +vsync (II) S3VIRGE(1): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (==) S3VIRGE(1): Using gamma correction (1.0, 1.0, 1.0) (--) S3VIRGE(1): videoram: 4096k (--) S3VIRGE(1): Detected current MCLK value of 100.227 MHz (II) S3VIRGE(1): Monitor1: Using hsync range of 31.50-80.00 kHz (II) S3VIRGE(1): Monitor1: Using vrefresh range of 30.00-100.00 Hz (II) S3VIRGE(1): Estimated virtual size for aspect ratio 1.3333 is 1024x768 (II) S3VIRGE(1): Clock range: 10.00 to 270.00 MHz (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x960" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x960" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "640x480" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "640x512" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1792x1344" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "896x672" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1792x1344" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "896x672" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1856x1392" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "928x696" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1856x1392" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "928x696" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1152x768" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "576x432" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1440x900" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "1600x1024" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "840x525" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "840x525" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x540" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x540" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory for mode) (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for virtual size) (II) S3VIRGE(1): Not using driver mode "1280x1024" (width too large for virtual size) (--) S3VIRGE(1): Virtual size is 1024x768 (pitch 1024) (**) S3VIRGE(1): *Driver mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) S3VIRGE(1): *Driver mode "1024x768": 94.5 MHz, 68.7 kHz, 84.9 Hz (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1096 1200 1376 768 771 775 809 -hsync +vsync (**) S3VIRGE(1): *Driver mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (**) S3VIRGE(1): *Driver mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (**) S3VIRGE(1): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) S3VIRGE(1): *Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) S3VIRGE(1): *Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (**) S3VIRGE(1): *Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (**) S3VIRGE(1): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) S3VIRGE(1): *Default mode "1024x768": 44.9 MHz, 35.5 kHz, 86.9 Hz (I) (II) S3VIRGE(1): Modeline "1024x768" 44.90 1024 1032 1208 1264 768 768 776 817 interlace +hsync +vsync (**) S3VIRGE(1): *Default mode "960x600": 96.6 MHz, 74.5 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "960x600" 96.58 960 1024 1128 1296 600 600 602 621 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz (II) S3VIRGE(1): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (**) S3VIRGE(1): *Default mode "960x540": 102.1 MHz, 78.8 kHz, 70.0 Hz (D) (II) S3VIRGE(1): Modeline "960x540" 102.12 960 1028 1128 1296 540 541 544 563 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "960x540": 86.5 MHz, 67.2 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "960x540" 86.50 960 1024 1124 1288 540 541 544 560 doublescan -hsync +vsync (**) S3VIRGE(1): *Driver mode "800x600": 56.8 MHz, 53.7 kHz, 84.9 Hz (II) S3VIRGE(1): Modeline "800x600" 56.75 800 848 928 1056 600 603 607 633 -hsync +vsync (**) S3VIRGE(1): *Driver mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (**) S3VIRGE(1): *Driver mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz (II) S3VIRGE(1): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 631 +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz (II) S3VIRGE(1): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) S3VIRGE(1): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) S3VIRGE(1): *Default mode "840x525": 87.0 MHz, 76.6 kHz, 69.9 Hz (D) (II) S3VIRGE(1): Modeline "840x525" 87.00 840 900 988 1136 525 526 529 548 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "840x525": 73.1 MHz, 65.3 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "840x525" 73.12 840 892 980 1120 525 526 529 544 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "700x525": 72.5 MHz, 76.5 kHz, 70.1 Hz (D) (II) S3VIRGE(1): Modeline "700x525" 72.53 700 748 824 948 525 525 527 546 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) (II) S3VIRGE(1): Modeline "700x525" 75.50 700 732 828 980 525 525 527 550 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "700x525" 61.00 700 744 820 940 525 526 532 541 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "640x512" 67.50 640 648 720 844 512 512 514 533 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "640x512" 54.00 640 664 720 844 512 512 514 533 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "720x450": 53.2 MHz, 55.9 kHz, 59.9 Hz (D) (II) S3VIRGE(1): Modeline "720x450" 53.25 720 760 836 952 450 451 454 467 doublescan -hsync +vsync (**) S3VIRGE(1): *Driver mode "640x480": 35.0 MHz, 42.9 kHz, 84.6 Hz (II) S3VIRGE(1): Modeline "640x480" 35.00 640 664 728 816 480 483 487 507 -hsync +vsync (**) S3VIRGE(1): *Driver mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (**) S3VIRGE(1): *Driver mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) S3VIRGE(1): *Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz (II) S3VIRGE(1): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (**) S3VIRGE(1): *Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (**) S3VIRGE(1): *Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz (II) S3VIRGE(1): Modeline "640x480" 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (**) S3VIRGE(1): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) S3VIRGE(1): *Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "640x480" 54.00 640 688 744 900 480 480 482 500 doublescan +hsync +vsync (**) S3VIRGE(1): *Driver mode "720x400": 28.3 MHz, 31.5 kHz, 70.1 Hz (II) S3VIRGE(1): Modeline "720x400" 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (**) S3VIRGE(1): *Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz (II) S3VIRGE(1): Modeline "720x400" 35.50 720 756 828 936 400 401 404 446 -hsync +vsync (**) S3VIRGE(1): *Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) S3VIRGE(1): Modeline "640x400" 31.50 640 672 736 832 400 401 404 445 -hsync +vsync (**) S3VIRGE(1): *Default mode "640x400": 61.7 MHz, 71.4 kHz, 85.0 Hz (D) (II) S3VIRGE(1): Modeline "640x400" 61.69 640 684 752 864 400 400 402 420 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x400": 53.6 MHz, 62.6 kHz, 75.1 Hz (D) (II) S3VIRGE(1): Modeline "640x400" 53.60 640 680 748 856 400 400 402 417 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x400": 49.4 MHz, 58.3 kHz, 70.1 Hz (D) (II) S3VIRGE(1): Modeline "640x400" 49.45 640 676 744 848 400 400 402 416 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x400": 41.7 MHz, 49.7 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "640x400" 41.73 640 672 740 840 400 400 402 414 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 60.75 576 608 672 784 432 432 434 455 doublescan +hsync -vsync (**) S3VIRGE(1): *Default mode "576x432": 59.8 MHz, 77.1 kHz, 85.1 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 59.83 576 612 676 776 432 432 434 453 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 54.00 576 608 672 800 432 432 434 450 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "576x432": 52.5 MHz, 67.6 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 52.49 576 612 676 776 432 432 434 451 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "576x432": 48.4 MHz, 63.0 kHz, 70.0 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 48.38 576 612 672 768 432 432 434 450 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "576x432": 40.8 MHz, 53.7 kHz, 60.1 Hz (D) (II) S3VIRGE(1): Modeline "576x432" 40.81 576 608 668 760 432 432 434 447 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x384": 59.3 MHz, 68.6 kHz, 85.1 Hz (D) (II) S3VIRGE(1): Modeline "640x384" 59.27 640 684 752 864 384 384 386 403 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x384": 51.5 MHz, 60.2 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "640x384" 51.49 640 680 748 856 384 384 386 401 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x384": 47.5 MHz, 56.0 kHz, 70.0 Hz (D) (II) S3VIRGE(1): Modeline "640x384" 47.49 640 676 744 848 384 384 386 400 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x384": 40.1 MHz, 47.7 kHz, 60.1 Hz (D) (II) S3VIRGE(1): Modeline "640x384" 40.07 640 672 740 840 384 384 386 397 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x360": 55.0 MHz, 64.3 kHz, 85.0 Hz (D) (II) S3VIRGE(1): Modeline "640x360" 55.01 640 680 748 856 360 360 362 378 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x360": 47.8 MHz, 56.4 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "640x360" 47.83 640 676 744 848 360 360 362 376 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x360": 44.5 MHz, 52.5 kHz, 70.0 Hz (D) (II) S3VIRGE(1): Modeline "640x360" 44.52 640 676 744 848 360 360 362 375 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x360": 37.2 MHz, 44.8 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "640x360" 37.24 640 668 736 832 360 360 362 373 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz (II) S3VIRGE(1): Modeline "640x350" 31.50 640 672 736 832 350 382 385 445 +hsync -vsync (**) S3VIRGE(1): *Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) (II) S3VIRGE(1): Modeline "576x384" 32.50 576 589 657 736 384 385 388 403 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) (II) S3VIRGE(1): Modeline "512x384" 47.25 512 536 584 688 384 384 386 404 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) (II) S3VIRGE(1): Modeline "512x384" 39.40 512 520 568 656 384 384 386 400 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) (II) S3VIRGE(1): Modeline "512x384" 37.50 512 524 592 664 384 385 388 403 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) (II) S3VIRGE(1): Modeline "512x384" 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "512x384": 22.4 MHz, 35.5 kHz, 86.6 Hz (D) (II) S3VIRGE(1): Modeline "512x384" 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) (II) S3VIRGE(1): Modeline "416x312" 28.64 416 432 464 576 312 312 314 333 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) (II) S3VIRGE(1): Modeline "400x300" 28.15 400 416 448 524 300 300 302 315 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) (II) S3VIRGE(1): Modeline "400x300" 24.75 400 408 448 528 300 300 302 312 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) (II) S3VIRGE(1): Modeline "400x300" 25.00 400 428 488 520 300 318 321 333 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) (II) S3VIRGE(1): Modeline "400x300" 20.00 400 420 484 528 300 300 302 314 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) (II) S3VIRGE(1): Modeline "400x300" 18.00 400 412 448 512 300 300 301 312 doublescan +hsync +vsync (**) S3VIRGE(1): *Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) (II) S3VIRGE(1): Modeline "320x240" 18.00 320 348 376 416 240 240 242 254 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) (II) S3VIRGE(1): Modeline "320x240" 15.75 320 328 360 420 240 240 242 250 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) (II) S3VIRGE(1): Modeline "320x240" 15.75 320 332 352 416 240 244 245 260 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) (II) S3VIRGE(1): Modeline "320x240" 12.60 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (**) S3VIRGE(1): *Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) (II) S3VIRGE(1): Modeline "360x200" 17.75 360 378 414 468 200 200 202 223 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) S3VIRGE(1): Modeline "320x200" 15.75 320 336 368 416 200 200 202 222 doublescan -hsync +vsync (**) S3VIRGE(1): *Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) (II) S3VIRGE(1): Modeline "320x175" 15.75 320 336 368 416 175 191 192 222 doublescan +hsync -vsync (**) S3VIRGE(1): Display dimensions: (320, 240) mm (**) S3VIRGE(1): DPI set to (81, 81) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Reloading /usr/lib/xorg/modules/libfb.so (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Reloading /usr/lib/xorg/modules/libxaa.so (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Reloading /usr/lib/xorg/modules/libramdac.so (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? Yes, I do. (II) LoadModule: "rac" (II) Loading /usr/lib/xorg/modules/librac.so (II) Module rac: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) resource ranges after preInit: [0] 1 0 0xd0000000 - 0xd3ffffff (0x4000000) MS[B] [1] 0 0 0xd8000000 - 0xdbffffff (0x4000000) MS[B] [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [6] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] [7] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O [8] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) [9] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [13] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [14] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [15] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [18] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] [19] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] [20] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] [21] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] [22] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) [25] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [26] 1 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) S3VIRGE(0): Write-combining range (0xd8000000,0x200000) (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (**) S3VIRGE(0): Using FB (II) S3VIRGE(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles CPU to Screen color expansion Solid Horizontal and Vertical Lines Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 12 128x128 slots (==) S3VIRGE(0): Backing store disabled (==) S3VIRGE(0): Silken mouse enabled (**) Option "dpms" (**) S3VIRGE(0): DPMS enabled (II) S3VIRGE(0): Using overlay video (WW) S3VIRGE(0): Option "UserPasswdVerifier" is not used (WW) S3VIRGE(0): Option "PasswordFile" is not used (WW) S3VIRGE(0): Option "httpd" is not used (WW) S3VIRGE(0): Option "ClientWaitTimeMillis" is not used (WW) S3VIRGE(0): Option "deferUpdate" is not used (WW) S3VIRGE(0): Option "DisconnectClients" is not used (WW) S3VIRGE(0): Option "AllwaysShared" is not used (WW) S3VIRGE(0): Option "IdleTimeout" is not used (WW) S3VIRGE(0): Option "desktop" is not used (==) RandR enabled (==) S3VIRGE(1): Write-combining range (0xd0000000,0x400000) (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (**) S3VIRGE(1): Using FB (II) S3VIRGE(1): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Solid Horizontal and Vertical Lines Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 16 128x128 slots 4 256x256 slots (==) S3VIRGE(1): Backing store disabled (==) S3VIRGE(1): Silken mouse enabled (**) Option "dpms" (**) S3VIRGE(1): DPMS enabled (II) S3VIRGE(1): Using overlay video (WW) S3VIRGE(1): Option "UserPasswdVerifier" is not used (WW) S3VIRGE(1): Option "PasswordFile" is not used (WW) S3VIRGE(1): Option "httpd" is not used (WW) S3VIRGE(1): Option "ClientWaitTimeMillis" is not used (WW) S3VIRGE(1): Option "deferUpdate" is not used (WW) S3VIRGE(1): Option "DisconnectClients" is not used (WW) S3VIRGE(1): Option "AllwaysShared" is not used (WW) S3VIRGE(1): Option "IdleTimeout" is not used (WW) S3VIRGE(1): Option "desktop" is not used (==) RandR enabled (II) Entity 0 shares no resources (II) Entity 1 shares no resources (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (**) Option "CoreKeyboard" (**) Keyboard0: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "es" (**) Keyboard0: XkbLayout: "es" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/input/mice" (--) : Device: "/dev/input/mice" (==) : Protocol: "Auto" (**) Option "CorePointer" (**) : Core Pointer (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (II) XINPUT: Adding extended input device "" (type: MOUSE) (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (--) : PnP-detected protocol: "ExplorerPS/2" (II) : ps2EnableDataReporting: succeeded Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e3fe1] 1: [0x6ed420] 2: /usr/lib/xorg/modules/libxaa.so(XAARemoveAreaCallback+0x17) [0x8f1ae7] 3: /usr/lib/xorg/modules/libxaa.so [0x8d57bd] 4: /usr/bin/Xorg [0x8104b19] 5: /usr/bin/Xorg [0x815b577] 6: /usr/bin/Xorg [0x8156810] 7: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] 8: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] 9: /usr/bin/Xorg [0x815b6ff] 10: /usr/bin/Xorg [0x8156810] 11: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] 12: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] 13: /usr/bin/Xorg(ProcPolyFillRectangle+0xb6) [0x8084526] 14: /usr/bin/Xorg(Dispatch+0x19a) [0x808811a] 15: /usr/bin/Xorg(main+0x485) [0x806fa95] 16: /lib/libc.so.6(__libc_start_main+0xdc) [0xb50dec] 17: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e5) [0x806ed91] Fatal server error: Caught signal 11. Server aborting (II) Screen 0 shares mem & io resources (II) Screen 1 shares mem & io resources ================================================================= This is the /var/log/gdm/\:0.log.1: X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Linux 2.6.9-42.0.3.ELsmp i686 Red Hat, Inc. Current Operating System: Linux acpc08.arcoscom 2.6.18-53.1.4.1.el5_ArcosCom #1 SMP Wed Dec 5 08:29:14 CET 2007 i686 Build Date: 10 November 2007 Build ID: xorg-x11-server 1.1.1-48.26.el5 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Thu Dec 27 09:56:31 2007 (==) Using config file: "/etc/X11/xorg.conf" Thu Dec 27 09:56:36 2007 vncext: VNC extension running! vncext: Listening for VNC connections on port 5900 vncext: Listening for HTTP connections on port 5800 vncext: created VNC server for screen 0 vncext: Listening for VNC connections on port 6900 vncext: Listening for HTTP connections on port 6800 vncext: created VNC server for screen 1 Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e3fe1] 1: [0x6ed420] 2: /usr/lib/xorg/modules/libxaa.so(XAARemoveAreaCallback+0x17) [0x8f1ae7] 3: /usr/lib/xorg/modules/libxaa.so [0x8d57bd] 4: /usr/bin/Xorg [0x8104b19] 5: /usr/bin/Xorg [0x815b577] 6: /usr/bin/Xorg [0x8156810] 7: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] 8: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] 9: /usr/bin/Xorg [0x815b6ff] 10: /usr/bin/Xorg [0x8156810] 11: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] 12: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] 13: /usr/bin/Xorg(ProcPolyFillRectangle+0xb6) [0x8084526] 14: /usr/bin/Xorg(Dispatch+0x19a) [0x808811a] 15: /usr/bin/Xorg(main+0x485) [0x806fa95] 16: /lib/libc.so.6(__libc_start_main+0xdc) [0xb50dec] 17: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e5) [0x806ed91] Fatal server error: Caught signal 11. Server aborting From zhenyu.z.wang at intel.com Fri Dec 28 00:45:45 2007 From: zhenyu.z.wang at intel.com (Zhenyu Wang) Date: Fri, 28 Dec 2007 16:45:45 +0800 Subject: new 'xvmc' branch of intel video driver Message-ID: <20071228084545.GA21215@zhen-devel.sh.intel.com> The aim of the new 'xvmc' branch is to deprecate origin 'xvmc-i915' branch with lot of cleanups and new framework inside driver to add supports for more hardware media decode drivers in future. It also has changes that affect users. The most noteable is that the origin libI915XvMC.so is replaced by a single libIntelXvMC.so entry to be used on different chipsets for different hardware decoders. Although currently there's only one decoder for MPEG MC on 915/945/G33 series. So you should change lib path in your XvMCConfig file. New driver option "XvMC" and config option can be used to disable XvMC feature in the driver. It turns on by default. Welcome to test and send issues to me. Thanks. From macslow at bangang.de Fri Dec 28 01:24:14 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Fri, 28 Dec 2007 10:24:14 +0100 Subject: GLX_EXT_texture_from_pixmap working on GeForce 8800 but not on i965 In-Reply-To: <1198658253.12578.39.camel@HAL9000> References: <1198658253.12578.39.camel@HAL9000> Message-ID: <1198833854.2922.29.camel@HAL9000> Greetings again! I simplified the example by two thirds (~500 lines instead of ~1400) hoping that someone might take a look at it and possibly explain why this does not work on the i965 (not under compiz, not under metacity) and only on a GeForce (not under compiz, only under metacity). The i965 is running the 2.1.1 intel-driver shipping with Ubuntu 7.10 (64bit) under xserver 1.3.0. Both, under metacity and compiz, x11-tfp-test fails with a GLXBadPixmap-error for X_GLXVenderPrivateWithReply. The GeForce 8800 runs nvidia's binary driver 100.14.19 on Ubuntu 7.10 (32bit) under xserver 1.3.0. Under metacity the x11-tfp-test program works. Under compiz it fails with the a BadAlloc-error "insufficient resources for operation" for the request X_GLXCreatePixmap. After the last couple of days I'm surprised that GLX_EXT_texture_from_pixmap (compiz) works at all on the i965. I tried to get further clues from compiz' source, but trying to do exactly the same calls compiz does (setting up a GL-context, finding the right fbconfig etc), just isn't working. Also what GLX-version is relevant again? Client, server or this "generic" one? Best regards... Mirco "MacSlow" M?ller -------------- next part -------------- A non-text attachment was scrubbed... Name: x11-tfp-test.tar.bz2 Type: application/x-bzip-compressed-tar Size: 4150 bytes Desc: not available URL: From macslow at bangang.de Fri Dec 28 01:28:37 2007 From: macslow at bangang.de (Mirco =?ISO-8859-1?Q?M=FCller?=) Date: Fri, 28 Dec 2007 10:28:37 +0100 Subject: GLX_EXT_texture_from_pixmap working on GeForce 8800 but not on i965 In-Reply-To: <477231FA.5060907@gmail.com> References: <1198658253.12578.39.camel@HAL9000> <477231FA.5060907@gmail.com> Message-ID: <1198834117.2922.32.camel@HAL9000> Am Mittwoch, den 26.12.2007, 11:50 +0100 schrieb drago01: > >... > > Any help on this issue is much appreciated! > > > have you tryed setting LIBGL_ALWAYS_INDIRECT=1 before starting your app? I do that by passing either True of False for direct-rendering in the call to create a GLX-context. This does not change anything. Best regards... Mirco From xavier.bestel at free.fr Fri Dec 28 02:47:33 2007 From: xavier.bestel at free.fr (Xavier Bestel) Date: Fri, 28 Dec 2007 11:47:33 +0100 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071227.163627.195037633.davem@davemloft.net> References: <1198744545.4976.4.camel@skapc.parateam.prv> <20071227.004300.218132079.davem@davemloft.net> <20071227223534.D20387@artificial-stupidity.net> <20071227.163627.195037633.davem@davemloft.net> Message-ID: <1198838853.5738.5.camel@bip.parateam.prv> On jeu, 2007-12-27 at 16:36 -0800, David Miller wrote: > From: Jaymz Julian > Date: Thu, 27 Dec 2007 22:35:34 +1100 > > > It's not random (it rotates the result in a specific way), but > that's not the > > point - you can easily check for this bevaviour by doing something > like: > > > > (warning: written into email client :-p. Bonus points if you modify > > it to check endian at the same time) > > Actually we can't implement this as a run-time check, I just tried. > > The problem is that we can't handle cross-compilation cases properly. Hi again, (uninformed opinion ahead) I didn't look at where it's used, but if as I think it is, it's for aligning 64bits data, and if it doesn't cause ABI trouble it's perhaps even better to always define it. Processors that allow unaligned accesses do so at a cost, even when they don't trap. Xav From heavytull at hotmail.com Fri Dec 28 04:13:33 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Fri, 28 Dec 2007 12:13:33 +0000 Subject: radeon dual head In-Reply-To: References: <200712231319.11996.harryrat@postnuklear.de> Message-ID: > > #less /var/log/Xorg.0.log > > .... > > (II) LoadModule: "radeon" > > (II) Loading /usr/X11R6/lib/modules/drivers//radeon_drv.so > > (II) Module radeon: vendor="X.Org Foundation" > > compiled for 1.3.0, module version = 4.2.0 > > Module class: X.Org Video Driver > > ABI class: X.Org Video Driver, version 1.2 > > (II) LoadModule: "ati" > > (II) Loading /usr/X11R6/lib/modules/drivers//ati_drv.so > > (II) Module ati: vendor="X.Org Foundation" > > compiled for 1.3.0, module version = 6.6.192 > > Module class: X.Org Video Driver > > ABI class: X.Org Video Driver, version 1.2 > > > > > > (II) ATI: ATI driver wrapper (version 6.6.192) for chipsets: mach64, > > rage128, radeon > > (II) Primary Device is: PCI 01:00:0 > > (II) Loading sub module "radeon" > > (II) LoadModule: "radeon" > > (II) Reloading /usr/X11R6/lib/modules/drivers//radeon_drv.so > > .... > > > > > > http://www.intellinuxgraphics.com/dualhead.html > > > > > > > > by the way i would like to know if this is normal tthat drm is never > > loaded. > > > > > > > > when i load it manually it says: > > > > > > > > root at slack12:/home/slackkk# modprobe drm > > > > FATAL: Error inserting drm > > > > (/lib/modules/2.6.21.5-smp/kernel/drivers/char/drm/drm.ko): Cannot > > allocate > > > > memory > > > > > > > > > > > > > > > > but the X interface works well, Open GL screen savers are Ok, some are > > slow. > > > > google earth is not hard accelerated at all, it is awfully slow and runs > > th > > > > CPU at 100% > > > > > > > #less /var/log/Xorg.0.log > > .... > > (II) RADEON(0): PCIE card detected > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 9, (OK) > > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 9, (OK) > > drmOpenByBusid: drmOpenMinor returns 9 > > drmOpenByBusid: drmGetBusid reports > > drmOpenDevice: node name is /dev/dri/card1 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenByBusid: drmOpenMinor returns -19 > > drmOpenDevice: node name is /dev/dri/card2 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenByBusid: drmOpenMinor returns -19 > > ..... > actually drm was not loaded because fglrx was being load at every X startup. i rmmoded fglrx and drm loads properly: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamk at voicenet.com Fri Dec 28 06:00:48 2007 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri, 28 Dec 2007 09:00:48 -0500 Subject: Moving windows with x2x + X Server 1.4.99.2 Message-ID: <20071228090048.d743b7ec.adamk@voicenet.com> I have an odd situation. I've recently upgraded my x server (so that I could upgrade my DRI drivers and still have AIGLX) on a machine that I send my mouse/keyboard to using x2x. It doesn't (typically) have a keyboard or mouse attached. Now that the new x server (1.4.99.2, built from git yesterday) is being used, I can't move any windows on it unless it's running compiz (I've tried xfwm4 and kwin). I can grab the titlebar and drag, and the mouse cursor changes like it's moving the window, but the window doesn't move. If I have compiz running, I have no problems moving windows. If I throw a mouse onto the machine to test with, I can move windows in kwin and xfwm4. If I leave the mouse attached, and go back to x2x, I still can't move windows. I can't even move windows using the keybindings for the window managers. This happens on two machines (though I suspect it would happen on all my machines, if I used x2x to access them), one with a radeon 9800 and one with an intel 845, so it doesn't appear to be a driver issue. I'm attaching the gzipped Xorg.0.log file from the machine with the 9800. I'll gladly open up a bug report for this if no one here thinks it's a configuration issue. Thanks for your time. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log.gz Type: application/x-gzip Size: 10604 bytes Desc: not available URL: From mail at sphinx.net.ru Fri Dec 28 06:53:47 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Fri, 28 Dec 2007 17:53:47 +0300 Subject: On Linux kernel / X keycodes Message-ID: <871w9698g4.fsf@sphinx.net.ru> Did I miss something or X really doesn't get keycodes higher than 255 from the kernel? Is this intentional limitation? How can it be fixed? -- Happy Hacking. http://sphinx.net.ru ? From daniel at fooishbar.org Fri Dec 28 07:29:01 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Fri, 28 Dec 2007 17:29:01 +0200 Subject: On Linux kernel / X keycodes In-Reply-To: <871w9698g4.fsf@sphinx.net.ru> References: <871w9698g4.fsf@sphinx.net.ru> Message-ID: <20071228152901.GA6099@fooishbar.org> On Fri, Dec 28, 2007 at 05:53:47PM +0300, Dmitry Dzhus wrote: > Did I miss something or X really doesn't get keycodes higher than 255 > from the kernel? Is this intentional limitation? How can it be fixed? X can get extended keycodes with evdev, but you then need to do a remapping, as the protocol can't support more than 255 keycodes, period. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mail at sphinx.net.ru Fri Dec 28 08:02:04 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Fri, 28 Dec 2007 19:02:04 +0300 Subject: On Linux kernel / X keycodes References: <871w9698g4.fsf@sphinx.net.ru> <20071228152901.GA6099@fooishbar.org> Message-ID: <87tzm27qpv.fsf@sphinx.net.ru> Daniel Stone writes: > X can get extended keycodes with evdev, but you then need to do a > remapping Do you mean `setkeycodes(1)`? -- Happy Hacking. http://sphinx.net.ru ? From pcpa at mandriva.com.br Fri Dec 28 09:28:35 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Fri, 28 Dec 2007 15:28:35 -0200 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <477494D9.5020108@sun.com> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> Message-ID: <47753243.1040106@mandriva.com.br> Alan Coopersmith wrote: > pcpa at mandriva.com.br wrote: >> If you check the >> existing video modules, there are other problems, mainly due to not >> compiling with more verbose gcc warnings neither using any tools to >> check >> for things like unresolved symbols (I am using a perl script that parses >> the output of "objdmup -t -T -w --demangle" and cross references symbols >> and "simulates" loading of shared libraries), i.e. things like >> modules with >> missing symbols (function calls) that are actually macros, but the >> proper >> headers were not included, C files declaring "extern" functions that >> don't >> exist, etc. > > I haven't had a chance to update our Solaris builds to 1.4 yet, but we're > building 1.3 and all the drivers we ship (most, but not all, of the video > & input drivers) with -z defs using a mapfile for the Xorg exported > symbols > generated at build time with nm. I did find a couple of unresolvable > symbols that way, but they were all fixed before 1.4. Yes, the problems are more like a "lack of human resources", or some kind of X Org "janitors" team, that would work on making sure old drivers still work (usually ISA only cards), that lib*fb*so that isn't libfb.so still is usable, and people watching over the commits to not "easily" allow breaking API if an alternate/compat method is doable, etc. I don't know what video drivers are available for Solaris (well, for x86 should be the same as Linux :-), but unless you added local patches, anything other than things like ati/nv/intel/vesa have high chances of being broken. Almost all lib*fb*.so other than libfb.so are broken in 1.3. In 1.4 most missing symbols were fixes, and I believe only libxf8_32bpp.so has unresolved symbols, I don't remember all the details, but I think some "magic" must be done to another file, like what is done with cfbgc.c - cfbgc8.c - cfbgc32.c. There is also the problem of symbol clashes, but if I recall corectly, the only case it happens outside Xserver<->libraries is the modes directory, if for some reason a driver that has a copy of this code is compiled using it, while the server compiles with its own version, but that is another history and/or usually a "fault" of whoever compiled a module before the X Server (better to have a symbol defined 2 or more times than never defined) :-) Paulo From daniel at fooishbar.org Fri Dec 28 09:48:11 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Fri, 28 Dec 2007 19:48:11 +0200 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <47753243.1040106@mandriva.com.br> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> <47753243.1040106@mandriva.com.br> Message-ID: <20071228174811.GA9340@fooishbar.org> On Fri, Dec 28, 2007 at 03:28:35PM -0200, Paulo Cesar Pereira de Andrade wrote: > Yes, the problems are more like a "lack of human resources", or some kind > of X Org "janitors" team, Well, patches welcome. People have already started tagging bugs 'janitor' on Bugzilla. > that would work on making sure old drivers still > work (usually ISA only cards), that lib*fb*so that isn't libfb.so still > is usable, Well, basically the only thing preventing conversion from cfb et al is people with the hardware to actually test that the final result works. > and people watching over the commits to not "easily" allow > breaking API if an alternate/compat method is doable, etc. (In these cases, no.) > There is also the problem of symbol clashes, but if I recall corectly, the > only case it happens outside Xserver<->libraries is the modes directory, > if for some reason a driver that has a copy of this code is compiled using > it, while the server compiles with its own version, 'Don't do that.' Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From katoom at pacbell.net Fri Dec 28 11:01:41 2007 From: katoom at pacbell.net (KMF) Date: Fri, 28 Dec 2007 11:01:41 -0800 Subject: CentOS-5 Xorg hopelessly out of date for debugging? Message-ID: <1198868501.19019.8.camel@aprilia> Howdy! I'm trying to debug what I presume to be an Xorg server windowing problem on my CentOS-5.1 system. The OS is up-to-date but the Xorg server version seems very behind: # Xorg -version X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Linux 2.6.9-42.0.3.ELsmp x86_64 Red Hat, Inc. Current Operating System: Linux aprilia 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST 2007 x86_64 Build Date: 10 November 2007 Build ID: xorg-x11-server 1.1.1-48.26.el5 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present I'd prefer to stay in synch with the CentOS distributions especially since I expect that the problem lies with my hardware/software configuration rather than with a bug in the xorg code itself. However, is this version so hopelessly out of date that it's pointless to proceed? Thanks, -- Kevin Flaherty katoom at pacbell.net From pcpa at mandriva.com.br Fri Dec 28 12:55:51 2007 From: pcpa at mandriva.com.br (Paulo Cesar Pereira de Andrade) Date: Fri, 28 Dec 2007 18:55:51 -0200 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <20071228174811.GA9340@fooishbar.org> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> <47753243.1040106@mandriva.com.br> <20071228174811.GA9340@fooishbar.org> Message-ID: <477562D7.1090105@mandriva.com.br> Daniel Stone wrote: > On Fri, Dec 28, 2007 at 03:28:35PM -0200, Paulo Cesar Pereira de Andrade wrote: >> Yes, the problems are more like a "lack of human resources", or some kind >> of X Org "janitors" team, > > Well, patches welcome. People have already started tagging bugs > 'janitor' on Bugzilla. Good to know :-) Now it is only required to have people to work on it. Basically a work that very few people consider important or even notice, and that usually doesn't produce copyrightable work. Unfortunately AFAIK, most "janitors" on OSS are "good samaritans" that work on their free time. >> that would work on making sure old drivers still >> work (usually ISA only cards), that lib*fb*so that isn't libfb.so still >> is usable, > > Well, basically the only thing preventing conversion from cfb et al is > people with the hardware to actually test that the final result works. Or maybe someone implementing things like 1bpp/4bpp/bank switch/whatever in an extension to libfb; probably would be easier to work on the existing modules. Anyway, it should be possible to test the vga driver in any x86 computer. And I think it is functional again with X server 1.4 >> and people watching over the commits to not "easily" allow >> breaking API if an alternate/compat method is doable, etc. > > (In these cases, no.) Maybe I should have said "people with common sense and some understanding of the concepts of ABI/API". In, other words, avoid breaking working code. >> There is also the problem of symbol clashes, but if I recall corectly, the >> only case it happens outside Xserver<->libraries is the modes directory, >> if for some reason a driver that has a copy of this code is compiled using >> it, while the server compiles with its own version, > > 'Don't do that.' I know, but it may take some time to find out the cause, when you are presented to a problem, but doesn't know all details, i.e. discovering this kind of problems with duplicated symbols. And there isn't a clear way to find out dependencies or proper "build order" in modular X org. > Cheers, > Daniel Paulo From techservio at gmail.com Fri Dec 28 13:21:30 2007 From: techservio at gmail.com (techservio) Date: Fri, 28 Dec 2007 13:21:30 -0800 (PST) Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today In-Reply-To: <1198228867.3126.48.camel@rousalka.dyndns.org> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> <20071221153644.64091709@KNIGHT> <1198228867.3126.48.camel@rousalka.dyndns.org> Message-ID: <14531630.post@talk.nabble.com> Nicolas Mailhot wrote: > > > Le vendredi 21 d?cembre 2007 ? 15:36 +1300, Wei-Tsun Sun a ?crit : >> Any particular filed bug known ? > > There is probably one somewhere, but I don't know it. > I've seen the bug discussed several times in non-xorg technical irc > channels, and didn't understood WTF people were talking about till I > started hitting it too. > > Option "XAANoOffscreenPixmaps" in Device section solves this problem for me -- View this message in context: http://www.nabble.com/Re%3A-distorted-fonts-after-updating-xserver-and-video-drivers-to--the-GIT-HEAD-today-tp14316226p14531630.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. From davem at davemloft.net Fri Dec 28 13:23:16 2007 From: davem at davemloft.net (David Miller) Date: Fri, 28 Dec 2007 13:23:16 -0800 (PST) Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <1198838853.5738.5.camel@bip.parateam.prv> References: <20071227223534.D20387@artificial-stupidity.net> <20071227.163627.195037633.davem@davemloft.net> <1198838853.5738.5.camel@bip.parateam.prv> Message-ID: <20071228.132316.18751378.davem@davemloft.net> From: Xavier Bestel Date: Fri, 28 Dec 2007 11:47:33 +0100 > > On jeu, 2007-12-27 at 16:36 -0800, David Miller wrote: > > From: Jaymz Julian > > Date: Thu, 27 Dec 2007 22:35:34 +1100 > > > > > It's not random (it rotates the result in a specific way), but > > that's not the > > > point - you can easily check for this bevaviour by doing something > > like: > > > > > > (warning: written into email client :-p. Bonus points if you modify > > > it to check endian at the same time) > > > > Actually we can't implement this as a run-time check, I just tried. > > > > The problem is that we can't handle cross-compilation cases properly. > > Hi again, > > (uninformed opinion ahead) > I didn't look at where it's used, but if as I think it is, it's for > aligning 64bits data, and if it doesn't cause ABI trouble it's perhaps > even better to always define it. Processors that allow unaligned > accesses do so at a cost, even when they don't trap. Unfortunately this setting adds a non-trivial performance penalty to the in-server GL code. If the incoming GLX stream is unaligned, the code does a memmove() of the entire transaction. So turning this on all the time is an enormously bad idea. From faraci1 at sbcglobal.net Fri Dec 28 13:28:59 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Fri, 28 Dec 2007 15:28:59 -0600 Subject: [PATCH RFC]: Generic Linux multi-domain PCI handling Message-ID: <20071228213539.839A89E7B8@gabe.freedesktop.org> Im a using Debian Etch with Xorg 7.1.0 on a sunblade 1500. I would like to know if I can still make use of this patch, and if so how. I downloaded the source usuing apt-get, but I do not have the Pci.h, and linuxPci.c, my video card is on domain 0001. ATI Radeon 7000/VE Thank You Michael No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.11/1201 - Release Date: 12/28/2007 11:51 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From davem at davemloft.net Fri Dec 28 13:58:29 2007 From: davem at davemloft.net (David Miller) Date: Fri, 28 Dec 2007 13:58:29 -0800 (PST) Subject: [PATCH RFC]: Generic Linux multi-domain PCI handling In-Reply-To: <20071228213539.839A89E7B8@gabe.freedesktop.org> References: <20071228213539.839A89E7B8@gabe.freedesktop.org> Message-ID: <20071228.135829.18340884.davem@davemloft.net> From: "Michael Faraci" Date: Fri, 28 Dec 2007 15:28:59 -0600 > Im a using Debian Etch with Xorg 7.1.0 on a sunblade 1500. I would like to > know if I can still make use of this patch, and if so how. I downloaded the > source usuing apt-get, but I do not have the Pci.h, and linuxPci.c, my video > card is on domain 0001. ATI Radeon 7000/VE The current GIT sources have all of the PCI support handling revamped using a new library called libpciaccess. After I made a minor fix to the kernel, it's in Linus's current GIT, everything in XORG GIT works beautifully. I'm typing thing this on the Radeon on my SunBlade1500 :-) From lists2006 at pervalidus.net Fri Dec 28 14:00:45 2007 From: lists2006 at pervalidus.net (=?ISO-8859-15?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Fri, 28 Dec 2007 20:00:45 -0200 (BRDT) Subject: What to blame for ATI lockups after upgrade ? Message-ID: I used XOrg 1.4 with ATI driver 6.7.196 without any problems for a month. I upgraded to XOrg 1.4.0.90 on december 13 and to ATI 6.7.197 on the 21. On the 22, suddenly, while moving the mouse cursor, nothing worked anymore. I could move the mouse, but it was like an "I" and didn't do anything. The screen was apparently locked, as the clock didn't get updated. After some time and no results, I decided to do a forced reboot. Then, I had the idea to use joyd, a mouse daemon that send commands. Today, I had the same problem while moving the mouse. One of the joyd commands was "/bin/killall -9 X", but the mouse also locked up when it was issued. The other, "/sbin/reboot", worked, and apparently did a clean shutdown, because after a reboot there were no fsck messages about "recovery required". In all above versions, I used the same DRI from Mesa 7.0.2. I have a Radeon 9600. Xorg.0.log prints lots of these when it occurs: tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. From daniel at fooishbar.org Fri Dec 28 14:14:42 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Sat, 29 Dec 2007 00:14:42 +0200 Subject: What to blame for ATI lockups after upgrade ? In-Reply-To: References: Message-ID: <20071228221442.GG9340@fooishbar.org> On Fri, Dec 28, 2007 at 08:00:45PM -0200, Fr?d?ric L. W. Meunier wrote: > Xorg.0.log prints lots of these when it occurs: > > tossed event which came in late > mieqEnequeue: out-of-order valuator event; dropping. This is indicative of a soft lockup. Does current server-1.4-branch work? If not, could you please have a look using git bisect? Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From alexdeucher at gmail.com Fri Dec 28 14:18:36 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Fri, 28 Dec 2007 17:18:36 -0500 Subject: What to blame for ATI lockups after upgrade ? In-Reply-To: References: Message-ID: On Dec 28, 2007 5:00 PM, Fr?d?ric L. W. Meunier wrote: > I used XOrg 1.4 with ATI driver 6.7.196 without any problems > for a month. I upgraded to XOrg 1.4.0.90 on december 13 and to > ATI 6.7.197 on the 21. > > On the 22, suddenly, while moving the mouse cursor, nothing > worked anymore. I could move the mouse, but it was like an "I" > and didn't do anything. The screen was apparently locked, as > the clock didn't get updated. > > After some time and no results, I decided to do a forced > reboot. Then, I had the idea to use joyd, a mouse daemon that > send commands. > > Today, I had the same problem while moving the mouse. > > One of the joyd commands was "/bin/killall -9 X", but the mouse > also locked up when it was issued. > > The other, "/sbin/reboot", worked, and apparently did a clean > shutdown, because after a reboot there were no fsck messages > about "recovery required". > > In all above versions, I used the same DRI from Mesa 7.0.2. I > have a Radeon 9600. Try disabling the DRI or changing the AGPMode. the newer ati driver switched back to AGP 1x mode by default, previous versions defaulted to whatever mode the bios set. Both seem to have stability problems on different cards. Option "AGPMode" "4" Alex From lists2006 at pervalidus.net Fri Dec 28 14:31:06 2007 From: lists2006 at pervalidus.net (=?ISO-8859-15?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Fri, 28 Dec 2007 20:31:06 -0200 (BRDT) Subject: What to blame for ATI lockups after upgrade ? In-Reply-To: References: Message-ID: On Fri, 28 Dec 2007, Alex Deucher wrote: > On Dec 28, 2007 5:00 PM, Fr?d?ric L. W. Meunier wrote: > >> I used XOrg 1.4 with ATI driver 6.7.196 without any problems >> for a month. I upgraded to XOrg 1.4.0.90 on december 13 and to >> ATI 6.7.197 on the 21. >> >> On the 22, suddenly, while moving the mouse cursor, nothing >> worked anymore. I could move the mouse, but it was like an "I" >> and didn't do anything. The screen was apparently locked, as >> the clock didn't get updated. > > Try disabling the DRI or changing the AGPMode. the newer ati driver > switched back to AGP 1x mode by default, previous versions defaulted > to whatever mode the bios set. Both seem to have stability problems > on different cards. > > Option "AGPMode" "4" I always had that option set in my xorg.conf (the card supports 8x, but the motherboard only 4x), so the solution would be to disable DRI and, if I need DRI (I don't for now), return to 6.7.196 ? If neither work, I'll try what Daniel suggested. From mailinglists at who-t.net Fri Dec 28 22:05:57 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Sat, 29 Dec 2007 16:35:57 +1030 Subject: Tablet to screen coordinate conversion (again) In-Reply-To: References: <200710271809.22295.Magnus.Vigerlof@home.se> <200710280217.36648.Magnus.Vigerlof@home.se> Message-ID: <4775E3C5.4060607@who-t.net> Giuseppe Bilotta wrote: > I'm left with another issue, but I'm not sure it's related: when using > the calligraphic pen in Inkscape I get a very 'blotched' line, as if > 'full-pressure' blobs were inserted along the way. I'm not sure wether > this is an Inkscape or driver bug though. It sort of looks like a lot > of 'button 0' events are inserted along the way. And I can't test what > happens with xinput because for some odd reason xinput list > is the only thing that works (xinput test or anything else claims they > can't find the device). please file a bug for the xinput issue so it doesn't get forgotten. (i suspect that if you download the latest git version [0] of xinput this problem should be fixed anyway) Cheers, Peter [0] git://anongit.freedesktop.org/git/xorg/app/xinput From mailinglists at who-t.net Fri Dec 28 22:07:48 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Sat, 29 Dec 2007 16:37:48 +1030 Subject: Moving windows with x2x + X Server 1.4.99.2 In-Reply-To: <20071228090048.d743b7ec.adamk@voicenet.com> References: <20071228090048.d743b7ec.adamk@voicenet.com> Message-ID: <4775E434.9030809@who-t.net> Adam K Kirchhoff wrote: > Now that the new x server (1.4.99.2, built from git yesterday) is being > used, I can't move any windows on it unless it's running compiz (I've > tried xfwm4 and kwin). I can grab the titlebar and drag, and the mouse > cursor changes like it's moving the window, but the window doesn't > move. does the cursor move at all? it could be a grab issue and/or an issue with the XTEST code. Cheers, Peter From mailinglists at who-t.net Fri Dec 28 22:21:24 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Sat, 29 Dec 2007 16:51:24 +1030 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <200712201944.55285.harryrat@postnuklear.de> References: <200712201838.13133.harryrat@postnuklear.de> <1198174627.6426.2.camel@blackadder> <200712201944.55285.harryrat@postnuklear.de> Message-ID: <4775E764.3030701@who-t.net> Harald Radke wrote: > hm, I guess I will rather patch kdrive to support it since it makes more sense > to implement this low level than doin this over and over again for every GUI > toolkit, just as it is for emulate 3 buttons for mouse I disagree. Patching this in the server means putting interaction techniques into the server. This also means that if for some reason my app needs long touch to do, well, whatever, I can't do it because the server prohibits it. unless you have your own device with a limited user base and you tightly control the apps on your devices I strongly discourage from putting interaction techniques into the server itself. As an example, many many moons ago the decision was made to put a restriction for a single cursor/keyboard focus into the server. and see where that got us... Cheers, Peter (who has repeatedly attempted to gnaw through his wrists when resolving the above issue) From Alan.Coopersmith at Sun.COM Fri Dec 28 23:33:45 2007 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Fri, 28 Dec 2007 23:33:45 -0800 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <477562D7.1090105@mandriva.com.br> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> <47753243.1040106@mandriva.com.br> <20071228174811.GA9340@fooishbar.org> <477562D7.1090105@mandriva.com.br> Message-ID: <4775F859.50200@sun.com> Paulo Cesar Pereira de Andrade wrote: > Good to know :-) Now it is only required to have people to work on it. > Basically a work that very few people consider important or even notice, > and that usually doesn't produce copyrightable work. Unfortunately AFAIK, > most "janitors" on OSS are "good samaritans" that work on their free > time. I do some of that at work while waiting for other builds to finish or when otherwise procrastinating. I've left a bunch of the janitorial bugs alone so they can serve as introductory work for new developers getting into the code, but apply patches from bugzilla and the like. > kind of problems with duplicated symbols. And there isn't a clear way to > find out dependencies or proper "build order" in modular X org. "less util/modular/build.sh" has always worked for me to find proper build order. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From faraci1 at sbcglobal.net Fri Dec 28 23:48:26 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Sat, 29 Dec 2007 01:48:26 -0600 Subject: usinggit to compile xorg Message-ID: <20071229074826.4B5A69EB03@gabe.freedesktop.org> Hello all Since my last question on a fix for Sun ultrasparc multi pci domain and Xorg. David Miller replied and explained that the Xorg in git repo is working with this architecture. I have installed the git-core, and have ran the git_xorg.sh to pull dowm src, I then ran the build.sh ?n ?D /tmp/modular. Im not sure how to procede, should there me a make file somewhere? Im running Debian Etch on a SunBlade 1500, ATI Radeon 7000/VE. Thank You No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.11/1201 - Release Date: 12/28/2007 11:51 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Coopersmith at Sun.COM Sat Dec 29 00:27:46 2007 From: Alan.Coopersmith at Sun.COM (Alan Coopersmith) Date: Sat, 29 Dec 2007 00:27:46 -0800 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <47753243.1040106@mandriva.com.br> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> <47753243.1040106@mandriva.com.br> Message-ID: <47760502.9080806@sun.com> Paulo Cesar Pereira de Andrade wrote: > I don't know what video drivers are available for Solaris (well, for x86 > should be the same as Linux :-), but unless you added local patches, > anything > other than things like ati/nv/intel/vesa have high chances of being broken. For x86 we ship these video drivers: apm_drv.so ark_drv.so ast_drv.so ati_drv.so atimisc_drv.so chips_drv.so cirrus_alpine.so cirrus_drv.so cirrus_laguna.so cyrix_drv.so glint_drv.so i128_drv.so i740_drv.so intel_drv.so mga_drv.so neomagic_drv.so nsc_drv.so nv_drv.so radeon_drv.so radeonhd_drv.so r128_drv.so rendition_drv.so s3_drv.so s3virge_drv.so savage_drv.so siliconmotion_drv.so sis_drv.so tdfx_drv.so tga_drv.so trident_drv.so tseng_drv.so vesa_drv.so vga_drv.so via_drv.so vmware_drv.so (On amd64, we dropped a bunch of the older ones as being unlikely to appear in a amd64 machine - especially the ancient pre-PCI boards like Rendition.) I can only claim to have tried a few myself - mostly those you mentioned, and I know others who use mga_drv.so & vmware_drv.so. We add some local patches, but not many. Some of the ones we had to add when we got missing symbol errors in our build include: http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/driver/xf86-video-intel/libraries.patch http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/driver/xf86-video-s3/newmmio.patch http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/driver/xf86-video-trident/tridentramdac.patch (As you can see, several have been pushed upstream already.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering From harryrat at postnuklear.de Sat Dec 29 02:00:57 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Sat, 29 Dec 2007 11:00:57 +0100 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <4775E764.3030701@who-t.net> References: <200712201838.13133.harryrat@postnuklear.de> <200712201944.55285.harryrat@postnuklear.de> <4775E764.3030701@who-t.net> Message-ID: <200712291100.57448.harryrat@postnuklear.de> On Saturday 29 December 2007 07:21:24 Peter Hutterer wrote: > Harald Radke wrote: > > hm, I guess I will rather patch kdrive to support it since it makes more > > sense to implement this low level than doin this over and over again for > > every GUI toolkit, just as it is for emulate 3 buttons for mouse > > I disagree. Patching this in the server means putting interaction > techniques into the server sorry, I don't get the point here > This also means that if for some reason my > app needs long touch to do, well, whatever, I can't do it because the > server prohibits it. well, of course such a behaviour can/should be tied to a command line option, to be disabled by default, only be activated by the user if it makes sense for him in his situation...The thing is, you want to be able to have the possibilty to use a certain (example) app, while I want to be able to use 70% of the X applications, which mostly requires to have a right mouse button... (ok that was a wild guess, but u know what I mean *g*) Harry From mailinglists at who-t.net Sat Dec 29 02:06:22 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Sat, 29 Dec 2007 20:36:22 +1030 Subject: usinggit to compile xorg In-Reply-To: <20071229074826.4B5A69EB03@gabe.freedesktop.org> References: <20071229074826.4B5A69EB03@gabe.freedesktop.org> Message-ID: <47761C1E.3050409@who-t.net> Michael Faraci wrote: I have installed the git-core, and have ran > the git_xorg.sh to pull dowm src, I then ran the build.sh ?n ?D > /tmp/modular. Im not sure how to procede, should there me a make file > somewhere? if the build script completed successfully then everything is installed in /tmp/modular (in your case). each directory should also have a tarball, in case you want to go through the fun of compiling everything again. Most likely however it won't work, the -n flag causes everything to continue even if a component fails and I have yet to compile a full run of the repository in one go... best to retry without the -n flag and fix the errors. Cheers, Peter From listgetter at ncbx-mln.de Sat Dec 29 02:44:05 2007 From: listgetter at ncbx-mln.de (Christian Franck) Date: Sat, 29 Dec 2007 11:44:05 +0100 Subject: ok also for "nv" (was: Re: distorted fonts after updating xserver and video drivers to the GIT HEAD today) In-Reply-To: <14531630.post@talk.nabble.com> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> <20071221153644.64091709@KNIGHT> <1198228867.3126.48.camel@rousalka.dyndns.org> <14531630.post@talk.nabble.com> Message-ID: <20071229104405.GA17539@lygeia.ncbx-mln.de> On Fri, Dec 28, 2007 at 01:21:30PM -0800, techservio wrote: > Option "XAANoOffscreenPixmaps" > in Device section solves this problem for me Hello, same here, problem solved by this option. JFTR: X server : X.Org X Server 1.4.99.2 (built from git) video card : nVidia Corporation NV25 [GeForce4 Ti 4400] X.org driver : "nv" Thanks a lot and best seasonal greetings Christian From bamboo9527 at gmail.com Sat Dec 29 04:15:42 2007 From: bamboo9527 at gmail.com (antilife) Date: Sat, 29 Dec 2007 20:15:42 +0800 Subject: Some problem about writing a x driver Message-ID: <002c01c84a14$8d85b2d0$3601a8c0@lgw3dce7a2070b> x driver: ...... ...... xf86PostMotionEvent(device, 1, 0, 3, x, y, p);//for example: x=50,y=100 user program: use xlib to fetch motion event: XEvent event; XNextEvent(disp, &event); ... XDeviceMotionEvent *me = (XDeviceMotionEvent*)&event; x = me->axis_data[0];//x=50 y = me->axis_data[1];//y=100 I get the correct values. But use gtk, i get the wrong values: static gint motion_notify_event(GtkWidget *widget, GdkEventMotion *event) { ... x = event->x;// x less than the xf86PostMotionEvent'x y = event->y;// y less than the xf86PostMotionEvent'y ... return TRUE; } Anybody who can tell me the truth? many thanks... -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamk at voicenet.com Sat Dec 29 04:43:04 2007 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Sat, 29 Dec 2007 07:43:04 -0500 Subject: Moving windows with x2x + X Server 1.4.99.2 In-Reply-To: <4775E434.9030809@who-t.net> References: <20071228090048.d743b7ec.adamk@voicenet.com> <4775E434.9030809@who-t.net> Message-ID: <200712290743.04913.adamk@voicenet.com> On Saturday 29 December 2007 01:07:48 Peter Hutterer wrote: > Adam K Kirchhoff wrote: > > Now that the new x server (1.4.99.2, built from git yesterday) is being > > used, I can't move any windows on it unless it's running compiz (I've > > tried xfwm4 and kwin). I can grab the titlebar and drag, and the mouse > > cursor changes like it's moving the window, but the window doesn't > > move. > > does the cursor move at all? it could be a grab issue and/or an issue > with the XTEST code. > > Cheers, > Peter Yes, the cursor definitely moves, but the window doesn't move (or resize, for that matter) with it. Adam From giuseppe.bilotta at gmail.com Sat Dec 29 06:17:05 2007 From: giuseppe.bilotta at gmail.com (Giuseppe Bilotta) Date: Sat, 29 Dec 2007 15:17:05 +0100 Subject: Tablet to screen coordinate conversion (again) In-Reply-To: <4775E3C5.4060607@who-t.net> References: <200710271809.22295.Magnus.Vigerlof@home.se> <200710280217.36648.Magnus.Vigerlof@home.se> <4775E3C5.4060607@who-t.net> Message-ID: On 12/29/07, Peter Hutterer wrote: > Giuseppe Bilotta wrote: > > I'm left with another issue, but I'm not sure it's related: when using > > the calligraphic pen in Inkscape I get a very 'blotched' line, as if > > 'full-pressure' blobs were inserted along the way. I'm not sure wether > > this is an Inkscape or driver bug though. It sort of looks like a lot > > of 'button 0' events are inserted along the way. And I can't test what > > happens with xinput because for some odd reason xinput list > > is the only thing that works (xinput test or anything else claims they > > can't find the device). > > please file a bug for the xinput issue so it doesn't get forgotten. > > (i suspect that if you download the latest git version [0] of xinput > this problem should be fixed anyway) Yes, it's fixed in git, thanks. I'll remember to file any new bugs I might find. -- Giuseppe "Oblomov" Bilotta From remi at gentoo.org Sat Dec 29 06:55:57 2007 From: remi at gentoo.org (=?ISO-8859-1?Q?R=E9mi_Cardona?=) Date: Sat, 29 Dec 2007 15:55:57 +0100 Subject: Kdrive - touchscreen - long touch == button 3? In-Reply-To: <200712291100.57448.harryrat@postnuklear.de> References: <200712201838.13133.harryrat@postnuklear.de> <200712201944.55285.harryrat@postnuklear.de> <4775E764.3030701@who-t.net> <200712291100.57448.harryrat@postnuklear.de> Message-ID: <47765FFD.1000003@gentoo.org> Harald Radke a ?crit : >> This also means that if for some reason my >> app needs long touch to do, well, whatever, I can't do it because the >> server prohibits it. > well, of course such a behaviour can/should be tied to a command line option, > to be disabled by default, only be activated by the user if it makes sense > for him in his situation...The thing is, you want to be able to have the > possibilty to use a certain (example) app, while I want to be able to use 70% > of the X applications, which mostly requires to have a right mouse button... > (ok that was a wild guess, but u know what I mean *g*) I think you can do what you want from outside the server using XEvIE (unless KDrive doesn't support it). Cheers, R?mi From adamk at voicenet.com Sat Dec 29 07:11:28 2007 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Sat, 29 Dec 2007 10:11:28 -0500 Subject: Moving windows with x2x + X Server 1.4.99.2 In-Reply-To: <200712290743.04913.adamk@voicenet.com> References: <20071228090048.d743b7ec.adamk@voicenet.com> <4775E434.9030809@who-t.net> <200712290743.04913.adamk@voicenet.com> Message-ID: <20071229101128.f5b1eb55.adamk@voicenet.com> On Sat, 29 Dec 2007 07:43:04 -0500 Adam K Kirchhoff wrote: > On Saturday 29 December 2007 01:07:48 Peter Hutterer wrote: > > Adam K Kirchhoff wrote: > > > Now that the new x server (1.4.99.2, built from git yesterday) is > > > being used, I can't move any windows on it unless it's running > > > compiz (I've tried xfwm4 and kwin). I can grab the titlebar and > > > drag, and the mouse cursor changes like it's moving the window, > > > but the window doesn't move. > > > > does the cursor move at all? it could be a grab issue and/or an > > issue with the XTEST code. > > > > Cheers, > > Peter > > Yes, the cursor definitely moves, but the window doesn't move (or > resize, for that matter) with it. > Oddly enough, it works with metacity in addition to compiz. With compiz, moving windows is quite smooth, and you can see the window while it moves. With metacity, the window doesn't move till I actually stop moving the mouse (though I don't need to release the mouse button... I can drag, stop, and the window moves, and then drag again, stop, and the window moves). I've tested as well on my laptop (first generation radeon mobility), and see the same problem. Of course, as soon as I use the touchpad (or USB mouse) to move the windows in metacity, it goes back to showing the content of the windows as I move them. Adam From pcpa at mandriva.com.br Sat Dec 29 08:08:17 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Sat, 29 Dec 2007 14:08:17 -0200 Subject: [PATCH]: Fix GLX crashes on RISC cpus. In-Reply-To: <4775F859.50200@sun.com> References: <20071227082218.GC21019@fooishbar.org> <20071227.003416.249664616.davem@davemloft.net> <20071227095643.GD21019@fooishbar.org> <20071227.140433.198915809.davem@davemloft.net> <20071228003151.bae8kuq11me8oc0c@webmail.conectiva.com.br> <477494D9.5020108@sun.com> <47753243.1040106@mandriva.com.br> <20071228174811.GA9340@fooishbar.org> <477562D7.1090105@mandriva.com.br> <4775F859.50200@sun.com> Message-ID: <20071229140817.32csh13myo0008c0@webmail.conectiva.com.br> Quoting Alan Coopersmith : > Paulo Cesar Pereira de Andrade wrote: >> Good to know :-) Now it is only required to have people to work on it. >> Basically a work that very few people consider important or even notice, >> and that usually doesn't produce copyrightable work. Unfortunately AFAIK, >> most "janitors" on OSS are "good samaritans" that work on their free >> time. > > I do some of that at work while waiting for other builds to finish or when > otherwise procrastinating. I've left a bunch of the janitorial bugs alone > so they can serve as introductory work for new developers getting into the > code, but apply patches from bugzilla and the like. I understand. Maybe I am talking about "advanced janitors" (I am not saying you are not an "advanced janitor") :-) i.e. people that doesn't write new features, but will do things like git bitsect and test different versions, invest several hours in debugging sessions, doing things like "ErrorF debug" until finding some wrong code, and then inspecting variables, stack, etc (this requires a lot of time invested with close to zero return, personally, I have sastisfaction finding and fixing obscure bugs, but I am weird :-). I used to do this kind of thing for XFree86 and other projects, but nowadays I have my own personal projects, etc... >> kind of problems with duplicated symbols. And there isn't a clear way to >> find out dependencies or proper "build order" in modular X org. > > "less util/modular/build.sh" has always worked for me to find proper > build order. I am using a different approach. I am sorry I don't have all scripts complete, neither know exactly what approach was used to generate util/modular scripts (but a review should not hurt :-) but the current code is like this: o search all .deps directories o create a .deps file where contents are basically -- : # rpm package of file -- Example of first lines of xorg-server.deps: -- /usr/include/X11/extensions/Xcup.h:1198443181 # x11-proto-devel-7.3-2mdv2008.0 /usr/include/asm/sockios.h:1186061974 # glibc-devel-2.6.1-4.1mdv2008.0 /usr/include/asm-generic/ioctl.h:1186061951 # glibc-devel-2.6.1-4.1mdv2008.0 /usr/include/dbus-1.0/dbus/dbus-macros.h:1189532431 # libdbus-1_3-devel-1.0.2-10mdv2008.0 /usr/include/termios.h:1195662581 # glibc-devel-2.6.1-4.1mdv2008.0 -- I am adding this to .deps file to -devel rpm packages, but the proper name could be a -packager package :-) Note that rpm packages don't always match X Org packages, but I am trying to rework it, example, in Mandriva all *proto are in a single package. Also note that the perl scripts may need some updates, as some files may always be generated, currently, and at least in my build, xorg-server.h is always being regenerated. It also prints warning if some include not in /usr/include or /usr/lib/gcc is used (and ofcourse, doesn't list dependencies on headers inside the build tree :-) The mtime field is usede by another script, that call tell what has been modified, or if new dependencies exist, or if old dependencies were droped, among others. But needs manual intervention to check if a package really needs to be rebuilt. After generating these files, another script reads the .deps files and builds a list like: rpm-name : (rpm-dep1, rpm-dep2, ...) and then, just use "tsort | tac" to print "build order" as well as detect possible cyclic dependencies. I need to also create a possible other method for ``modules'' that aren't compiled (i.e. things like data files, m4 macros, etc), or a dependency list is not generated (possibly some hand written Makefile, or the like). Cavassin at Mandriva suggested me to use or write a variant of an old rpm script (dep) that basically uses strace and logs all opens and execs during builds (since the concept is simple, I will try it soon, but I believe it will be really slow :-). > -- > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering Paulo From techservio at gmail.com Sat Dec 29 08:25:43 2007 From: techservio at gmail.com (techservio) Date: Sat, 29 Dec 2007 08:25:43 -0800 (PST) Subject: how to compile Xgl? Message-ID: <14538954.post@talk.nabble.com> Is it possible to compile Xgl from git? Here my actions: git clone git://anongit.freedesktop.org/git/xorg/xserver cd xserver git checkout origin/xgl-0-0-1 ./autogen.sh --prefix=/opt/xgl --enable-xgl --disable-xorg --disable-xprint --enable-glx --enable-dri --with-mesa-source=/build/X.org/mesa-drm/mesa --with-dri-driver-path=/usr/lib/dri --with-release-snap=1 --disable-xvfb --disable-xnest --enable-xglx --enable-xkb --disable-kdriveserver --disable-dmx make compilation finished with a error: dispatch.c:115:35: error: X11/extensions/Xagsrv.h: No such file or directory dispatch.c:118:1: warning: "XKB_IN_SERVER" redefined In file included from dispatch.c:82: ../include/dix-config.h:346:1: warning: this is the location of the previous definition make[1]: *** [dispatch.lo] Error 1 make[1]: Leaving directory `/mnt/d6/xgl/build/dix' make: *** [all-recursive] Error 1 What is wrong? -- View this message in context: http://www.nabble.com/how-to-compile-Xgl--tp14538954p14538954.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. From mail at sphinx.net.ru Sat Dec 29 08:31:29 2007 From: mail at sphinx.net.ru (Dmitry Dzhus) Date: Sat, 29 Dec 2007 19:31:29 +0300 Subject: On Linux kernel / X keycodes References: <871w9698g4.fsf@sphinx.net.ru> <20071228152901.GA6099@fooishbar.org> Message-ID: <87k5mx799a.fsf@sphinx.net.ru> Daniel Stone writes: >> Did I miss something or X really doesn't get keycodes higher than 255 >> from the kernel? Is this intentional limitation? How can it be fixed? > > X can get extended keycodes with evdev, but you then need to do a > remapping, as the protocol can't support more than 255 keycodes, period. Some of the extra keys on my keyboard get really high *kernel* keycodes, like 418 or 432. Does `evdev(4x)` pass such high keycodes to X? I've noted the following code in `evdev_key.c`: int keycode = ev->code + MIN_KEYCODE; (And `MIN_KEYCODE` is 8 by definition.) As far I've understood, later keypress from event kernel interface gets processed further by xf86PostKeyboardEvent(pInfo->dev, keycode, ev->value); Where keycodes>255 seem to get lost. How can I use a device producing high kernel keycodes in X with `evdev(4x)`? `setkeycodes(1)` doesn't allow me to rebind kernel keycode; I've found that a possible solution (actually a kludge) is to change builtin kernel keycodes in `include/linux/input.h` for problem keys to some lower value not colliding with existing keycodes ? then X server sees my keypresses wonderfully, but that's a dirty hack and I want to find out how X server and `evdev(4x)` really deal with kernel keycodes. -- Happy Hacking. http://sphinx.net.ru ? From michel at tungstengraphics.com Sat Dec 29 09:30:53 2007 From: michel at tungstengraphics.com (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Sat, 29 Dec 2007 18:30:53 +0100 Subject: GLX_EXT_texture_from_pixmap working on GeForce 8800 but not on i965 In-Reply-To: <1198834117.2922.32.camel@HAL9000> References: <1198658253.12578.39.camel@HAL9000> <477231FA.5060907@gmail.com> <1198834117.2922.32.camel@HAL9000> Message-ID: <1198949453.15483.14.camel@thor.sulgenrain.local> On Fri, 2007-12-28 at 10:28 +0100, Mirco M?ller wrote: > Am Mittwoch, den 26.12.2007, 11:50 +0100 schrieb drago01: > > >... > > > Any help on this issue is much appreciated! > > > > > have you tryed setting LIBGL_ALWAYS_INDIRECT=1 before starting your app? > > I do that by passing either True of False for direct-rendering in the > call to create a GLX-context. That's not the same thing. As there's no way to express in the GLX API that an extension is only supported with indirect rendering, GLX_EXT_texture_from_pixmap can only be advertised when the environment variable is set. It might be able to work regardless if you force an indirect context, but setting the environment variable is probably worth a try anyway. -- Earthling Michel D?nzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer From wsun013 at gmail.com Sat Dec 29 12:23:00 2007 From: wsun013 at gmail.com (Wei-Tsun Sun) Date: Sun, 30 Dec 2007 09:23:00 +1300 Subject: Blurred fonts under the X.org + Mesa + DRI In-Reply-To: References: Message-ID: <20071230092300.6aae275b@KNIGHT> Well, in my case, qt3 programs are stuffed. QT4 are alright. GTK2s are alright too. Here is my screenshot, i am running open source driver with radeon 7500. http://i215.photobucket.com/albums/cc312/wsun013/20071212-xorg/a.png On Wed, 26 Dec 2007 12:07:54 +0500 "paul paul" wrote: > X.org and Mesa were installed (from git) over the fresh installation of > LFS. > The video-card is Radeon 9600 with proper driver settings in the xorg.conf > (radeon). > > The X window starts properly. Direct rendering is enabled and glxgears shows > ~3000fps. > According to the log-file the r300_dri driver is actually loaded and this is > why > Open-GL and DRI are functioning properly, I guess. > > Yet a huge problem exists in the work of the window managers. (I tried > IceWM and KDE3). > That is: fonts (including labels, texts and menu items) are blurred (as if > they were cross-hatched). Snapshot: > http://www.myfilestash.com/userfiles/techservio/snapshot2.jpg. > If the driver is set into the "vesa" mode, the letters are displayed > properly, but the direct rendering is obviously not supported. > > It must be noted that in the case of KDE4, letters, in general, are > visualized properly, but in the GTK-based applications letters are still > blurred . > > Did anyone experienced the same problem? If so what is the solution (if > any, in the case of Radeon 9600 video-card)? > > I also tried to use the proprietary ATI driver. After the driver was > installed ("fglrx" in the xorg.conf), X did not start. The following error > message was issued: > > (II) Loading /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so > dlopen: /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so: undefined symbol: > miZeroLineScreenIndex > (EE) Failed to load /opt/xorg/lib/xorg/modules/drivers//fglrx_drv.so > (II) UnloadModule: "fglrx" > (EE) Failed to load module "fglrx" (loader failed, 7) > > Does any one know about the nature of this error message? From dottedmag at dottedmag.net Sat Dec 29 12:28:04 2007 From: dottedmag at dottedmag.net (Mikhail Gusarov) Date: Sun, 30 Dec 2007 02:28:04 +0600 Subject: Blurred fonts under the X.org + Mesa + DRI In-Reply-To: (paul paul's message of "Wed, 26 Dec 2007 12:07:54 +0500") References: Message-ID: <878x3dtfe3.fsf@vertex.dottedmag.net> "paul paul" writes: > That is: fonts (including labels, texts and menu items) are blurred > (as if they were cross-hatched). I've seen such problem with radeon 9600 (see the comment #11): http://bugs.freedesktop.org/show_bug.cgi?id=12387 You may try to update your xorg.conf as mentioned in bug report. If problem persists, you might want to try to build driver from git and then reopen bug if fresh driver does not help. -- JID: dottedmag at jabber.dottedmag.net From bart at cs.pdx.edu Sat Dec 29 13:11:47 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Sat, 29 Dec 2007 13:11:47 -0800 Subject: Reminder to vote for Foundation Board Message-ID: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> This is just a gentle reminder to X.Org Foundation members that there are about 2 days left to vote in the current X.Org Foundation Board election. Please visit http://members.x.org to vote. I've attached the previous election announcement. Thanks much for your contributions to X.Org. Bart Massey Election Committee X.Org Foundation Board bart at cs.pdx.edu -------------- next part -------------- An embedded message was scrubbed... From: Barton C Massey Subject: Election of X.Org Foundation Board Members is now open Date: Fri, 21 Dec 2007 12:36:22 -0800 Size: 9189 URL: From libv at skynet.be Sat Dec 29 14:02:50 2007 From: libv at skynet.be (Luc Verhaegen) Date: Sat, 29 Dec 2007 23:02:50 +0100 Subject: Reminder to vote for Foundation Board In-Reply-To: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> Message-ID: <20071229220250.GA389@skynet.be> On Sat, Dec 29, 2007 at 01:11:47PM -0800, Barton C Massey wrote: > This is just a gentle reminder to X.Org Foundation members > that there are about 2 days left to vote in the current > X.Org Foundation Board election. Please visit > http://members.x.org to vote. I've attached the previous > election announcement. This is all rather awkward timing. Is there a statutary reason for ending the election in 2007? I can imagine that a lot of people will be in places without access to the interweb, or that there are people who do not check (for instance) their work email during this period. Those people will be rather surprised to find these election emails in their mailbox on january 2nd, or even worse, january 7th, this no matter how many reminders they get sent. To be honest, i didn't find the reasons for delaying the nomination process that important, certainly not important enough for staging the actual elections at the most awkward time of year. Maybe the election period should be extended by a week? Luc Verhaegen. SUSE/Novell X Driver Developer. From mailinglists at who-t.net Sat Dec 29 21:27:31 2007 From: mailinglists at who-t.net (Peter Hutterer) Date: Sun, 30 Dec 2007 15:57:31 +1030 Subject: On Linux kernel / X keycodes In-Reply-To: <87k5mx799a.fsf@sphinx.net.ru> References: <871w9698g4.fsf@sphinx.net.ru> <20071228152901.GA6099@fooishbar.org> <87k5mx799a.fsf@sphinx.net.ru> Message-ID: <47772C43.6070609@who-t.net> Dmitry Dzhus wrote: > Some of the extra keys on my keyboard get really high *kernel* keycodes, > like 418 or 432. > > Does `evdev(4x)` pass such high keycodes to X? no. the server ignores codes outside of the 0-255 range. > > Where keycodes>255 seem to get lost. How can I use a device producing > high kernel keycodes in X with `evdev(4x)`? `setkeycodes(1)` doesn't > allow me to rebind kernel keycode; I've found that a possible solution > (actually a kludge) is to change builtin kernel keycodes in > `include/linux/input.h` for problem keys to some lower value not > colliding with existing keycodes ? then X server sees my keypresses > wonderfully, but that's a dirty hack and I want to find out how X server > and `evdev(4x)` really deal with kernel keycodes. the problem is that there's only 8 bits in the protocol. so if you have keycodes > 256 you need two+ keymaps. if such a key occurs, you have to send a mapping notify to the app first to let it switch to the new keymap. that's how I understand it anyway. it's a bit of a chicken and egg problem. when we get the data (SIGIO handling), we can't switch the keymap. on the other hand, when we can switch the keymap (event processing), the data is already lost (normalised to 256). Cheers, Peter From jra at baylink.com Sat Dec 29 22:43:17 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 30 Dec 2007 01:43:17 -0500 Subject: Reminder to vote for Foundation Board In-Reply-To: <20071229220250.GA389@skynet.be> References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> Message-ID: <20071230064317.GB29629@cgi.jachomes.com> On Sat, Dec 29, 2007 at 11:02:50PM +0100, Luc Verhaegen wrote: > On Sat, Dec 29, 2007 at 01:11:47PM -0800, Barton C Massey wrote: > > This is just a gentle reminder to X.Org Foundation members > > that there are about 2 days left to vote in the current > > X.Org Foundation Board election. Please visit > > http://members.x.org to vote. I've attached the previous > > election announcement. > > This is all rather awkward timing. Is there a statutary reason for > ending the election in 2007? > > I can imagine that a lot of people will be in places without access to > the interweb, or that there are people who do not check (for > instance) their work email during this period. Those people will be > rather surprised to find these election emails in their mailbox on > january 2nd, or even worse, january 7th, this no matter how many > reminders they get sent. WADR, this argument already got made... a month ago. Did it not? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From jerone at gmail.com Sat Dec 29 23:01:28 2007 From: jerone at gmail.com (Jerone Young) Date: Sun, 30 Dec 2007 01:01:28 -0600 Subject: MacBook Intel GMA950 w/ Dell 2407WFP - resolution problem Message-ID: <9f50a7a00712292301nc205f08ia255af564ddc7f8d@mail.gmail.com> I am seeing something like this problem with my GMA965 (in my Lenovo Thinkpad T61) w/ Samsung 243T via DVI or VGA connectors. Xrandr sees it can do 1920x1200 yet it is stuck at 1280x1024 @ 75hz , which my monitor then shows out of sync. The problem is definitely with the intel driver as I can use it fine under Windows Vista with my Thinkpad via DVI or VGA. When you try to do anything with xrandr to the monitor .. it does NOTHING! Can't change the res on it or anything. Now this works perfectly fine with my Nvidia card in my desktop using xorg "nv" driver as well as proprietary driver. I've attached 2 docs to this email showing output data from my desktop hooked to the Samsung 243T (the good one) .. and my Thinkpad T61 connected to the Samsung 243T I'm really surprised as I really expected this to just work .. and now I've had a chance to try it and I'm like WTF! Docs are attached with xrandr info for everyone's enjoyment (or someone can figure out what is going on). Also looking through bugzilla I found something that may "possibly" be related: https://bugs.freedesktop.org/show_bug.cgi?id=10694 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xrandr_intel_samsung243T_BAD.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xrandr_nv_samsung_243T_WORKS.txt URL: From sndirsch at suse.de Sun Dec 30 01:29:58 2007 From: sndirsch at suse.de (Stefan Dirsch) Date: Sun, 30 Dec 2007 10:29:58 +0100 Subject: Reminder to vote for Foundation Board In-Reply-To: <20071230064317.GB29629@cgi.jachomes.com> References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> <20071230064317.GB29629@cgi.jachomes.com> Message-ID: <20071230092957.GA10850@suse.de> On Sun, Dec 30, 2007 at 01:43:17AM -0500, Jay R. Ashworth wrote: > On Sat, Dec 29, 2007 at 11:02:50PM +0100, Luc Verhaegen wrote: > > On Sat, Dec 29, 2007 at 01:11:47PM -0800, Barton C Massey wrote: > > > This is just a gentle reminder to X.Org Foundation members > > > that there are about 2 days left to vote in the current > > > X.Org Foundation Board election. Please visit > > > http://members.x.org to vote. I've attached the previous > > > election announcement. > > > > This is all rather awkward timing. Is there a statutary reason for > > ending the election in 2007? > > > > I can imagine that a lot of people will be in places without access to > > the interweb, or that there are people who do not check (for > > instance) their work email during this period. Those people will be > > rather surprised to find these election emails in their mailbox on > > january 2nd, or even worse, january 7th, this no matter how many > > reminders they get sent. I can only second that! > WADR, this argument already got made... a month ago. Did it not? I'm not aware of the election period being mentioned anytime before the announcement for itself on Fri Dec 21. Could you provide some reference for your statement? Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstra?e 5 FAX: 0911-740 53 479 D-90409 N?rnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg) ----------------------------------------------------------------- From eich at suse.de Sun Dec 30 01:53:07 2007 From: eich at suse.de (Egbert Eich) Date: Sun, 30 Dec 2007 10:53:07 +0100 Subject: Reminder to vote for Foundation Board In-Reply-To: libv@skynet.be wrote on Saturday, 29 December 2007 at 23:02:50 +0100 References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> Message-ID: <18295.27267.772930.202030@cicero.suse.de> Luc Verhaegen writes: > > This is all rather awkward timing. Is there a statutary reason for > ending the election in 2007? > > I can imagine that a lot of people will be in places without access to > the interweb, or that there are people who do not check (for > instance) their work email during this period. Those people will be > rather surprised to find these election emails in their mailbox on > january 2nd, or even worse, january 7th, this no matter how many > reminders they get sent. > > To be honest, i didn't find the reasons for delaying the nomination > process that important, certainly not important enough for staging the > actual elections at the most awkward time of year. > > Maybe the election period should be extended by a week? > The timing was such that the announcement arrived when a lot of people (here in Europe) were already heading for the weekend - and most likely for Christmas vacation. Therefore I raised this issue with the election subcommittee and made a similar suggestion. However there were also concerns about extending the period while the election was already in progress. Cheers, Egbert. From wsun013 at gmail.com Sun Dec 30 02:07:22 2007 From: wsun013 at gmail.com (Wei-Tsun Sun) Date: Sun, 30 Dec 2007 23:07:22 +1300 Subject: distorted fonts after updating xserver and video drivers to the GIT HEAD today In-Reply-To: <14531630.post@talk.nabble.com> References: <13804.192.54.193.58.1197553237.squirrel@rousalka.dyndns.org> <20071221153644.64091709@KNIGHT> <1198228867.3126.48.camel@rousalka.dyndns.org> <14531630.post@talk.nabble.com> Message-ID: <20071230230722.6417c2f2@KNIGHT> > Nicolas Mailhot wrote: > > > > > > Le vendredi 21 d?cembre 2007 ? 15:36 +1300, Wei-Tsun Sun a ?crit : > >> Any particular filed bug known ? > > > > There is probably one somewhere, but I don't know it. > > I've seen the bug discussed several times in non-xorg technical irc > > channels, and didn't understood WTF people were talking about till I > > started hitting it too. > > > > > > Option "XAANoOffscreenPixmaps" > in Device section solves this problem for me Option "AccelMethod" "EXA" solves the problem for me, if Option "AccelMethod" "XXA" is used, distorted will occour. however, the perfomance with EXA on my radeon 7500m is not as good as it was with XXA. From linux at arcoscom.com Sun Dec 30 03:22:38 2007 From: linux at arcoscom.com (ArcosCom Linux User) Date: Sun, 30 Dec 2007 12:22:38 +0100 (CET) Subject: Please help!! - Re: Problems with two S3 video devices. In-Reply-To: <34974.10.1.1.10.1198831723.squirrel@www.arcoscom.com> References: <34974.10.1.1.10.1198831723.squirrel@www.arcoscom.com> Message-ID: <51861.10.1.1.10.1199013758.squirrel@www.arcoscom.com> Please, some type of help is needed to solve this problem. Regards El Vie, 28 de Diciembre de 2007, 9:48, ArcosCom Linux User escribi?: > Hi, I'm having problems in an old PC with 2 S3 video devices. > > Sorry for the long e-mail, but here is all the config files and log files > output. > > The X's start fine, and gnome too. I have the 2 screens working fine, but > when I launch some programs, the xserver restart without any type of > screen message. > > I don't know what is the problem, because VNC extension works fine, > screen0 runs fine at 800x600 and screen1 runs fine at 1024x768. > > The 2 video devices uses the same driver s3virge. The first is a PCI (the > principal screen) and the second is an AGP device (the secondary screen). > > Could anyone help me in diagnose and solve this problem? > > Thanks!! > > ========================================================== > lspci output: > > 00:08.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) > (prog-if 00 [VGA]) > Subsystem: S3 Inc. ViRGE/DX > Flags: bus master, medium devsel, latency 32, IRQ 10 > Memory at d8000000 (32-bit, non-prefetchable) [size=64M] > [virtual] Expansion ROM at 30120000 [disabled] [size=64K] > 01:00.0 VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 02) > (prog-if 00 [VGA]) > Subsystem: S3 Inc. Trio3D/2X > Flags: bus master, medium devsel, latency 32 > Memory at d0000000 (32-bit, non-prefetchable) [size=64M] > Expansion ROM at 30000000 [disabled] [size=64K] > Capabilities: [dc] Power Management version 1 > Capabilities: [80] AGP version 1.0 > ================================================================= > This is the xorg.conf file content: > Section "ServerLayout" > Identifier "Multihead layout" > Screen 0 "Screen0" LeftOf "Screen1" > Screen 1 "Screen1" 0 0 > InputDevice "Keyboard0" "CoreKeyboard" > Option "Xinerama" "off" > Option "Clone" "on" > EndSection > > Section "Module" > Load "vnc" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbModel" "pc105" > Option "XkbLayout" "es" > EndSection > > Section "Monitor" > Identifier "Monitor1" > VendorName "Monitor Vendor" > ModelName "Monitor 1024x768" > HorizSync 31.5 - 80.0 > VertRefresh 30.0 - 100.0 > Option "dpms" > EndSection > > Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName "Monitor 1024x768" > HorizSync 31.5 - 80.0 > VertRefresh 30.0 - 100.0 > Option "dpms" > EndSection > > Section "Device" > Identifier "Videocard0" > Driver "s3virge" > VendorName "Videocard Vendor" > BoardName "S3 Inc. ViRGE/DX or /GX" > BusID "PCI:0:8:0" > Option "pci_burst" "on" > Option "pci_retry" "on" > EndSection > > Section "Device" > Identifier "Videocard1" > Driver "s3virge" > VendorName "Videocard Vendor" > BoardName "S3 Inc. 86c368 [Trio 3D/2X]" > BusID "PCI:1:0:0" > Option "pci_burst" "on" > Option "pci_retry" "on" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > Monitor "Monitor0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Modes "1024x768" "800x600" > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > Modes "1024x768" "800x600" > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > Modes "1024x768" "800x600" > EndSubSection > Option "UserPasswdVerifier" "VncAuth" > Option "PasswordFile" "/root/.vnc/passwd" > Option "httpd" "/usr/share/vnc/classes/" > Option "ClientWaitTimeMillis" "300000" > Option "deferUpdate" "100" > Option "DisconnectClients" "off" > Option "AllwaysShared" "on" > Option "IdleTimeout" "300" > Option "desktop" "screen0" > EndSection > > Section "Screen" > Identifier "Screen1" > Device "Videocard1" > Monitor "Monitor1" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 16 > Modes "1024x768" "800x600" > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > Modes "1024x768" "800x600" > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > Modes "1024x768" "800x600" > EndSubSection > Option "UserPasswdVerifier" "VncAuth" > Option "PasswordFile" "/root/.vnc/passwd" > Option "httpd" "/usr/share/vnc/classes/" > Option "ClientWaitTimeMillis" "300000" > Option "deferUpdate" "100" > Option "DisconnectClients" "off" > Option "AllwaysShared" "on" > Option "IdleTimeout" "300" > Option "desktop" "screen1" > EndSection > ============================================================= > This is the Xorg.0.log.old output: > > X Window System Version 7.1.1 > Release Date: 12 May 2006 > X Protocol Version 11, Revision 0, Release 7.1.1 > Build Operating System: Linux 2.6.9-42.0.3.ELsmp i686 Red Hat, Inc. > Current Operating System: Linux acpc08.arcoscom > 2.6.18-53.1.4.1.el5_ArcosCom #1 SMP Wed Dec 5 08:29:14 CET 2007 i686 > Build Date: 10 November 2007 > Build ID: xorg-x11-server 1.1.1-48.26.el5 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Module Loader present > 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: Thu Dec 27 09:56:31 2007 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "Multihead layout" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Videocard0" > (**) |-->Screen "Screen1" (1) > (**) | |-->Monitor "Monitor1" > (**) | |-->Device "Videocard1" > (**) |-->Input Device "Keyboard0" > (==) |-->Input Device "" > (==) The core pointer device wasn't specified explicitly in the layout. > Using the default mouse configuration. > (==) No FontPath specified. Using compiled-in default. > (==) FontPath set to: > unix/:7100, > built-ins > (==) RgbPath set to "/usr/share/X11/rgb" > (==) ModulePath set to "/usr/lib/xorg/modules" > (**) Option "Xinerama" "off" > (II) Open ACPI successful (/var/run/acpid.socket) > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.3 > X.Org Video Driver: 1.0 > X.Org XInput driver : 0.6 > X.Org Server Extension : 0.3 > X.Org Font Renderer : 0.5 > (II) Loader running on linux > (II) LoadModule: "bitmap" > (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so > (II) Module bitmap: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > Module class: X.Org Font Renderer > ABI class: X.Org Font Renderer, version 0.5 > (II) Loading font Bitmap > (II) LoadModule: "pcidata" > (II) Loading /usr/lib/xorg/modules/libpcidata.so > (II) Module pcidata: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (++) using VT number 7 > > (II) PCI: PCI scan (all values are in hex) > (II) PCI: 00:00:0: chip 1106,0691 card 0000,0000 rev c4 class 06,00,00 hdr > 00 > (II) PCI: 00:01:0: chip 1106,8598 card 0000,0000 rev 00 class 06,04,00 hdr > 01 > (II) PCI: 00:07:0: chip 1106,0686 card 1106,0000 rev 40 class 06,01,00 hdr > 80 > (II) PCI: 00:07:1: chip 1106,0571 card 0000,0000 rev 06 class 01,01,8a hdr > 00 > (II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr > 00 > (II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr > 00 > (II) PCI: 00:07:4: chip 1106,3057 card 0000,0000 rev 40 class 06,00,00 hdr > 00 > (II) PCI: 00:08:0: chip 5333,8a01 card 5333,8a01 rev 01 class 03,00,00 hdr > 00 > (II) PCI: 00:09:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00 hdr > 00 > (II) PCI: 00:0a:0: chip 10b7,9055 card 10b7,9055 rev 24 class 02,00,00 hdr > 00 > (II) PCI: 01:00:0: chip 5333,8a13 card 5333,8a13 rev 02 class 03,00,00 hdr > 00 > (II) PCI: End of PCI scan > (II) Host-to-PCI bridge: > (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) > (II) Bus 0 I/O range: > [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] > (II) Bus 0 non-prefetchable memory range: > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > (II) Bus 0 prefetchable memory range: > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > (II) PCI-to-PCI bridge: > (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0004 (VGA_EN is > cleared) > (II) Bus 1 non-prefetchable memory range: > [0] -1 0 0xd0000000 - 0xd7ffffff (0x8000000) MX[B] > (II) Bus 1 prefetchable memory range: > [0] -1 0 0x30000000 - 0x300fffff (0x100000) MX[B] > (II) PCI-to-ISA bridge: > (II) Bus -1: bridge is at (0:7:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is > set) > (--) PCI:*(0:8:0) S3 Inc. ViRGE/DX or /GX rev 1, Mem @ 0xd8000000/26 > (--) PCI: (1:0:0) S3 Inc. 86c368 [Trio 3D/2X] rev 2, Mem @ 0xd0000000/26 > (II) Addressable bus resource ranges are > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] > (II) OS-reported resource ranges: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) PCI Memory resource overlap reduced 0xdd000000 from 0xdd7fffff to > 0xdcffffff > (II) Active PCI resource ranges: > [0] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [1] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [2] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [3] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [4] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [5] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [6] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [7] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > (II) Inactive PCI resource ranges: > [0] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > (II) Active PCI resource ranges after removing overlaps: > [0] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [1] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [2] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [3] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [4] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [5] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [6] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [7] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > (II) Inactive PCI resource ranges after removing overlaps: > [0] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > (II) OS-reported resource ranges after removing overlaps with PCI: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) All system resource ranges: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > (II) LoadModule: "vnc" > (II) Loading /usr/lib/xorg/modules/extensions/libvnc.so > (II) Module vnc: vendor="RealVNC Ltd" > compiled for 4.3.99.902, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 0.3 > (II) Loading extension VNC > (II) LoadModule: "s3virge" > (II) Loading /usr/lib/xorg/modules/drivers/s3virge_drv.so > (II) Module s3virge: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.9.1 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 1.0 > (II) LoadModule: "kbd" > (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so > (II) Module kbd: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.1.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 0.6 > (II) LoadModule: "mouse" > (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so > (II) Module mouse: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.1.1 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 0.6 > (II) S3VIRGE: driver (version 1.9.1) for S3 ViRGE chipsets: virge, 86C325, > virge vx, 86C988, virge dx, virge gx, 86C375, 86C385, virge gx2, > 86C357, virge mx, 86C260, virge mx+, 86C280, trio 3d, 86C365, > trio 3d/2x, 86C362, 86C368 > (II) Primary Device is: PCI 00:08:0 > (--) Chipset virge dx found > (--) Chipset trio 3d/2x found > (II) resource ranges after xf86ClaimFixedResources() call: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > (II) resource ranges after xf86ClaimFixedResources() call: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [10] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [11] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [12] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [13] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [14] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > (II) resource ranges after probing: > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [4] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [5] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [6] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > [8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [11] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [12] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [13] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [16] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [17] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [18] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [19] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [20] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > [21] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [22] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > [23] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [24] 1 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) Setting vga for screen 1. > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/lib/xorg/modules/libvgahw.so > (II) Module vgahw: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 0.1.0 > ABI class: X.Org Video Driver, version 1.0 > (**) S3VIRGE(0): Depth 24, (--) framebuffer bpp 24 > (==) S3VIRGE(0): RGB weight 888 > (==) S3VIRGE(0): Default visual is TrueColor > (**) S3VIRGE(0): Option "pci_burst" "on" > (**) S3VIRGE(0): Option "pci_retry" "on" > (**) S3VIRGE(0): Option: pci_burst - PCI burst read enabled > (**) S3VIRGE(0): Option: pci_retry > (==) S3VIRGE(0): Using HW Cursor > (==) S3VIRGE(0): Using fb. > (==) S3VIRGE(0): mx_cr3a_fix. > (II) Loading sub module "vbe" > (II) LoadModule: "vbe" > (II) Loading /usr/lib/xorg/modules/libvbe.so > (II) Module vbe: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.1.0 > ABI class: X.Org Video Driver, version 1.0 > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Loading /usr/lib/xorg/modules/libint10.so > (II) Module int10: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (II) S3VIRGE(0): initializing int10 > (II) S3VIRGE(0): Primary V_BIOS segment is: 0xc000 > (II) S3VIRGE(0): VESA BIOS detected > (II) S3VIRGE(0): VESA VBE Version 1.2 > (II) S3VIRGE(0): VESA VBE Total Mem: 2048 kB > (II) S3VIRGE(0): VESA VBE OEM: S3 Incorporated. 86C375/86C385 > (--) S3VIRGE(0): Chipset: "virge dx" > (==) S3VIRGE(0): XVideo supported. > (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Loading /usr/lib/xorg/modules/libddc.so > (II) Module ddc: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (--) S3VIRGE(0): No DDC signal > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Loading /usr/lib/xorg/modules/libi2c.so > (II) Module i2c: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.2.0 > ABI class: X.Org Video Driver, version 1.0 > (II) S3VIRGE(0): I2C bus "I2C bus" initialized. > (II) S3VIRGE(0): I2C device "I2C bus:ddc2" registered at address 0xA0. > (II) S3VIRGE(0): I2C device "I2C bus:ddc2" removed. > (==) S3VIRGE(0): Using gamma correction (1.0, 1.0, 1.0) > (--) S3VIRGE(0): videoram: 2048k > (--) S3VIRGE(0): Detected current MCLK value of 45.102 MHz > (II) S3VIRGE(0): Monitor0: Using hsync range of 31.50-80.00 kHz > (II) S3VIRGE(0): Monitor0: Using vrefresh range of 30.00-100.00 Hz > (II) S3VIRGE(0): Clock range: 10.00 to 270.00 MHz > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x960" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x960" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "640x480" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x1024" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "640x512" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1792x1344" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "896x672" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1792x1344" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "896x672" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1856x1392" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "928x696" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1856x1392" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "928x696" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1152x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1152x864" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "576x432" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x720" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1440x900" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1600x1024" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "840x525" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "840x525" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x540" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x540" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1024x768" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using default mode "1280x800" (insufficient memory > for mode) > (II) S3VIRGE(0): Not using mode "1024x768" (no mode of this name) > (II) S3VIRGE(0): Not using default mode "960x600" (width too large for > virtual size) > (II) S3VIRGE(0): Not using default mode "832x624" (width too large for > virtual size) > (II) S3VIRGE(0): Not using default mode "960x540" (width too large for > virtual size) > (II) S3VIRGE(0): Not using default mode "960x540" (width too large for > virtual size) > (II) S3VIRGE(0): Not using default mode "840x525" (width too large for > virtual size) > (II) S3VIRGE(0): Not using default mode "840x525" (width too large for > virtual size) > (--) S3VIRGE(0): Virtual size is 800x600 (pitch 800) > (**) S3VIRGE(0): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz > (II) S3VIRGE(0): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 > 631 +hsync +vsync > (**) S3VIRGE(0): Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz > (II) S3VIRGE(0): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync > (**) S3VIRGE(0): Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz > (II) S3VIRGE(0): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 > 666 +hsync +vsync > (**) S3VIRGE(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz > (II) S3VIRGE(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync > (**) S3VIRGE(0): Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 > 625 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz > (II) S3VIRGE(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 > 625 +hsync +vsync > (**) S3VIRGE(0): Default mode "700x525": 72.5 MHz, 76.5 kHz, 70.1 Hz (D) > (II) S3VIRGE(0): Modeline "700x525" 72.53 700 748 824 948 525 525 527 > 546 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(0): Modeline "700x525" 75.50 700 732 828 980 525 525 527 > 550 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "700x525" 61.00 700 744 820 940 525 526 532 > 541 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x512" 67.50 640 648 720 844 512 512 514 > 533 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x512" 54.00 640 664 720 844 512 512 514 > 533 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "720x450": 53.2 MHz, 55.9 kHz, 59.9 Hz (D) > (II) S3VIRGE(0): Modeline "720x450" 53.25 720 760 836 952 450 451 454 > 467 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz > (II) S3VIRGE(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 > 509 -hsync -vsync > (**) S3VIRGE(0): Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz > (II) S3VIRGE(0): Modeline "640x480" 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync > (**) S3VIRGE(0): Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz > (II) S3VIRGE(0): Modeline "640x480" 31.50 640 664 704 832 480 489 491 > 520 -hsync -vsync > (**) S3VIRGE(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz > (II) S3VIRGE(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492 > 525 -hsync -vsync > (**) S3VIRGE(0): Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x480" 54.00 640 688 744 900 480 480 482 > 500 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz > (II) S3VIRGE(0): Modeline "720x400" 35.50 720 756 828 936 400 401 404 > 446 -hsync +vsync > (**) S3VIRGE(0): Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz > (II) S3VIRGE(0): Modeline "640x400" 31.50 640 672 736 832 400 401 404 > 445 -hsync +vsync > (**) S3VIRGE(0): Default mode "640x400": 61.7 MHz, 71.4 kHz, 85.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x400" 61.69 640 684 752 864 400 400 402 > 420 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x400": 53.6 MHz, 62.6 kHz, 75.1 Hz (D) > (II) S3VIRGE(0): Modeline "640x400" 53.60 640 680 748 856 400 400 402 > 417 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x400": 49.4 MHz, 58.3 kHz, 70.1 Hz (D) > (II) S3VIRGE(0): Modeline "640x400" 49.45 640 676 744 848 400 400 402 > 416 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x400": 41.7 MHz, 49.7 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x400" 41.73 640 672 740 840 400 400 402 > 414 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 60.75 576 608 672 784 432 432 434 > 455 doublescan +hsync -vsync > (**) S3VIRGE(0): Default mode "576x432": 59.8 MHz, 77.1 kHz, 85.1 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 59.83 576 612 676 776 432 432 434 > 453 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 54.00 576 608 672 800 432 432 434 > 450 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "576x432": 52.5 MHz, 67.6 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 52.49 576 612 676 776 432 432 434 > 451 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "576x432": 48.4 MHz, 63.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 48.38 576 612 672 768 432 432 434 > 450 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "576x432": 40.8 MHz, 53.7 kHz, 60.1 Hz (D) > (II) S3VIRGE(0): Modeline "576x432" 40.81 576 608 668 760 432 432 434 > 447 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x384": 59.3 MHz, 68.6 kHz, 85.1 Hz (D) > (II) S3VIRGE(0): Modeline "640x384" 59.27 640 684 752 864 384 384 386 > 403 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x384": 51.5 MHz, 60.2 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x384" 51.49 640 680 748 856 384 384 386 > 401 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x384": 47.5 MHz, 56.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x384" 47.49 640 676 744 848 384 384 386 > 400 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x384": 40.1 MHz, 47.7 kHz, 60.1 Hz (D) > (II) S3VIRGE(0): Modeline "640x384" 40.07 640 672 740 840 384 384 386 > 397 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x360": 55.0 MHz, 64.3 kHz, 85.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x360" 55.01 640 680 748 856 360 360 362 > 378 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x360": 47.8 MHz, 56.4 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x360" 47.83 640 676 744 848 360 360 362 > 376 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x360": 44.5 MHz, 52.5 kHz, 70.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x360" 44.52 640 676 744 848 360 360 362 > 375 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x360": 37.2 MHz, 44.8 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "640x360" 37.24 640 668 736 832 360 360 362 > 373 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz > (II) S3VIRGE(0): Modeline "640x350" 31.50 640 672 736 832 350 382 385 > 445 +hsync -vsync > (**) S3VIRGE(0): Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) > (II) S3VIRGE(0): Modeline "576x384" 32.50 576 589 657 736 384 385 388 > 403 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) > (II) S3VIRGE(0): Modeline "512x384" 47.25 512 536 584 688 384 384 386 > 404 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) > (II) S3VIRGE(0): Modeline "512x384" 39.40 512 520 568 656 384 384 386 > 400 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) > (II) S3VIRGE(0): Modeline "512x384" 37.50 512 524 592 664 384 385 388 > 403 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) > (II) S3VIRGE(0): Modeline "512x384" 32.50 512 524 592 672 384 385 388 > 403 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "512x384": 22.4 MHz, 35.5 kHz, 86.6 Hz (D) > (II) S3VIRGE(0): Modeline "512x384" 22.45 512 516 604 632 384 384 388 > 409 interlace doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) > (II) S3VIRGE(0): Modeline "416x312" 28.64 416 432 464 576 312 312 314 > 333 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) > (II) S3VIRGE(0): Modeline "400x300" 28.15 400 416 448 524 300 300 302 > 315 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) > (II) S3VIRGE(0): Modeline "400x300" 24.75 400 408 448 528 300 300 302 > 312 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) > (II) S3VIRGE(0): Modeline "400x300" 25.00 400 428 488 520 300 318 321 > 333 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) > (II) S3VIRGE(0): Modeline "400x300" 20.00 400 420 484 528 300 300 302 > 314 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) > (II) S3VIRGE(0): Modeline "400x300" 18.00 400 412 448 512 300 300 301 > 312 doublescan +hsync +vsync > (**) S3VIRGE(0): Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) > (II) S3VIRGE(0): Modeline "320x240" 18.00 320 348 376 416 240 240 242 > 254 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) > (II) S3VIRGE(0): Modeline "320x240" 15.75 320 328 360 420 240 240 242 > 250 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) > (II) S3VIRGE(0): Modeline "320x240" 15.75 320 332 352 416 240 244 245 > 260 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) > (II) S3VIRGE(0): Modeline "320x240" 12.60 320 328 376 400 240 245 246 > 262 doublescan -hsync -vsync > (**) S3VIRGE(0): Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) > (II) S3VIRGE(0): Modeline "360x200" 17.75 360 378 414 468 200 200 202 > 223 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) > (II) S3VIRGE(0): Modeline "320x200" 15.75 320 336 368 416 200 200 202 > 222 doublescan -hsync +vsync > (**) S3VIRGE(0): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) > (II) S3VIRGE(0): Modeline "320x175" 15.75 320 336 368 416 175 191 192 > 222 doublescan +hsync -vsync > (==) S3VIRGE(0): DPI set to (75, 75) > (II) Loading sub module "fb" > (II) LoadModule: "fb" > (II) Loading /usr/lib/xorg/modules/libfb.so > (II) Module fb: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.3 > (II) Loading sub module "xaa" > (II) LoadModule: "xaa" > (II) Loading /usr/lib/xorg/modules/libxaa.so > (II) Module xaa: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.2.0 > ABI class: X.Org Video Driver, version 1.0 > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Loading /usr/lib/xorg/modules/libramdac.so > (II) Module ramdac: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 0.1.0 > ABI class: X.Org Video Driver, version 1.0 > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Reloading /usr/lib/xorg/modules/libvgahw.so > (II) S3VIRGE(1): Creating default Display subsection in Screen section > "Screen1" for depth/fbbpp 24/24 > (**) S3VIRGE(1): Depth 24, (--) framebuffer bpp 24 > (==) S3VIRGE(1): RGB weight 888 > (==) S3VIRGE(1): Default visual is TrueColor > (**) S3VIRGE(1): Option "pci_burst" "on" > (**) S3VIRGE(1): Option "pci_retry" "on" > (**) S3VIRGE(1): Option: pci_burst - PCI burst read enabled > (**) S3VIRGE(1): Option: pci_retry > (==) S3VIRGE(1): Using HW Cursor > (==) S3VIRGE(1): Using fb. > (==) S3VIRGE(1): mx_cr3a_fix. > (II) Loading sub module "vbe" > (II) LoadModule: "vbe" > (II) Reloading /usr/lib/xorg/modules/libvbe.so > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Reloading /usr/lib/xorg/modules/libint10.so > (II) S3VIRGE(1): initializing int10 > (II) Attempted to read BIOS 64KB from > /sys/bus/pci/devices/0000:01:00.0/rom: got 32KB > (II) S3VIRGE(1): VESA BIOS detected > (II) S3VIRGE(1): VESA VBE Version 2.0 > (II) S3VIRGE(1): VESA VBE Total Mem: 4096 kB > (II) S3VIRGE(1): VESA VBE OEM: S3 Incorporated. 86C362 > (II) S3VIRGE(1): VESA VBE OEM Software Rev: 1.1 > (II) S3VIRGE(1): VESA VBE OEM Vendor: S3 Incorporated. > (II) S3VIRGE(1): VESA VBE OEM Product: Trio3D/2X > (II) S3VIRGE(1): VESA VBE OEM Product Rev: Rev C > (--) S3VIRGE(1): Chipset: "trio 3d/2x" > (==) S3VIRGE(1): XVideo supported. > (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Reloading /usr/lib/xorg/modules/libddc.so > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Reloading /usr/lib/xorg/modules/libddc.so > (II) S3VIRGE(1): VESA VBE DDC supported > (II) S3VIRGE(1): VESA VBE DDC Level 2 > (II) S3VIRGE(1): VESA VBE DDC transfer in appr. 1 sec. > (II) S3VIRGE(1): VESA VBE DDC read successfully > (II) S3VIRGE(1): Manufacturer: TAT Model: 31d7 Serial#: 630247 > (II) S3VIRGE(1): Year: 2001 Week: 52 > (II) S3VIRGE(1): EDID Version: 1.3 > (II) S3VIRGE(1): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) S3VIRGE(1): Sync: Separate > (II) S3VIRGE(1): Max H-Image Size [cm]: horiz.: 32 vert.: 24 > (II) S3VIRGE(1): Gamma: 2.77 > (II) S3VIRGE(1): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) S3VIRGE(1): First detailed timing is preferred mode > (II) S3VIRGE(1): redX: 0.630 redY: 0.340 greenX: 0.280 greenY: 0.601 > (II) S3VIRGE(1): blueX: 0.145 blueY: 0.061 whiteX: 0.281 whiteY: 0.311 > (II) S3VIRGE(1): Supported VESA Video Modes: > (II) S3VIRGE(1): 720x400 at 70Hz > (II) S3VIRGE(1): 640x480 at 60Hz > (II) S3VIRGE(1): 640x480 at 75Hz > (II) S3VIRGE(1): 800x600 at 60Hz > (II) S3VIRGE(1): 800x600 at 75Hz > (II) S3VIRGE(1): 1024x768 at 60Hz > (II) S3VIRGE(1): 1024x768 at 70Hz > (II) S3VIRGE(1): 1024x768 at 75Hz > (II) S3VIRGE(1): Manufacturer's mask: 0 > (II) S3VIRGE(1): Supported Future Video Modes: > (II) S3VIRGE(1): #0: hsize: 640 vsize 480 refresh: 85 vid: 22833 > (II) S3VIRGE(1): #1: hsize: 800 vsize 600 refresh: 85 vid: 22853 > (II) S3VIRGE(1): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 > (II) S3VIRGE(1): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) S3VIRGE(1): Supported additional Video Mode: > (II) S3VIRGE(1): clock: 94.5 MHz Image Size: 306 x 230 mm > (II) S3VIRGE(1): h_active: 1024 h_sync: 1072 h_sync_end 1168 h_blank_end > 1376 h_border: 0 > (II) S3VIRGE(1): v_active: 768 v_sync: 769 v_sync_end 772 v_blanking: > 808 v_border: 0 > (II) S3VIRGE(1): Ranges: V min: 50 V max: 120 Hz, H min: 30 H max: 70 > kHz, > (II) S3VIRGE(1): Serial No: 80H152630247 > (II) S3VIRGE(1): Monitor name: TATUNG C7ES > (II) S3VIRGE(1): EDID (in hex): > (II) S3VIRGE(1): 00ffffffffffff005034d731e79d0900 > (II) S3VIRGE(1): 340b0103682018b1ea4f22a157479925 > (II) S3VIRGE(1): 0f484fa54e0031594559615981800101 > (II) S3VIRGE(1): 010101010101ea240060410028303060 > (II) S3VIRGE(1): 130032e61000001e000000fd0032781e > (II) S3VIRGE(1): 46ff000a202020202020000000ff0038 > (II) S3VIRGE(1): 30483135323633303234370a000000fc > (II) S3VIRGE(1): 00544154554e4720433745530a200007 > (II) S3VIRGE(1): Using hsync ranges from config file > (II) S3VIRGE(1): Using vrefresh ranges from config file > (II) S3VIRGE(1): Printing DDC gathered Modelines: > (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync > (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync > (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 > 525 -hsync -vsync > (II) S3VIRGE(1): Modeline "720x400" 28.32 720 738 846 900 400 412 414 > 449 -hsync +vsync > (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync > (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 > 777 806 -hsync -vsync > (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 > 777 806 -hsync -vsync > (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync > (II) S3VIRGE(1): Modeline "640x480" 35.00 640 664 728 816 480 483 487 > 507 -hsync +vsync > (II) S3VIRGE(1): Modeline "800x600" 56.75 800 848 928 1056 600 603 607 > 633 -hsync +vsync > (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1096 1200 1376 768 771 > 775 809 -hsync +vsync > (II) S3VIRGE(1): Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 > 1027 1034 1063 -hsync +vsync > (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 > 772 808 +hsync +vsync > (==) S3VIRGE(1): Using gamma correction (1.0, 1.0, 1.0) > (--) S3VIRGE(1): videoram: 4096k > (--) S3VIRGE(1): Detected current MCLK value of 100.227 MHz > (II) S3VIRGE(1): Monitor1: Using hsync range of 31.50-80.00 kHz > (II) S3VIRGE(1): Monitor1: Using vrefresh range of 30.00-100.00 Hz > (II) S3VIRGE(1): Estimated virtual size for aspect ratio 1.3333 is > 1024x768 > (II) S3VIRGE(1): Clock range: 10.00 to 270.00 MHz > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x960" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x960" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "640x480" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x1024" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "640x512" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1600x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "800x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1792x1344" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "896x672" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1792x1344" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "896x672" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1856x1392" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "928x696" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1856x1392" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "928x696" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1152x768" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1152x864" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "576x432" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x720" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1280x768" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1400x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "700x525" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1440x900" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "1600x1024" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "840x525" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1680x1050" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "840x525" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x540" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1080" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x540" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1200" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x600" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "1920x1440" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "960x720" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "2048x1536" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1024x768" (hsync out of range) > (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using default mode "2560x1600" (insufficient memory > for mode) > (II) S3VIRGE(1): Not using default mode "1280x800" (width too large for > virtual size) > (II) S3VIRGE(1): Not using driver mode "1280x1024" (width too large for > virtual size) > (--) S3VIRGE(1): Virtual size is 1024x768 (pitch 1024) > (**) S3VIRGE(1): *Driver mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz > (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 > 772 808 +hsync +vsync > (**) S3VIRGE(1): *Driver mode "1024x768": 94.5 MHz, 68.7 kHz, 84.9 Hz > (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1096 1200 1376 768 771 > 775 809 -hsync +vsync > (**) S3VIRGE(1): *Driver mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz > (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync > (**) S3VIRGE(1): *Driver mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz > (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 > 777 806 -hsync -vsync > (**) S3VIRGE(1): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz > (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 > 777 806 -hsync -vsync > (**) S3VIRGE(1): *Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz > (II) S3VIRGE(1): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 > 772 808 +hsync +vsync > (**) S3VIRGE(1): *Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz > (II) S3VIRGE(1): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync > (**) S3VIRGE(1): *Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz > (II) S3VIRGE(1): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 > 777 806 -hsync -vsync > (**) S3VIRGE(1): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz > (II) S3VIRGE(1): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 > 777 806 -hsync -vsync > (**) S3VIRGE(1): *Default mode "1024x768": 44.9 MHz, 35.5 kHz, 86.9 Hz (I) > (II) S3VIRGE(1): Modeline "1024x768" 44.90 1024 1032 1208 1264 768 768 > 776 817 interlace +hsync +vsync > (**) S3VIRGE(1): *Default mode "960x600": 96.6 MHz, 74.5 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "960x600" 96.58 960 1024 1128 1296 600 600 > 602 621 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz > (II) S3VIRGE(1): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 > 667 -hsync -vsync > (**) S3VIRGE(1): *Default mode "960x540": 102.1 MHz, 78.8 kHz, 70.0 Hz (D) > (II) S3VIRGE(1): Modeline "960x540" 102.12 960 1028 1128 1296 540 541 > 544 563 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "960x540": 86.5 MHz, 67.2 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "960x540" 86.50 960 1024 1124 1288 540 541 > 544 560 doublescan -hsync +vsync > (**) S3VIRGE(1): *Driver mode "800x600": 56.8 MHz, 53.7 kHz, 84.9 Hz > (II) S3VIRGE(1): Modeline "800x600" 56.75 800 848 928 1056 600 603 607 > 633 -hsync +vsync > (**) S3VIRGE(1): *Driver mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz > (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync > (**) S3VIRGE(1): *Driver mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz > (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz > (II) S3VIRGE(1): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 > 631 +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz > (II) S3VIRGE(1): Modeline "800x600" 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz > (II) S3VIRGE(1): Modeline "800x600" 50.00 800 856 976 1040 600 637 643 > 666 +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz > (II) S3VIRGE(1): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "800x600" 81.00 800 832 928 1080 600 600 602 > 625 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz > (II) S3VIRGE(1): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 > 625 +hsync +vsync > (**) S3VIRGE(1): *Default mode "840x525": 87.0 MHz, 76.6 kHz, 69.9 Hz (D) > (II) S3VIRGE(1): Modeline "840x525" 87.00 840 900 988 1136 525 526 529 > 548 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "840x525": 73.1 MHz, 65.3 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "840x525" 73.12 840 892 980 1120 525 526 529 > 544 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "700x525": 72.5 MHz, 76.5 kHz, 70.1 Hz (D) > (II) S3VIRGE(1): Modeline "700x525" 72.53 700 748 824 948 525 525 527 > 546 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "700x525": 75.5 MHz, 77.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(1): Modeline "700x525" 75.50 700 732 828 980 525 525 527 > 550 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "700x525" 61.00 700 744 820 940 525 526 532 > 541 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "640x512": 67.5 MHz, 80.0 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x512" 67.50 640 648 720 844 512 512 514 > 533 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "640x512": 54.0 MHz, 64.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x512" 54.00 640 664 720 844 512 512 514 > 533 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "720x450": 53.2 MHz, 55.9 kHz, 59.9 Hz (D) > (II) S3VIRGE(1): Modeline "720x450" 53.25 720 760 836 952 450 451 454 > 467 doublescan -hsync +vsync > (**) S3VIRGE(1): *Driver mode "640x480": 35.0 MHz, 42.9 kHz, 84.6 Hz > (II) S3VIRGE(1): Modeline "640x480" 35.00 640 664 728 816 480 483 487 > 507 -hsync +vsync > (**) S3VIRGE(1): *Driver mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz > (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync > (**) S3VIRGE(1): *Driver mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz > (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 > 525 -hsync -vsync > (**) S3VIRGE(1): *Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz > (II) S3VIRGE(1): Modeline "640x480" 36.00 640 696 752 832 480 481 484 > 509 -hsync -vsync > (**) S3VIRGE(1): *Default mode "640x480": 31.5 MHz, 37.5 kHz, 75.0 Hz > (II) S3VIRGE(1): Modeline "640x480" 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync > (**) S3VIRGE(1): *Default mode "640x480": 31.5 MHz, 37.9 kHz, 72.8 Hz > (II) S3VIRGE(1): Modeline "640x480" 31.50 640 664 704 832 480 489 491 > 520 -hsync -vsync > (**) S3VIRGE(1): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz > (II) S3VIRGE(1): Modeline "640x480" 25.20 640 656 752 800 480 490 492 > 525 -hsync -vsync > (**) S3VIRGE(1): *Default mode "640x480": 54.0 MHz, 60.0 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x480" 54.00 640 688 744 900 480 480 482 > 500 doublescan +hsync +vsync > (**) S3VIRGE(1): *Driver mode "720x400": 28.3 MHz, 31.5 kHz, 70.1 Hz > (II) S3VIRGE(1): Modeline "720x400" 28.32 720 738 846 900 400 412 414 > 449 -hsync +vsync > (**) S3VIRGE(1): *Default mode "720x400": 35.5 MHz, 37.9 kHz, 85.0 Hz > (II) S3VIRGE(1): Modeline "720x400" 35.50 720 756 828 936 400 401 404 > 446 -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x400": 31.5 MHz, 37.9 kHz, 85.1 Hz > (II) S3VIRGE(1): Modeline "640x400" 31.50 640 672 736 832 400 401 404 > 445 -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x400": 61.7 MHz, 71.4 kHz, 85.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x400" 61.69 640 684 752 864 400 400 402 > 420 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x400": 53.6 MHz, 62.6 kHz, 75.1 Hz (D) > (II) S3VIRGE(1): Modeline "640x400" 53.60 640 680 748 856 400 400 402 > 417 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x400": 49.4 MHz, 58.3 kHz, 70.1 Hz (D) > (II) S3VIRGE(1): Modeline "640x400" 49.45 640 676 744 848 400 400 402 > 416 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x400": 41.7 MHz, 49.7 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x400" 41.73 640 672 740 840 400 400 402 > 414 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "576x432": 60.8 MHz, 77.5 kHz, 85.2 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 60.75 576 608 672 784 432 432 434 > 455 doublescan +hsync -vsync > (**) S3VIRGE(1): *Default mode "576x432": 59.8 MHz, 77.1 kHz, 85.1 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 59.83 576 612 676 776 432 432 434 > 453 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "576x432": 54.0 MHz, 67.5 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 54.00 576 608 672 800 432 432 434 > 450 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "576x432": 52.5 MHz, 67.6 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 52.49 576 612 676 776 432 432 434 > 451 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "576x432": 48.4 MHz, 63.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 48.38 576 612 672 768 432 432 434 > 450 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "576x432": 40.8 MHz, 53.7 kHz, 60.1 Hz (D) > (II) S3VIRGE(1): Modeline "576x432" 40.81 576 608 668 760 432 432 434 > 447 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x384": 59.3 MHz, 68.6 kHz, 85.1 Hz (D) > (II) S3VIRGE(1): Modeline "640x384" 59.27 640 684 752 864 384 384 386 > 403 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x384": 51.5 MHz, 60.2 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x384" 51.49 640 680 748 856 384 384 386 > 401 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x384": 47.5 MHz, 56.0 kHz, 70.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x384" 47.49 640 676 744 848 384 384 386 > 400 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x384": 40.1 MHz, 47.7 kHz, 60.1 Hz (D) > (II) S3VIRGE(1): Modeline "640x384" 40.07 640 672 740 840 384 384 386 > 397 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x360": 55.0 MHz, 64.3 kHz, 85.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x360" 55.01 640 680 748 856 360 360 362 > 378 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x360": 47.8 MHz, 56.4 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x360" 47.83 640 676 744 848 360 360 362 > 376 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x360": 44.5 MHz, 52.5 kHz, 70.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x360" 44.52 640 676 744 848 360 360 362 > 375 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x360": 37.2 MHz, 44.8 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "640x360" 37.24 640 668 736 832 360 360 362 > 373 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "640x350": 31.5 MHz, 37.9 kHz, 85.1 Hz > (II) S3VIRGE(1): Modeline "640x350" 31.50 640 672 736 832 350 382 385 > 445 +hsync -vsync > (**) S3VIRGE(1): *Default mode "576x384": 32.5 MHz, 44.2 kHz, 54.8 Hz (D) > (II) S3VIRGE(1): Modeline "576x384" 32.50 576 589 657 736 384 385 388 > 403 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "512x384": 47.2 MHz, 68.7 kHz, 85.0 Hz (D) > (II) S3VIRGE(1): Modeline "512x384" 47.25 512 536 584 688 384 384 386 > 404 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "512x384": 39.4 MHz, 60.1 kHz, 75.1 Hz (D) > (II) S3VIRGE(1): Modeline "512x384" 39.40 512 520 568 656 384 384 386 > 400 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "512x384": 37.5 MHz, 56.5 kHz, 70.1 Hz (D) > (II) S3VIRGE(1): Modeline "512x384" 37.50 512 524 592 664 384 385 388 > 403 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) > (II) S3VIRGE(1): Modeline "512x384" 32.50 512 524 592 672 384 385 388 > 403 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "512x384": 22.4 MHz, 35.5 kHz, 86.6 Hz (D) > (II) S3VIRGE(1): Modeline "512x384" 22.45 512 516 604 632 384 384 388 > 409 interlace doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "416x312": 28.6 MHz, 49.7 kHz, 74.7 Hz (D) > (II) S3VIRGE(1): Modeline "416x312" 28.64 416 432 464 576 312 312 314 > 333 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "400x300": 28.1 MHz, 53.7 kHz, 85.3 Hz (D) > (II) S3VIRGE(1): Modeline "400x300" 28.15 400 416 448 524 300 300 302 > 315 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "400x300": 24.8 MHz, 46.9 kHz, 75.1 Hz (D) > (II) S3VIRGE(1): Modeline "400x300" 24.75 400 408 448 528 300 300 302 > 312 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "400x300": 25.0 MHz, 48.1 kHz, 72.2 Hz (D) > (II) S3VIRGE(1): Modeline "400x300" 25.00 400 428 488 520 300 318 321 > 333 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) > (II) S3VIRGE(1): Modeline "400x300" 20.00 400 420 484 528 300 300 302 > 314 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) > (II) S3VIRGE(1): Modeline "400x300" 18.00 400 412 448 512 300 300 301 > 312 doublescan +hsync +vsync > (**) S3VIRGE(1): *Default mode "320x240": 18.0 MHz, 43.3 kHz, 85.2 Hz (D) > (II) S3VIRGE(1): Modeline "320x240" 18.00 320 348 376 416 240 240 242 > 254 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "320x240": 15.8 MHz, 37.5 kHz, 75.0 Hz (D) > (II) S3VIRGE(1): Modeline "320x240" 15.75 320 328 360 420 240 240 242 > 250 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "320x240": 15.8 MHz, 37.9 kHz, 72.8 Hz (D) > (II) S3VIRGE(1): Modeline "320x240" 15.75 320 332 352 416 240 244 245 > 260 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) > (II) S3VIRGE(1): Modeline "320x240" 12.60 320 328 376 400 240 245 246 > 262 doublescan -hsync -vsync > (**) S3VIRGE(1): *Default mode "360x200": 17.8 MHz, 37.9 kHz, 85.0 Hz (D) > (II) S3VIRGE(1): Modeline "360x200" 17.75 360 378 414 468 200 200 202 > 223 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "320x200": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) > (II) S3VIRGE(1): Modeline "320x200" 15.75 320 336 368 416 200 200 202 > 222 doublescan -hsync +vsync > (**) S3VIRGE(1): *Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D) > (II) S3VIRGE(1): Modeline "320x175" 15.75 320 336 368 416 175 191 192 > 222 doublescan +hsync -vsync > (**) S3VIRGE(1): Display dimensions: (320, 240) mm > (**) S3VIRGE(1): DPI set to (81, 81) > (II) Loading sub module "fb" > (II) LoadModule: "fb" > (II) Reloading /usr/lib/xorg/modules/libfb.so > (II) Loading sub module "xaa" > (II) LoadModule: "xaa" > (II) Reloading /usr/lib/xorg/modules/libxaa.so > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Reloading /usr/lib/xorg/modules/libramdac.so > (==) Depth 24 pixmap format is 32 bpp > (II) do I need RAC? Yes, I do. > (II) LoadModule: "rac" > (II) Loading /usr/lib/xorg/modules/librac.so > (II) Module rac: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (II) resource ranges after preInit: > [0] 1 0 0xd0000000 - 0xd3ffffff (0x4000000) MS[B] > [1] 0 0 0xd8000000 - 0xdbffffff (0x4000000) MS[B] > [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [6] -1 0 0xdd800000 - 0xdd80007f (0x80) MX[B] > [7] -1 0 0xdd000000 - 0xdcffffff (0x0) MX[B]O > [8] -1 0 0xd8000000 - 0xdbffffff (0x4000000) MX[B](B) > [9] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B) > [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) > [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) > [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) > [13] 1 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) > [14] 1 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) > [15] 1 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) > [16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [18] -1 0 0x0000e000 - 0x0000e07f (0x80) IX[B] > [19] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B] > [20] -1 0 0x0000d800 - 0x0000d81f (0x20) IX[B] > [21] -1 0 0x0000d400 - 0x0000d41f (0x20) IX[B] > [22] -1 0 0x0000d000 - 0x0000d00f (0x10) IX[B] > [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) > [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) > [25] 1 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) > [26] 1 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) > (==) S3VIRGE(0): Write-combining range (0xd8000000,0x200000) > (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (**) S3VIRGE(0): Using FB > (II) S3VIRGE(0): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > CPU to Screen color expansion > Solid Horizontal and Vertical Lines > Image Writes > Offscreen Pixmaps > Setting up tile and stipple cache: > 12 128x128 slots > (==) S3VIRGE(0): Backing store disabled > (==) S3VIRGE(0): Silken mouse enabled > (**) Option "dpms" > (**) S3VIRGE(0): DPMS enabled > (II) S3VIRGE(0): Using overlay video > (WW) S3VIRGE(0): Option "UserPasswdVerifier" is not used > (WW) S3VIRGE(0): Option "PasswordFile" is not used > (WW) S3VIRGE(0): Option "httpd" is not used > (WW) S3VIRGE(0): Option "ClientWaitTimeMillis" is not used > (WW) S3VIRGE(0): Option "deferUpdate" is not used > (WW) S3VIRGE(0): Option "DisconnectClients" is not used > (WW) S3VIRGE(0): Option "AllwaysShared" is not used > (WW) S3VIRGE(0): Option "IdleTimeout" is not used > (WW) S3VIRGE(0): Option "desktop" is not used > (==) RandR enabled > (==) S3VIRGE(1): Write-combining range (0xd0000000,0x400000) > (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (II) S3VIRGE(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (**) S3VIRGE(1): Using FB > (II) S3VIRGE(1): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > Solid Horizontal and Vertical Lines > Image Writes > Offscreen Pixmaps > Setting up tile and stipple cache: > 16 128x128 slots > 4 256x256 slots > (==) S3VIRGE(1): Backing store disabled > (==) S3VIRGE(1): Silken mouse enabled > (**) Option "dpms" > (**) S3VIRGE(1): DPMS enabled > (II) S3VIRGE(1): Using overlay video > (WW) S3VIRGE(1): Option "UserPasswdVerifier" is not used > (WW) S3VIRGE(1): Option "PasswordFile" is not used > (WW) S3VIRGE(1): Option "httpd" is not used > (WW) S3VIRGE(1): Option "ClientWaitTimeMillis" is not used > (WW) S3VIRGE(1): Option "deferUpdate" is not used > (WW) S3VIRGE(1): Option "DisconnectClients" is not used > (WW) S3VIRGE(1): Option "AllwaysShared" is not used > (WW) S3VIRGE(1): Option "IdleTimeout" is not used > (WW) S3VIRGE(1): Option "desktop" is not used > (==) RandR enabled > (II) Entity 0 shares no resources > (II) Entity 1 shares no resources > (II) Initializing built-in extension MIT-SHM > (II) Initializing built-in extension XInputExtension > (II) Initializing built-in extension XTEST > (II) Initializing built-in extension XKEYBOARD > (II) Initializing built-in extension XC-APPGROUP > (II) Initializing built-in extension SECURITY > (II) Initializing built-in extension XINERAMA > (II) Initializing built-in extension XFIXES > (II) Initializing built-in extension XFree86-Bigfont > (II) Initializing built-in extension RENDER > (II) Initializing built-in extension RANDR > (II) Initializing built-in extension COMPOSITE > (II) Initializing built-in extension DAMAGE > (II) Initializing built-in extension XEVIE > (**) Option "CoreKeyboard" > (**) Keyboard0: Core Keyboard > (**) Option "Protocol" "standard" > (**) Keyboard0: Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) Keyboard0: XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) Keyboard0: XkbModel: "pc105" > (**) Option "XkbLayout" "es" > (**) Keyboard0: XkbLayout: "es" > (**) Option "CustomKeycodes" "off" > (**) Keyboard0: CustomKeycodes disabled > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/input/mice" > (--) : Device: "/dev/input/mice" > (==) : Protocol: "Auto" > (**) Option "CorePointer" > (**) : Core Pointer > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (II) XINPUT: Adding extended input device "" (type: > MOUSE) > (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) > (--) : PnP-detected protocol: "ExplorerPS/2" > (II) : ps2EnableDataReporting: succeeded > > Backtrace: > 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e3fe1] > 1: [0x6ed420] > 2: /usr/lib/xorg/modules/libxaa.so(XAARemoveAreaCallback+0x17) [0x8f1ae7] > 3: /usr/lib/xorg/modules/libxaa.so [0x8d57bd] > 4: /usr/bin/Xorg [0x8104b19] > 5: /usr/bin/Xorg [0x815b577] > 6: /usr/bin/Xorg [0x8156810] > 7: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] > 8: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] > 9: /usr/bin/Xorg [0x815b6ff] > 10: /usr/bin/Xorg [0x8156810] > 11: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] > 12: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] > 13: /usr/bin/Xorg(ProcPolyFillRectangle+0xb6) [0x8084526] > 14: /usr/bin/Xorg(Dispatch+0x19a) [0x808811a] > 15: /usr/bin/Xorg(main+0x485) [0x806fa95] > 16: /lib/libc.so.6(__libc_start_main+0xdc) [0xb50dec] > 17: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e5) [0x806ed91] > > Fatal server error: > Caught signal 11. Server aborting > > (II) Screen 0 shares mem & io resources > (II) Screen 1 shares mem & io resources > ================================================================= > This is the /var/log/gdm/\:0.log.1: > > X Window System Version 7.1.1 > Release Date: 12 May 2006 > X Protocol Version 11, Revision 0, Release 7.1.1 > Build Operating System: Linux 2.6.9-42.0.3.ELsmp i686 Red Hat, Inc. > Current Operating System: Linux acpc08.arcoscom > 2.6.18-53.1.4.1.el5_ArcosCom #1 SMP Wed Dec 5 08:29:14 CET 2007 i686 > Build Date: 10 November 2007 > Build ID: xorg-x11-server 1.1.1-48.26.el5 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Module Loader present > 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: Thu Dec 27 09:56:31 2007 > (==) Using config file: "/etc/X11/xorg.conf" > > Thu Dec 27 09:56:36 2007 > vncext: VNC extension running! > vncext: Listening for VNC connections on port 5900 > vncext: Listening for HTTP connections on port 5800 > vncext: created VNC server for screen 0 > vncext: Listening for VNC connections on port 6900 > vncext: Listening for HTTP connections on port 6800 > vncext: created VNC server for screen 1 > > Backtrace: > 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e3fe1] > 1: [0x6ed420] > 2: /usr/lib/xorg/modules/libxaa.so(XAARemoveAreaCallback+0x17) [0x8f1ae7] > 3: /usr/lib/xorg/modules/libxaa.so [0x8d57bd] > 4: /usr/bin/Xorg [0x8104b19] > 5: /usr/bin/Xorg [0x815b577] > 6: /usr/bin/Xorg [0x8156810] > 7: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] > 8: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] > 9: /usr/bin/Xorg [0x815b6ff] > 10: /usr/bin/Xorg [0x8156810] > 11: /usr/lib/xorg/modules/extensions/libvnc.so [0x2cd32e] > 12: /usr/bin/Xorg(ValidateGC+0x25) [0x80961d5] > 13: /usr/bin/Xorg(ProcPolyFillRectangle+0xb6) [0x8084526] > 14: /usr/bin/Xorg(Dispatch+0x19a) [0x808811a] > 15: /usr/bin/Xorg(main+0x485) [0x806fa95] > 16: /lib/libc.so.6(__libc_start_main+0xdc) [0xb50dec] > 17: /usr/bin/Xorg(FontFileCompleteXLFD+0x1e5) [0x806ed91] > > Fatal server error: > Caught signal 11. Server aborting > > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From heavytull at hotmail.com Sun Dec 30 07:52:15 2007 From: heavytull at hotmail.com (Jethro Tull) Date: Sun, 30 Dec 2007 15:52:15 +0000 Subject: fglrx loading Message-ID: this is the output of dmesg when i try to load fglrx driver: [drm] Initialized drm 1.1.0 20060810 fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [fglrx] Maximum main memory to use for locked dma buffers: 1898 MBytes. [fglrx] ASYNCIO init succeed! [fglrx] PAT is enabled successfully! [fglrx:firegl_init_module] *ERROR* firegl_stub_register failed [fglrx] Maximum main memory to use for locked dma buffers: 1898 MBytes. [fglrx] ASYNCIO init succeed! [fglrx:KCL_enable_pat] *ERROR* Pat entry 2 is already configured [fglrx] PAT is disabled! [fglrx:firegl_init_module] *ERROR* firegl_stub_register failed i'm using slack12.0 and the latest version of the proprietary ATI drivers. my Gcard is an ATI Radeon Mobility X300 _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabio.corazza at gmail.com Sun Dec 30 08:25:50 2007 From: fabio.corazza at gmail.com (Fabio Corazza) Date: Sun, 30 Dec 2007 17:25:50 +0100 Subject: X3100 OpenGL incredibly slow and buggy on 2.2.0 Message-ID: Hi all, The title is quite meaningful: running xf86-video-intel 2.2.0, Mesa 7.0.1, not running compiz or any other sort of composite window manager, have Composite extension and AIGLX turned off (but it doesn't make any difference), I find OpenGL applications to be very slow. glxgears shows an average of 1100fps (this is what a GMA950 usually achieves). Tried etracer and got a maximum of 25fps in the high motion scenes. If I try to play videos using OpenGL output under VLC as soon as I resize the video X freezes leaving me with the only option to reboot the laptop. Google Earth after the login freezes the system (although I can still move the mouse) and even then, the only solution is to reboot. If I move the glxgears window while the gears are running, the motion inside the window gets corrupted and fps suddenly fall down to 300/400. Sometimes, it even freezes X and corrupt the whole screen (solution: reboot). Practically 3D acceleration is unusable. DRI is enabled, glxinfo shows nothing strange. I don't really don't know what to try anymore. The previous driver (2.1.1) showed the same issues. I'm forced to use XAA instead of the default EXA otherwise I couldn't see the fonts (guess this is an antialiasing related bug?). I don't really know what is wrong, acceleration is enabled but just unusable. I always thought Intel cards would excel under Linux due to the open drivers and having gone through this I'm simply baffled. Coming from an ATI card I originally thought the nightmare would have ended, but I see it's still chasing me.. Additionally, horizontal tearing on video when using Xv is very evident especially in the fast motion scenes. I've read a thread of almost 10 months ago when somebody reported the bug and Keith Packard suggested some possible future fix, but it looks like that hasn't been implemented yet. Textured Video should have improved things but the actual implementation of the driver under Linux works way worse than Overlay. Sorry if mine looks more a complaint rather than a constructive bug report, I know there many out there who volunteer their work and do their best to make drivers usable with no reward of any sort, but when it comes to Intel I would have expected more support from the manufacturer to produce better Linux drivers. If you have any idea to fix the above issues or you need more debugging to be done on my side I'd be more than glad to do so. Meanwhile I attach xorg.conf and Xorg.0.log if it can be of any help. Regards, Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 4645 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 34263 bytes Desc: not available URL: From jra at baylink.com Sun Dec 30 08:51:25 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 30 Dec 2007 11:51:25 -0500 Subject: Reminder to vote for Foundation Board In-Reply-To: <20071230092957.GA10850@suse.de> References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> <20071230064317.GB29629@cgi.jachomes.com> <20071230092957.GA10850@suse.de> Message-ID: <20071230165125.GD31172@cgi.jachomes.com> On Sun, Dec 30, 2007 at 10:29:58AM +0100, Stefan Dirsch wrote: > > WADR, this argument already got made... a month ago. Did it not? > > I'm not aware of the election period being mentioned anytime before > the announcement for itself on Fri Dec 21. Could you provide some > reference for your statement? Normally, I locally archive mailing lists, but xorg fell off that pile when I got short of space; I do believe, though, that we heard the "why is this such short notice" argument, when people simply didn't realize that it was *not* short notice, around the first of December. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From adamk at voicenet.com Sun Dec 30 08:56:58 2007 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Sun, 30 Dec 2007 11:56:58 -0500 Subject: fglrx loading In-Reply-To: References: Message-ID: <1199033818.11356.2.camel@thorn.ashke.com> Sorry, but problems with the fglrx drivers need to be taken up with ATI/AMD, not with this list :-) Adam On Sun, 2007-12-30 at 15:52 +0000, Jethro Tull wrote: > this is the output of dmesg when i try to load fglrx driver: > > [drm] Initialized drm 1.1.0 20060810 > fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, > Starnberg, GERMANY' taints kernel. > [fglrx] Maximum main memory to use for locked dma buffers: 1898 > MBytes. > [fglrx] ASYNCIO init succeed! > [fglrx] PAT is enabled successfully! > [fglrx:firegl_init_module] *ERROR* firegl_stub_register failed > [fglrx] Maximum main memory to use for locked dma buffers: 1898 > MBytes. > [fglrx] ASYNCIO init succeed! > [fglrx:KCL_enable_pat] *ERROR* Pat entry 2 is already configured > [fglrx] PAT is disabled! > [fglrx:firegl_init_module] *ERROR* firegl_stub_register failed > > > i'm using slack12.0 and the latest version of the proprietary ATI > drivers. > my Gcard is an ATI Radeon Mobility X300 > > > > ______________________________________________________________________ > Sounds like? How many syllables? Guess and win prizes with Search > Charades! > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From irwin at beluga.phys.uvic.ca Sun Dec 30 11:06:11 2007 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 30 Dec 2007 11:06:11 -0800 (PST) Subject: [xorg] X3100 OpenGL incredibly slow and buggy on 2.2.0 In-Reply-To: References: Message-ID: On 2007-12-30 17:25+0100 Fabio Corazza wrote: > Hi all, > > The title is quite meaningful: running xf86-video-intel 2.2.0, Mesa > 7.0.1, not running compiz or any other sort of composite window > manager, have Composite extension and AIGLX turned off (but it doesn't > make any difference), I find OpenGL applications to be very slow. > glxgears shows an average of 1100fps (this is what a GMA950 usually > achieves). [...] > If I move the glxgears window while the gears are running, the motion > inside the window gets corrupted and fps suddenly fall down to > 300/400. Sometimes, it even freezes X and corrupt the whole screen > (solution: reboot). > > Practically 3D acceleration is unusable. DRI is enabled, glxinfo shows > nothing strange. I don't really don't know what to try anymore. The > previous driver (2.1.1) showed the same issues. I'm forced to use XAA > instead of the default EXA otherwise I couldn't see the fonts (guess > this is an antialiasing related bug?). Hi Fabio: I also bought Intel recently motivated by reports and articles about how they are putting support into their x.org drivers. In contrast with your initial bad experience, my experience has been pretty good. I want to give some details here to (a) show the Intel story is not all bad, and (b) let you know there is probably hope for you since if support for my modern Intel hardware is good, then it substantially narrows down what might be wrong for your combination of hardware, software, and configuration. (1) Hardware: ASUS P5K-V, g33 chipset with no ADD2 card. According to http://en.wikipedia.org/wiki/Intel_GMA the g33 chipset includes the GMA 3100. What exact hardware do you have? Probably the GMA X3100 you have mentioned is all the information that is needed, but I am curious about the rest of your hardware information (MB, chipset, and any ADD2 cards). (2) Software: Both Debian testing (x.org 7.2, mesa 7.0.2, and xf86-video-intel 2.1.0) and Debian unstable (x.org 7.3, mesa 7.0.2, and patched xf86-video-intel 2.2.0) work well. The patch (the "Let PLLs settle longer" patch from https://bugs.freedesktop.org/show_bug.cgi?id=13196) for xf86-video-intel 2.2.0 is necessary to keep X from immediately freezing for me. My impression from comments made here is that xf86-video-intel 2.2.0 has been problematic for a number of users with different hardware, and Jesse Barnes has said they are planning release of an improved 2.2.1 within weeks. It's possible that new version might sort out the troubles for your own hardware. (3) Configuration: I use XAA, and haven't yet tried EXA. I had a lot of trouble with mode setting (since a lot of that is done differently now with randr-enabled drivers) until I found a combination that worked in my xorg.conf file. My working xorg.conf file and other detailed results are given at https://bugs.freedesktop.org/show_bug.cgi?id=13399. (4) Results: glxgears gives 2500 FPS. I tried moving and resizing it this morning after I saw your report above. There were absolutely no troubles with those operations. I haven't bothered with any 3D desktop eye-candy yet, and I don't run any high-level 3D games, but ppracer (aka tuxracer) and foobillard are absolutely reliable and give far superior 3D performance compared to the low-level video card (Matrox G200, does anybody still remember those?) I had on my previous box. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From leo.fontenelle at gmail.com Sun Dec 30 11:51:09 2007 From: leo.fontenelle at gmail.com (Leonardo Ferreira Fontenelle) Date: Sun, 30 Dec 2007 17:51:09 -0200 Subject: Does the intel driver support G35? Message-ID: <1199044269.8500.6.camel@localhost> I read the mailing list archives and the documentation in Git, but I couldn't understand if, and how well, is G35 supported. I'd like to buy a G35-based motherboard, but of course that will depend on the drivers. If current support is non-existent, or seriously broken, how long will it take until it is improved? (1 month? 1 year? ...) Thanks! Leonardo Fontenelle http://leonardof.org From arne.schmitz at gmx.net Sun Dec 30 12:15:01 2007 From: arne.schmitz at gmx.net (Arne Schmitz) Date: Sun, 30 Dec 2007 21:15:01 +0100 Subject: Stray pixels on 945GM/GMS/940GML Message-ID: <200712302115.05121.arne.schmitz@gmx.net> I am using X.org 1.3.0 on a Vaio UX1XN with an Intel 945 type chipset. I have a row of stray pixels on screen line 736 (counting from 0). This happens in dual head mode, but in single head mode I also have this, albeit on another line, since the internal display has only 600 lines. This line is annoying, since it destroys the rendering when I e.g. scroll a webpage. Is this a known problem? What could be the cause? Arne -- Dipl.-Inform. Arne Schmitz Phone +49 (0)241 80-21817 Computer Graphics Group Fax +49 (0)241 80-22899 RWTH Aachen University http://www.rwth-graphics.de Ahornstrasse 55, 52074 Aachen, Germany -------------- 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 newbury at mandamus.org Sun Dec 30 12:26:22 2007 From: newbury at mandamus.org (R. G. Newbury) Date: Sun, 30 Dec 2007 15:26:22 -0500 Subject: new 'xvmc' branch of intel video driver In-Reply-To: References: Message-ID: <4777FEEE.7010509@mandamus.org> Zhenyu Wang wrote: > > The aim of the new 'xvmc' branch is to deprecate origin > 'xvmc-i915' branch with lot of cleanups and new framework > inside driver to add supports for more hardware media decode > drivers in future. It also has changes that affect users. > > The most noteable is that the origin libI915XvMC.so is replaced > by a single libIntelXvMC.so entry to be used on different > chipsets for different hardware decoders. Although currently > there's only one decoder for MPEG MC on 915/945/G33 series. > So you should change lib path in your XvMCConfig file. > > New driver option "XvMC" and config option can be used to disable > XvMC feature in the driver. It turns on by default. I would love to test xvmc on an intel chipset, but something is wrong. I updated my source xorg tree using the git-xorg script (Now 1.9G in total). It now has an xvmc folder in the xf86-video-intel/src/ folder. I followed the instructions on the Xorg wiki and used the /util/macros/build.sh script. But the intel driver build fails in configure, with...: checking whether gcc and cc understand -c and -o together... yes checking for intel-gen4asm... no ./configure: line 20441: syntax error near unexpected token `XINERAMA,' ./configure: line 20441: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' The problem appears to be that XINERAMA is not defined. BTW this is the master branch, but I took it that the xvmc changes had been committed to the master branch. I did not try pulling the xvmc branch. Can anyone help? Geoff From avilella at gmail.com Sun Dec 30 13:47:01 2007 From: avilella at gmail.com (Albert Vilella) Date: Sun, 30 Dec 2007 21:47:01 +0000 Subject: Stray pixels on 945GM/GMS/940GML In-Reply-To: <200712302115.05121.arne.schmitz@gmx.net> References: <200712302115.05121.arne.schmitz@gmx.net> Message-ID: <358f4d650712301347t7a575825ib065a8a642e46b62@mail.gmail.com> I have also experienced this problem. i945GM on a Vaio laptop, only on dual head. On Dec 30, 2007 8:15 PM, Arne Schmitz wrote: > I am using X.org 1.3.0 on a Vaio UX1XN with an Intel 945 type chipset. I have > a row of stray pixels on screen line 736 (counting from 0). This happens in > dual head mode, but in single head mode I also have this, albeit on another > line, since the internal display has only 600 lines. This line is annoying, > since it destroys the rendering when I e.g. scroll a webpage. Is this a known > problem? What could be the cause? > > Arne > > -- > Dipl.-Inform. Arne Schmitz Phone +49 (0)241 80-21817 > Computer Graphics Group Fax +49 (0)241 80-22899 > RWTH Aachen University http://www.rwth-graphics.de > Ahornstrasse 55, 52074 Aachen, Germany > > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > From dbn.lists at gmail.com Sun Dec 30 14:00:47 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sun, 30 Dec 2007 16:00:47 -0600 Subject: new 'xvmc' branch of intel video driver In-Reply-To: <4777FEEE.7010509@mandamus.org> References: <4777FEEE.7010509@mandamus.org> Message-ID: <91705d080712301400g1998afaerfd6f9ee7bd854c49@mail.gmail.com> On Dec 30, 2007 2:26 PM, R. G. Newbury wrote: > Zhenyu Wang wrote: > > > > The aim of the new 'xvmc' branch is to deprecate origin > > 'xvmc-i915' branch with lot of cleanups and new framework > > inside driver to add supports for more hardware media decode > > drivers in future. It also has changes that affect users. > > > > The most noteable is that the origin libI915XvMC.so is replaced > > by a single libIntelXvMC.so entry to be used on different > > chipsets for different hardware decoders. Although currently > > there's only one decoder for MPEG MC on 915/945/G33 series. > > So you should change lib path in your XvMCConfig file. > > > > New driver option "XvMC" and config option can be used to disable > > XvMC feature in the driver. It turns on by default. > > I would love to test xvmc on an intel chipset, but something is wrong. > I updated my source xorg tree using the git-xorg script (Now 1.9G in > total). It now has an xvmc folder in the xf86-video-intel/src/ folder. > I followed the instructions on the Xorg wiki and used the > /util/macros/build.sh script. > > But the intel driver build fails in configure, with...: > checking whether gcc and cc understand -c and -o together... yes > checking for intel-gen4asm... no > ./configure: line 20441: syntax error near unexpected token `XINERAMA,' > ./configure: line 20441: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' > > The problem appears to be that XINERAMA is not defined. > BTW this is the master branch, but I took it that the xvmc changes had > been committed to the master branch. I did not try pulling the xvmc branch. > Can anyone help? Sounds very much like you don't have the pkg-config development package which contains the pkg-config autoconf macros. autoconf will just pass through strings that it doesn't recognize into the final configure shell script. This will often result in syntax errors in configure. Do you get any output from 'grep PKG_CHECK' aclocal.m4'? -- Dan From dbn.lists at gmail.com Sun Dec 30 14:03:45 2007 From: dbn.lists at gmail.com (Dan Nicholson) Date: Sun, 30 Dec 2007 16:03:45 -0600 Subject: new 'xvmc' branch of intel video driver In-Reply-To: <91705d080712301400g1998afaerfd6f9ee7bd854c49@mail.gmail.com> References: <4777FEEE.7010509@mandamus.org> <91705d080712301400g1998afaerfd6f9ee7bd854c49@mail.gmail.com> Message-ID: <91705d080712301403o7c0453afwe5f8de74fdfdda46@mail.gmail.com> On Dec 30, 2007 4:00 PM, Dan Nicholson wrote: > > On Dec 30, 2007 2:26 PM, R. G. Newbury wrote: > > Zhenyu Wang wrote: > > > > > > The aim of the new 'xvmc' branch is to deprecate origin > > > 'xvmc-i915' branch with lot of cleanups and new framework > > > inside driver to add supports for more hardware media decode > > > drivers in future. It also has changes that affect users. > > > > > > The most noteable is that the origin libI915XvMC.so is replaced > > > by a single libIntelXvMC.so entry to be used on different > > > chipsets for different hardware decoders. Although currently > > > there's only one decoder for MPEG MC on 915/945/G33 series. > > > So you should change lib path in your XvMCConfig file. > > > > > > New driver option "XvMC" and config option can be used to disable > > > XvMC feature in the driver. It turns on by default. > > > > I would love to test xvmc on an intel chipset, but something is wrong. > > I updated my source xorg tree using the git-xorg script (Now 1.9G in > > total). It now has an xvmc folder in the xf86-video-intel/src/ folder. > > I followed the instructions on the Xorg wiki and used the > > /util/macros/build.sh script. > > > > But the intel driver build fails in configure, with...: > > checking whether gcc and cc understand -c and -o together... yes > > checking for intel-gen4asm... no > > ./configure: line 20441: syntax error near unexpected token `XINERAMA,' > > ./configure: line 20441: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' > > > > The problem appears to be that XINERAMA is not defined. > > BTW this is the master branch, but I took it that the xvmc changes had > > been committed to the master branch. I did not try pulling the xvmc branch. > > Can anyone help? > > Sounds very much like you don't have the pkg-config development > package which contains the pkg-config autoconf macros. autoconf will > just pass through strings that it doesn't recognize into the final > configure shell script. This will often result in syntax errors in > configure. Do you get any output from 'grep PKG_CHECK' aclocal.m4'? I should say that it's more likely that you don't have the xorg-server development package which contains the XORG_DRIVER_CHECK_EXT autoconf macro. It's usually in the file /usr/share/aclocal/xorg-server.m4. -- Dan From dag at bakke.com Sun Dec 30 14:19:20 2007 From: dag at bakke.com (Dag Bakke) Date: Sun, 30 Dec 2007 23:19:20 +0100 Subject: Does the intel driver support G35? In-Reply-To: <1199044269.8500.6.camel@localhost> References: <1199044269.8500.6.camel@localhost> Message-ID: <20071230231920.429f56d2@dagb-home> On Sun, 30 Dec 2007 17:51:09 -0200 Leonardo Ferreira Fontenelle wrote: > I read the mailing list archives and the documentation in Git, but I > couldn't understand if, and how well, is G35 supported. I'd like to > buy a G35-based motherboard, but of course that will depend on the > drivers. If current support is non-existent, or seriously broken, how > long will it take until it is improved? (1 month? 1 year? ...) The G35 appears to be handled as a G965. I have the ASUS P5E-V HDMI board, which has a G35. I haven't yet been able to get my monitor to sync on the HDMI output. Not with xserver 1.4.0.90 and xf86-video-i810-git as of two days ago, anyway. It works well with VGA, although I think the picture will be a little bit crisper with the digital connection. OpenGL and Xv works to my satisfaction, as does 2D. There appears to be a lot of work and time being put into the intel driver these days, so I expect it will make the most out of this chip both in terms of features and performance before it has become *completely* obsolete. :-) Dag B From leo.fontenelle at gmail.com Sun Dec 30 16:29:50 2007 From: leo.fontenelle at gmail.com (Leonardo Ferreira Fontenelle) Date: Sun, 30 Dec 2007 22:29:50 -0200 Subject: Does the intel driver support G35? In-Reply-To: <20071230231920.429f56d2@dagb-home> References: <1199044269.8500.6.camel@localhost> <20071230231920.429f56d2@dagb-home> Message-ID: <1199060990.29626.40.camel@localhost> Thank you, that's what I needed to know! I should by a P5E-VM or similar card in a few weeks. Leonardo Fontenelle http://leonardof.org Em Dom, 2007-12-30 ?s 23:19 +0100, Dag Bakke escreveu: > On Sun, 30 Dec 2007 17:51:09 -0200 > Leonardo Ferreira Fontenelle wrote: > > > I read the mailing list archives and the documentation in Git, but I > > couldn't understand if, and how well, is G35 supported. I'd like to > > buy a G35-based motherboard, but of course that will depend on the > > drivers. If current support is non-existent, or seriously broken, how > > long will it take until it is improved? (1 month? 1 year? ...) > > The G35 appears to be handled as a G965. > > I have the ASUS P5E-V HDMI board, which has a G35. I haven't yet been > able to get my monitor to sync on the HDMI output. Not with > xserver 1.4.0.90 and xf86-video-i810-git as of two days ago, anyway. > > It works well with VGA, although I think the picture will be a little > bit crisper with the digital connection. > > OpenGL and Xv works to my satisfaction, as does 2D. > > There appears to be a lot of work and time being put into the intel > driver these days, so I expect it will make the most out of > this chip both in terms of features and performance before it has become > *completely* obsolete. :-) > > > Dag B > _______________________________________________ > xorg mailing list > xorg at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg From faraci1 at sbcglobal.net Sun Dec 30 16:55:09 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Sun, 30 Dec 2007 18:55:09 -0600 Subject: current xserver git repo make error Message-ID: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> Im getting an error: expected expression before ')' token in main.c of dix, not sure what im missing autogen.sh runs fine no errors. I have attached a log of make from xserver dir. This is on Debian Etch, Sunblade 1500. Thank You Michael No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: application/octet-stream Size: 32771 bytes Desc: not available URL: From bero at arklinux.org Sun Dec 30 18:03:48 2007 From: bero at arklinux.org (Bernhard Rosenkraenzer) Date: Sun, 30 Dec 2007 20:03:48 -0600 Subject: current xserver git repo make error In-Reply-To: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> References: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> Message-ID: <219eae94a3468f4f537b5e9a9bfba99e@mail2.arklinux.org> On Sun, 30 Dec 2007 18:55:09 -0600, "Michael Faraci" wrote: > Im getting an error: expected expression before ')' token in main.c > of dix Explanation + fix here: https://bugs.freedesktop.org/show_bug.cgi?id=13794 From faraci1 at sbcglobal.net Sun Dec 30 17:42:05 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Sun, 30 Dec 2007 19:42:05 -0600 Subject: current xserver git repo make error In-Reply-To: <219eae94a3468f4f537b5e9a9bfba99e@mail2.arklinux.org> Message-ID: <20071231014206.BEA2F9EBB2@gabe.freedesktop.org> I apologize if im wrong, but I tried the patch, but no resolve, this is an error with xserver/dix/main.c main.c:508: error: expected expression before ')' token main.c:508: error: expected expression before ')' token make[2]: *** [main.lo] Error 1 make[2]: Leaving directory `/home/git/xserver/dix' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/git/xserver/dix' make: *** [all-recursive] Error 1 GinoPC:/home/git/xserver# -----Original Message----- From: Bernhard Rosenkraenzer [mailto:bero at arklinux.org] Sent: Sunday, December 30, 2007 8:04 PM To: Michael Faraci Cc: xorg at lists.freedesktop.org Subject: Re: current xserver git repo make error On Sun, 30 Dec 2007 18:55:09 -0600, "Michael Faraci" wrote: > Im getting an error: expected expression before ')' token in main.c > of dix Explanation + fix here: https://bugs.freedesktop.org/show_bug.cgi?id=13794 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM From daniel at fooishbar.org Sun Dec 30 20:45:07 2007 From: daniel at fooishbar.org (Daniel Stone) Date: Mon, 31 Dec 2007 05:45:07 +0100 Subject: current xserver git repo make error In-Reply-To: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> References: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> Message-ID: <20071231044507.GB8675@fooishbar.org> On Sun, Dec 30, 2007 at 06:55:09PM -0600, Michael Faraci wrote: > Im getting an error: expected expression before ')' token in main.c of dix, > not sure what im missing autogen.sh runs fine no errors. I have attached a > log of make from xserver dir. This is on Debian Etch, Sunblade 1500. At a guess, /bin/sh is not bash, and it's choking on the arithmetic. Try changing /bin/sh to bash, or hand-hacking configure to launch /bin/bash. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From faraci1 at sbcglobal.net Sun Dec 30 21:39:24 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Sun, 30 Dec 2007 23:39:24 -0600 Subject: current xserver git repo make error In-Reply-To: <20071231044507.GB8675@fooishbar.org> Message-ID: <20071231053925.794129E7E6@gabe.freedesktop.org> Daniel, below is an output showing sh pointing to bash, so would this eliminate your theory or should I continue checking? Thanks for your help ls -l /bin | grep sh -rwxr-xr-x 1 root root 677296 2006-12-11 15:56 bash lrwxrwxrwx 1 root root 4 2007-12-28 12:23 rbash -> bash lrwxrwxrwx 1 root root 4 2007-12-28 12:23 sh -> bash -----Original Message----- From: Daniel Stone [mailto:daniel at fooishbar.org] Sent: Sunday, December 30, 2007 10:45 PM To: Michael Faraci Cc: xorg at lists.freedesktop.org Subject: Re: current xserver git repo make error On Sun, Dec 30, 2007 at 06:55:09PM -0600, Michael Faraci wrote: > Im getting an error: expected expression before ')' token in main.c of dix, > not sure what im missing autogen.sh runs fine no errors. I have attached a > log of make from xserver dir. This is on Debian Etch, Sunblade 1500. At a guess, /bin/sh is not bash, and it's choking on the arithmetic. Try changing /bin/sh to bash, or hand-hacking configure to launch /bin/bash. Cheers, Daniel No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM From newbury at mandamus.org Sun Dec 30 21:44:59 2007 From: newbury at mandamus.org (R. G. Newbury) Date: Mon, 31 Dec 2007 00:44:59 -0500 Subject: 9. Re: new 'xvmc' branch of intel video driver In-Reply-To: References: Message-ID: <477881DB.1010505@mandamus.org> >> But the intel driver build fails in configure, with...: >> > > checking whether gcc and cc understand -c and -o together... yes >> > > checking for intel-gen4asm... no >> > > ./configure: line 20441: syntax error near unexpected token `XINERAMA,' >> > > ./configure: line 20441: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' >> > > >> > > The problem appears to be that XINERAMA is not defined. >> > > BTW this is the master branch, but I took it that the xvmc changes had >> > > been committed to the master branch. I did not try pulling the xvmc branch. >> > > Can anyone help? > > > > Sounds very much like you don't have the pkg-config development > > package which contains the pkg-config autoconf macros. autoconf will > > just pass through strings that it doesn't recognize into the final > > configure shell script. This will often result in syntax errors in > > configure. Do you get any output from 'grep PKG_CHECK' aclocal.m4'? > I should say that it's more likely that you don't have the xorg-server > development package which contains the XORG_DRIVER_CHECK_EXT autoconf > macro. It's usually in the file /usr/share/aclocal/xorg-server.m4. > Dan Right you are. I ended up doing a 'yum install xorg-x11-server-devel xorg-x11-server-source' and the previously missing xorg-server.m4 file miraculously appeared. I'm running the compile now. Probably a lot faster and waaaay fewer errors than before. Thank you. Geoff From jcristau at debian.org Sun Dec 30 23:40:12 2007 From: jcristau at debian.org (Julien Cristau) Date: Mon, 31 Dec 2007 08:40:12 +0100 Subject: current xserver git repo make error In-Reply-To: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> References: <20071231005511.AE82A9E7BC@gabe.freedesktop.org> Message-ID: <20071231074010.GA9999@patate.is-a-geek.org> On Sun, Dec 30, 2007 at 18:55:09 -0600, Michael Faraci wrote: > Im getting an error: expected expression before ')' token in main.c of dix, > not sure what im missing autogen.sh runs fine no errors. I have attached a > log of make from xserver dir. This is on Debian Etch, Sunblade 1500. > > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../include -I../include -I../include -I../include -I../include -I../Xprint -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/pixman-1 -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb "-DVENDOR_NAME=\"The X.Org Foundation\"" "-DVENDOR_RELEASE=(((1) * 10000000) + (() * 100000) + (() * 1000) + 2)" -g -O2 -MT main.lo -MD -MP -MF .deps/main.Tpo -c main.c -fPIC -DPIC -o .libs/main.o > main.c:508: error: expected expression before ')' token > main.c:508: error: expected expression before ')' token It looks like the release version isn't getting set correctly, so some parts are empty. Is the xutils-dev package installed when you run autoreconf/autogen, and is the XORG_RELEASE_VERSION macro available? Cheers, Julien From eich at freedesktop.org Mon Dec 31 00:22:06 2007 From: eich at freedesktop.org (Egbert Eich) Date: Mon, 31 Dec 2007 09:22:06 +0100 Subject: Reminder to vote for Foundation Board In-Reply-To: jra@baylink.com wrote on Sunday, 30 December 2007 at 11:51:25 -0500 References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> <20071230064317.GB29629@cgi.jachomes.com> <20071230092957.GA10850@suse.de> <20071230165125.GD31172@cgi.jachomes.com> Message-ID: <18296.42670.971692.290233@cicero.suse.de> Jay R. Ashworth writes: > On Sun, Dec 30, 2007 at 10:29:58AM +0100, Stefan Dirsch wrote: > > > WADR, this argument already got made... a month ago. Did it not? > > > > I'm not aware of the election period being mentioned anytime before > > the announcement for itself on Fri Dec 21. Could you provide some > > reference for your statement? > > Normally, I locally archive mailing lists, but xorg fell off that pile > when I got short of space; I do believe, though, that we heard the "why > is this such short notice" argument, when people simply didn't realize > that it was *not* short notice, around the first of December. > Jay - The date of the actual election had not been announced until Friday, Dec. 21. Furthermore the timeliness argument doesn't invalidate the original issue namely the fact that the timing of the election might have been rather inconvenient for some of the Members. Cheers, Egbert. From harryrat at postnuklear.de Mon Dec 31 02:06:16 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Mon, 31 Dec 2007 11:06:16 +0100 Subject: current xserver git repo make error In-Reply-To: <20071231014206.BEA2F9EBB2@gabe.freedesktop.org> References: <20071231014206.BEA2F9EBB2@gabe.freedesktop.org> Message-ID: <200712311106.16660.harryrat@postnuklear.de> On Monday 31 December 2007 02:42:05 Michael Faraci wrote: > I apologize if im wrong, but I tried the patch, but no resolve, this is an > error with xserver/dix/main.c > > main.c:508: error: expected expression before ')' token > main.c:508: error: expected expression before ')' token > make[2]: *** [main.lo] Error 1 > make[2]: Leaving directory `/home/git/xserver/dix' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/git/xserver/dix' > make: *** [all-recursive] Error 1 > GinoPC:/home/git/xserver# > hm, I think I had the same problem with 1.4.0 ...I modified the ./configure script so it sets the vendor release correctly PVM=`echo $PACKAGE_VERSION | cut -d . -f 2` if test "x$PVM" = "x"; then PVM="0" fi PVP=`echo $PACKAGE_VERSION | cut -d . -f 3` if test "x$PVP" = "x"; then PVP="0" fi (I put this right below "PVMAJOR=`echo $PACKAGE_VERSION | cut -d . -f 1`") Not sure if I missed a package or so, no idea why this problem appeared, so this was just a working fix for me (: Hope that helps Harry From SirRichard at fascinationsoftware.com Mon Dec 31 04:41:27 2007 From: SirRichard at fascinationsoftware.com (Richard Goedeken) Date: Mon, 31 Dec 2007 07:41:27 -0500 Subject: [xorg] X3100 OpenGL incredibly slow and buggy on 2.2.0 In-Reply-To: References: Message-ID: <4778E377.7070409@fascinationsoftware.com> > The title is quite meaningful: running xf86-video-intel 2.2.0, Mesa > 7.0.1, not running compiz or any other sort of composite window > manager, have Composite extension and AIGLX turned off (but it doesn't > make any difference), I find OpenGL applications to be very slow. > glxgears shows an average of 1100fps (this is what a GMA950 usually > achieves). I also have the X3100, in an Aopen MP965 w/ 2GB of ram. I'm running the latest drivers from git, and have filed bug reports for several non-performance related bugs that I've found. I haven't seen the crash when moving the window, but my 3D performance is also quite bad: I consistently score just under 600fps with glxgears. My N64 emulator chokes a little when the polygon count goes high, while it's perfect with an older GeForce 6600 fanless card in my desktop PC. Like others have mentioned, I waited for and bought the i965 hardware with hopes for good performance and open source driver support. If the GMA950 could do 1100fps with glxgears then there must be something really wrong, because my MiniPC can only do half that. Earlier versions of the driver did about 850 but I don't think I ever saw numbers higher than this. Richard From marchesin at icps.u-strasbg.fr Mon Dec 31 05:46:39 2007 From: marchesin at icps.u-strasbg.fr (Stephane Marchesin) Date: Mon, 31 Dec 2007 14:46:39 +0100 Subject: [xorg] X3100 OpenGL incredibly slow and buggy on 2.2.0 In-Reply-To: <4778E377.7070409@fascinationsoftware.com> References: <4778E377.7070409@fascinationsoftware.com> Message-ID: <6a89f9d50712310546i43f8badcw60bdbbcc5a175e42@mail.gmail.com> On 12/31/07, Richard Goedeken wrote: > > > > The title is quite meaningful: running xf86-video-intel 2.2.0, Mesa > > 7.0.1, not running compiz or any other sort of composite window > > manager, have Composite extension and AIGLX turned off (but it doesn't > > make any difference), I find OpenGL applications to be very slow. > > glxgears shows an average of 1100fps (this is what a GMA950 usually > > achieves). > > I also have the X3100, in an Aopen MP965 w/ 2GB of ram. I'm running the > latest > drivers from git, and have filed bug reports for several non-performance > related > bugs that I've found. I haven't seen the crash when moving the window, > but my > 3D performance is also quite bad: I consistently score just under 600fps > with > glxgears. My N64 emulator chokes a little when the polygon count goes > high, > while it's perfect with an older GeForce 6600 fanless card in my desktop > PC. > Like others have mentioned, I waited for and bought the i965 hardware with > hopes > for good performance and open source driver support. If the GMA950 could > do > 1100fps with glxgears then there must be something really wrong, because > my > MiniPC can only do half that. Earlier versions of the driver did about > 850 but > I don't think I ever saw numbers higher than this. Please read this : http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark Stephane -------------- next part -------------- An HTML attachment was scrubbed... URL: From techservio at gmail.com Mon Dec 31 08:37:37 2007 From: techservio at gmail.com (techservio) Date: Mon, 31 Dec 2007 08:37:37 -0800 (PST) Subject: how to compile Xgl? In-Reply-To: <14538954.post@talk.nabble.com> References: <14538954.post@talk.nabble.com> Message-ID: <14559430.post@talk.nabble.com> OK, if not for the Xgl, what are the other ways to improve performance of GUI with DRI? I use Xorg from git and the settings are: Section "Device" Identifier "Card0" Driver "radeon" VendorName "ATI Technologies Inc" BoardName "RV350 AP [Radeon 9600]" BusID "PCI:1:0:0" Option"ColorTiling""on" Option"EnablePageFlip""true" Option"AccelMethod" "EXA" Option"XAANoOffscreenPixmaps" EndSection The GL works fine, as I can see it, but the GUI is terribly slow. If I set: Option"AccelMethod" "XXA" ,the ?? GUI works well, but the fonts are disturted. Am I missing some settings, which have to be done in the xorg.conf ? I also tried to install the xorg 7.3 from tarballs. I this case fonts are displayed properly, however some black areas are blinking before any display element (like menu item or a pop up window) is displayed. The same is happening, for example, when I scroll a webpage in a browser. Any partial help is welcome the xorg.conf is enclosed http://www.nabble.com/file/p14559430/xorg.conf xorg.conf -- View this message in context: http://www.nabble.com/how-to-compile-Xgl--tp14538954p14559430.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. From faraci1 at sbcglobal.net Mon Dec 31 08:39:15 2007 From: faraci1 at sbcglobal.net (Michael Faraci) Date: Mon, 31 Dec 2007 10:39:15 -0600 Subject: [Bulk] Re: current xserver git repo make error In-Reply-To: <20071231074010.GA9999@patate.is-a-geek.org> Message-ID: <20071231163917.A1A3C9EC10@gabe.freedesktop.org> Yes, this is the version below, also xorgversion.m4 is defined in /usr/local/share/aclocal. This is the macro you are referring to right? xutils-dev 1:7.2.ds2-1 X Window System utility programs for develop -----Original Message----- From: Julien Cristau [mailto:jcristau at debian.org] Sent: Monday, December 31, 2007 1:40 AM To: Michael Faraci Cc: xorg at lists.freedesktop.org Subject: [Bulk] Re: current xserver git repo make error On Sun, Dec 30, 2007 at 18:55:09 -0600, Michael Faraci wrote: > Im getting an error: expected expression before ')' token in main.c of dix, > not sure what im missing autogen.sh runs fine no errors. I have attached a > log of make from xserver dir. This is on Debian Etch, Sunblade 1500. > > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../include -I../include -I../include -I../include -I../include -I../Xprint -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/pixman-1 -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb "-DVENDOR_NAME=\"The X.Org Foundation\"" "-DVENDOR_RELEASE=(((1) * 10000000) + (() * 100000) + (() * 1000) + 2)" -g -O2 -MT main.lo -MD -MP -MF .deps/main.Tpo -c main.c -fPIC -DPIC -o .libs/main.o > main.c:508: error: expected expression before ')' token > main.c:508: error: expected expression before ')' token It looks like the release version isn't getting set correctly, so some parts are empty. Is the xutils-dev package installed when you run autoreconf/autogen, and is the XORG_RELEASE_VERSION macro available? Cheers, Julien No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 12/30/2007 11:27 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1204 - Release Date: 12/31/2007 12:20 PM From newbury at mandamus.org Mon Dec 31 09:02:27 2007 From: newbury at mandamus.org (R. G. Newbury) Date: Mon, 31 Dec 2007 12:02:27 -0500 Subject: new 'xvmc' branch of intel video driver In-Reply-To: References: Message-ID: <477920A3.7050507@mandamus.org> > > I should say that it's more likely that you don't have the xorg-server > > development package which contains the XORG_DRIVER_CHECK_EXT autoconf > > macro. It's usually in the file /usr/share/aclocal/xorg-server.m4. > > Dan > > Right you are. > I ended up doing a 'yum install xorg-x11-server-devel > xorg-x11-server-source' and the previously missing xorg-server.m4 file > miraculously appeared. I'm running the compile now. Probably a lot > faster and waaaay fewer errors than before. Update: SOLVED....with questions... Compiling the driver, using: root at myth src]# cd driver/xf86-video-intel/ [root at myth xf86-video-intel]# ./autogen.sh --prefix=/video2/temp/tmp/modular Configure now completes properly...(The xorg wiki needs to be updated to list the package requirements: server-source and server-devel.) BUT: [root at myth xf86-video-intel]# make make all-recursive make[1]: Entering directory `/video2/temp/tmp/src/driver/xf86-video-intel' Making all in src make[2]: Entering directory `/video2/temp/tmp/src/driver/xf86-video-intel/src' Making all in xvmc make[3]: Entering directory `/video2/temp/tmp/src/driver/xf86-video-intel/src/xvmc' .... gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -I../../src -DTRUE=1 -DFALSE=0 -g -O2 -MT libI810XvMC_la-I810XvMC.lo -MD -MP -MF .deps/libI810XvMC_la-I810XvMC.Tpo -c I810XvMC.c -fPIC -DPIC -o .libs/libI810XvMC_la-I810XvMC.o In file included from /usr/local/include/xf86drm.h:661, from I810XvMC.h:45, from I810XvMC.c:53: /usr/local/include/xf86mm.h:134: error: field 'bo_arg' has incomplete type make[3]: *** [libI810XvMC_la-I810XvMC.lo] Error 1 Interestingly, I have TWO different copies of xf86mm.h in /usr/local/include and /usr/include. The latter folder has a lot more files in it, and the time-stamp on the file is earlier than the one in 'local'. Nothing in the files themselves notes any revision or changes. Anyone? Anyone? Bueller? At any rate, copying the earlier file to /usr/local/include allows make and make install to complete. Now to see if I can make it work!!! Geoff From jra at baylink.com Mon Dec 31 09:15:48 2007 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 31 Dec 2007 12:15:48 -0500 Subject: Reminder to vote for Foundation Board In-Reply-To: <18296.42670.971692.290233@cicero.suse.de> References: <200712292111.lBTLBlAA023963@murzim.cs.pdx.edu> <20071229220250.GA389@skynet.be> <20071230064317.GB29629@cgi.jachomes.com> <20071230092957.GA10850@suse.de> <20071230165125.GD31172@cgi.jachomes.com> <18296.42670.971692.290233@cicero.suse.de> Message-ID: <20071231171548.GB3043@cgi.jachomes.com> On Mon, Dec 31, 2007 at 09:22:06AM +0100, Egbert Eich wrote: > The date of the actual election had not been announced until Friday, Dec. 21. > Furthermore the timeliness argument doesn't invalidate the original issue > namely the fact that the timing of the election might have been rather > inconvenient for some of the Members. Forgive me; I thought that the *open date* was around the first of December; have there been *two* elections or nomination periods recently? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA From alexdeucher at gmail.com Mon Dec 31 09:57:52 2007 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 31 Dec 2007 12:57:52 -0500 Subject: What to blame for ATI lockups after upgrade ? In-Reply-To: References: Message-ID: On Dec 28, 2007 5:31 PM, Fr?d?ric L. W. Meunier wrote: > On Fri, 28 Dec 2007, Alex Deucher wrote: > > > On Dec 28, 2007 5:00 PM, Fr?d?ric L. W. Meunier wrote: > > > >> I used XOrg 1.4 with ATI driver 6.7.196 without any problems > >> for a month. I upgraded to XOrg 1.4.0.90 on december 13 and to > >> ATI 6.7.197 on the 21. > >> > >> On the 22, suddenly, while moving the mouse cursor, nothing > >> worked anymore. I could move the mouse, but it was like an "I" > >> and didn't do anything. The screen was apparently locked, as > >> the clock didn't get updated. > > > > Try disabling the DRI or changing the AGPMode. the newer ati driver > > switched back to AGP 1x mode by default, previous versions defaulted > > to whatever mode the bios set. Both seem to have stability problems > > on different cards. > > > > Option "AGPMode" "4" > > I always had that option set in my xorg.conf (the card supports > 8x, but the motherboard only 4x), so the solution would be to > disable DRI and, if I need DRI (I don't for now), return to > 6.7.196 ? Well, it should act the same as previous versions with that option. If it doesn't then you'll probably want to file a bug and attach your xorg log and config along with any other relevant info. Alex From gene.heskett at verizon.net Mon Dec 31 10:26:45 2007 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 31 Dec 2007 13:26:45 -0500 Subject: Prrobably silly Q? re xhost Message-ID: <200712311326.45173.gene.heskett@verizon.net> Greetings; I would like to add another machine to the x clients at boot time, but I boot to runlevel 3, so that xhost +ad.dr.es.s in my rc.local is just an error message. How can I add this so its done quite late in the 'startx' sequence? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Your computer hasn't been returning all the bits it gets from the Internet. From sergio at sergiomb.no-ip.org Mon Dec 31 11:23:57 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Mon, 31 Dec 2007 19:23:57 +0000 Subject: [Fwd: Re: Problem with intel driver on laptop with 945GM chipset] Message-ID: <1199129037.19392.15.camel@localhost.localdomain> sorry I forget add xorg at lists.freedesktop.org -------- Forwarded Message -------- Subject: Re: Problem with intel driver on laptop with 945GM chipset Date: Mon, 31 Dec 2007 19:15:50 +0000 On Wed, 2007-12-19 at 17:34 +0100, Maciej ?ozi?ski wrote: > Do you have any ideas what could be done with it? > you may test add on Section "Device": Driver "intel" ... Option "AccelMethod" "XAA" Regards, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Mon Dec 31 11:51:32 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Mon, 31 Dec 2007 19:51:32 +0000 Subject: Major stability issues with xf86-video-intel 2.2.0 when using Xv In-Reply-To: <1198207626.6348.33.camel@localhost.localdomain> References: <475F87D6.1040008@gentoo.org> <200712171513.33017.jbarnes@virtuousgeek.org> <1197958094.17915.29.camel@localhost.localdomain> <200712180913.32212.jbarnes@virtuousgeek.org> <1198105801.6348.9.camel@localhost.localdomain> <1198118446.2887.5.camel@monteirov> <1198162298.6348.15.camel@localhost.localdomain> <1198202504.4986.13.camel@monteirov> <1198207626.6348.33.camel@localhost.localdomain> Message-ID: <1199130692.19392.35.camel@localhost.localdomain> On Fri, 2007-12-21 at 14:27 +1100, Drew Parsons wrote: > On Fri, 2007-12-21 at 02:01 +0000, Sergio Monteiro Basto wrote: > > On Fri, 2007-12-21 at 01:51 +1100, Drew Parsons wrote: > > > Hi Sergio, do you mean that, when using git for everything, you have a > > > consistently successful suspend/resume on an intel 855 chip? > > > > No, I mean when we talking about: "Major stability issues with > > xf86-video-intel 2.2.0" , we should talk about compile video-drv with > > stable branch of xserver. > > and I mean if you are trying xserver from git, you need many thing from > > gits like Mesa and drm. > > > > Ah OK. I'm using mostly-stable versions too (apart from specific > commits cherry-picked from git), so we're doing the same thing there. > For me mesa is way too scary to build straight from git ;) > > > About suspend/resume,I don't need a new drm or libdrm. I had some > > problem with kernel-2.6.22 that was fix on 2.6.23, but with 2.6.23 I had > > a regression on black-light. > > - hibernation works well. > > - suspend to ram, after resume, I had to go to console (ctrl+alt+F1) and > > return to X (ctrl+alt+F7), to get back the screen. > > I haven't checked the backlight in detail so I don't know about that. > Hibernation (S4 suspend-to-disk) works flawlessly for me too. > > S3 suspend-to-ram is the one I have problems with, going to console and > back does not fix it for me. > > > My laptop is one hp-compaq nx6110, what is yours ? > > Mine is an IBM R51 Thinkpad with Intel(R) 855GME. Sorry, I just see your message today, (I like being add in CC to have the email directly :) ). On Redhat and Kernel bugzilla etc, I saw some reports about Thinkpads (Lenovos) with same or similar issues, but here (in this mailing list) the question is: If Intel video drive have problems that prevents you to suspend and/or hibernation your laptop and my guess is no. So, put your laptop level 3, with command "init 3" and without X can you suspend yours laptop ? IIRC, you write in one case you got a success suspend, do you remember what was the version of your kernel?. I think this issue depends more on kernel version. Regards, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From SirRichard at fascinationsoftware.com Mon Dec 31 14:45:25 2007 From: SirRichard at fascinationsoftware.com (Richard Goedeken) Date: Mon, 31 Dec 2007 17:45:25 -0500 Subject: [xorg] X3100 OpenGL incredibly slow and buggy on 2.2.0 In-Reply-To: References: Message-ID: <47797105.7000703@fascinationsoftware.com> > Please read this : > http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark > > Stephane You're right, glxgears is not a comprehensive 3D acceleration benchmark, but it does measure some narrow window of system hardware performance. Let's look at my 2 main systems for comparison: Desktop PC: - 64-bit Gentoo, older stable drivers - Gigabyte GA-K8N Ultra-9 socket939 nForce4 Ultra ATX - Athlon64 3800 x2 - 2.0GHz 1MB total cache - Asus EN6600/TD/256M Silencer - GeForce 6600, 256M ram - 128 bit DDR2 ram 500MHz, 8.0 GB/s - 300MHz core, 8 pixel shaders, 3 vertex shaders - PCI Express x16 - 2GB PC3200 DDR 400MHz SDRAM (6.4 GB/s) Set-top PC: - 64-bit Fedora 8, git drivers for mesa/drm/intel - AOpen MiniPC MP965-DR, Intel 965GM chipset - Intel Core 2 Duo T7500 2.2GHz Socket P 4MB total cache - X3100 graphics - shared system memory, total bandwidth 10.7 GB/s - 500MHz core, 8 unified shaders - 2*1GB dual channel PC5300 DDR2 667MHZ SDRAM By all measures it looks like the settop box would meet or beat the desktop one. But the difference in 3D performance in favor of the desktop is large, not small. Even if you write off a factor of 6 (!) times as many fps in glxgears, it remains that the N64 emulator I'm working on runs flawlessly with low CPU usage on the desktop box but bogs down on the MiniPC. glxinfo says direct rendering is on. If someone could suggest a good 3D benchmark for Linux I would be willing to run it for an experiment. Something is wrong here. Either the shared memory architecture really just clobbers real-world performance or else something is far from optimal in the software stack. Richard From dickey at radix.net Mon Dec 31 17:36:46 2007 From: dickey at radix.net (Thomas Dickey) Date: Mon, 31 Dec 2007 20:36:46 -0500 Subject: ANN: xterm #230 Message-ID: <20080101013645.GB12735@saltmine.radix.net> Patch #230 - 2007/12/31 * add quietGrab resource, which when true, suppresses cursor repainting when NotifyGrab and NotifyUngrab event types are received during change of focus (request by Nicolas George). * do not treat Unicode BIDI control characters as combining characters (Debian #457634). * add koi8rxterm, from Debian. * add manpage for uxterm, from Debian (Ubuntu #128136, Debian #438645) * remove ".xpm" suffixes from Icon filenames in desktop files since it confuses some lookups following the [234]Icon Theme Specification (report by Slava Semushin) * correct width-calculation used for adjusting proportional fonts, to work with wide-characters (Debian #441354). * fixes/improvements for double-size characters: + correct old clipping calculation which used total height of glyphs where ascent was needed. + if bold font is unavailable, fall back to normal font + adjust to "work" with Xft (which does not support double-width single-height characters). + restore reset of doublesize for a line when it is cleared, broken in [235]patch #228. * modify logic for forceBoxChars resource when using TrueType fonts to be consistent with bitmap fonts * modify logic for forceBoxChars resource to make the "Line-Drawing Characters" menu entry use xterm's line-drawing characters even asked to draw wide line-drawing characters which are available in the font. * modify rectangle-support functions to preserve colors when filling/erasing (request by Enzo Toscano, to match WRQ Reflection behavior). * add getopt-parsing to tcapquery.pl, including feature to test the extended cursor/editing keys. * make missing double-width glyphs display as double-width (Debian #456236). * change tcap-fkeys and rectangles configure options to enable them by default. * hide the mouse pointer while user is typing (request by Rodolfo Borges). * extend configure options --enable-tcap-query and --enable-tcap-fkeys to send cursor- and editing-keypad keys modified according to the keyboard (or termcap) selection for shift, alt, control, meta. * modify kdch1 in termcap, e.g., xterm-r6 to match the terminfo file. * add -hm option to turn highlightColorMode on or off. * add highlightColorMode resource to separate the new (since patch #225) highlighting with both text- and background-colors (prompted by report/example by Thomas Wolff). * add Keep Selection menu entry to turn the keepSelection resource on/off at runtime. * add keepSelection resource, which when enabled, tells xterm to retain the X selection even after it stops highlighting it (patch by Sergey Vlasov). * extend the CSI > n sequence to allow disabling all types of modified-keys that the CSI > m sequence affects. * move include for in resize.c to avoid redefinition of termios structure on OpenSolaris (report by Rahul Gopinathan Nair). * extend terminfo building blocks for modified editing keys to include all six keys. * synchronize terminfo with ncurses (report by Stephane Chazelas): + equate xterm-xfree86 and xterm-xf86-v44. + add ncurses extensions OTbs, AX, for termcap conversions. + make old/legacy entries such as xterm-24, xterm-65 and aliases xterms, vs100 inherit from xterm-old. + make xterm-r5 and xterm-r6 the same, ignoring historical errors in X Consortium's version. * fix an ifdef in logic for selecting regular expressions while in a narrow-character locale (Debian #449227). -- 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: From bernd-schubert at gmx.de Mon Dec 31 17:59:18 2007 From: bernd-schubert at gmx.de (Bernd Schubert) Date: Tue, 01 Jan 2008 02:59:18 +0100 Subject: wrong dpi after update Message-ID: Hi, I'm using Debian Sid on my desktop system, but I did the last update some weeks ago. After updating today several parts of X got updated and now something goes wrong with display-size detection and hence the display dpi is wrong (as are all font sizes). (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 162.0 MHz Image Size: 367 x 275 mm bernd at bathl ~>xrandr Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1600 x 1200 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 59.9 But: (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input (II) RADEON(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) RADEON(0): Gamma: 2.20 410x310 mm is the correct display size, but somehow by default 367x275 mm are used. And even though EDID provides correct information? Setting the correct value with "xrandr --fbdev 410x310" does work, but in the past this did work automatically? Thanks, Bernd From eric at anholt.net Mon Dec 31 18:46:30 2007 From: eric at anholt.net (Eric Anholt) Date: Mon, 31 Dec 2007 18:46:30 -0800 Subject: [xorg] X3100 OpenGL incredibly slow and buggy on 2.2.0 In-Reply-To: <47797105.7000703@fascinationsoftware.com> References: <47797105.7000703@fascinationsoftware.com> Message-ID: <1199155590.98142.10.camel@localhost> On Mon, 2007-12-31 at 17:45 -0500, Richard Goedeken wrote: > > Please read this : > > http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark > > > > Stephane > > You're right, glxgears is not a comprehensive 3D acceleration benchmark, but it > does measure some narrow window of system hardware performance. Let's look at > my 2 main systems for comparison: > > Desktop PC: > - 64-bit Gentoo, older stable drivers > - Gigabyte GA-K8N Ultra-9 socket939 nForce4 Ultra ATX > - Athlon64 3800 x2 - 2.0GHz 1MB total cache > - Asus EN6600/TD/256M Silencer > - GeForce 6600, 256M ram > - 128 bit DDR2 ram 500MHz, 8.0 GB/s > - 300MHz core, 8 pixel shaders, 3 vertex shaders > - PCI Express x16 > - 2GB PC3200 DDR 400MHz SDRAM (6.4 GB/s) > > Set-top PC: > - 64-bit Fedora 8, git drivers for mesa/drm/intel > - AOpen MiniPC MP965-DR, Intel 965GM chipset > - Intel Core 2 Duo T7500 2.2GHz Socket P 4MB total cache > - X3100 graphics > - shared system memory, total bandwidth 10.7 GB/s > - 500MHz core, 8 unified shaders > - 2*1GB dual channel PC5300 DDR2 667MHZ SDRAM > > By all measures it looks like the settop box would meet or beat the desktop one. > But the difference in 3D performance in favor of the desktop is large, not > small. Even if you write off a factor of 6 (!) times as many fps in glxgears, > it remains that the N64 emulator I'm working on runs flawlessly with low CPU > usage on the desktop box but bogs down on the MiniPC. glxinfo says direct > rendering is on. If someone could suggest a good 3D benchmark for Linux I would > be willing to run it for an experiment. Something is wrong here. Either the > shared memory architecture really just clobbers real-world performance or else > something is far from optimal in the software stack. Your N64 emulator sounds like an interesting thing to benchmark with, if graphics driver performance is an important factor. Finding a way to get a demo to play and exit and report fps could be useful. http://dri.freedesktop.org/wiki/Benchmarking has some of the things I've used for benchmarking and pointing other people at who are trying to figure out how to compare 3d performance. -- Eric Anholt anholt at FreeBSD.org eric at anholt.net eric.anholt at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part URL: From pcpa at mandriva.com.br Sat Dec 1 06:27:02 2007 From: pcpa at mandriva.com.br (pcpa at mandriva.com.br) Date: Sat, 01 Dec 2007 14:27:02 -0000 Subject: Xorg Input Hotplugging In-Reply-To: <20071201140039.GL6534@fooishbar.org> References: <1192412762.10563.14.camel@mercury> <1195118577.17511.17.camel@rousalka.dyndns.org> <200711302115.21487.arvidjaar@mail.ru> <1196454244.4700.3.camel@juerg-pd.bitron.ch> <1196470645.3148.6.camel@localhost.localdomain> <4750FBF8.2040405@codewiz.org> <20071201104942.uot4da8kfj6so8ss@webmail.conectiva.com.br> <20071201140039.GL6534@fooishbar.org> Message-ID: <20071201122322.06r3i5ujhekgg8gw@webmail.conectiva.com.br> Quoting Daniel Stone : > On Sat, Dec 01, 2007 at 10:49:42AM -0200, pcpa at mandriva.com.br wrote: >> The main problem is that there isn't a mapping from hal devices >> to xorg.conf devices, and the hal code in the X Server, if hal is >> "properly configured", will load a new module to handle an input >> device that already have a module loaded for it, as listed in >> xorg.conf. > > With evdev, this isn't a problem. EVIOCGRAB means that even if you have > the 'mouse' driver on /dev/input/mice and evdev drivers on > /dev/input/eventN, you'll never get duplicate events. > > For the mouse and kbd drivers, yes, this is an issue. > >> For example, if I change hal to use the mouse driver for my ps2 >> mouse, and have an input device section in xorg.conf also using >> the mouse driver, I will get double clicks for every mouse click. > > I'm not really sure why you'd do that, but yes, I do see the problem. I > guess one solution is just to remove the keyboard and mouse fallbacks in > the HAL FDI, and only ever do drivers that we know don't intefere with > others. This was in experimental code to fallback to xorg.conf configuration, but afaik, the evdev driver also doesn't provide 3 buttons emulation. And at first, I did not want to make a patch that would ignore xorg.conf settings. This probably will also break in some other way on *BSD, as hal is very Linux dependant for the moment, at least regarding to default/fallback values. >> Simillar problems will happen with the keyboard, like arrow keys >> not working, in my case it was mapping to Print Screen, and calling >> ksnapshot when running kde. > > That's just your XKB model being set wrong. I know the underlying > infrastructure works, because I've tested with multiple keyboards having > different layouts, etc. Maybe that is because xorg.conf is "properly" configured, and hal defaults to pc105/us :-), and you will notice that there is buggy code in config/hal.c. I don't remember the details, but if I recall correctly, after fixing it, the keyboard worked (no multiple events for every keypress and correct mapping), but the mouse still had the problems, as the hal/config.c would load a new instance of the mouse driver. >> For the moment, I disabled hal support in the Mandriva X Server >> a few days ago as I got no reply to the bugzilla above, but hope >> to work again on it in the next days. I did not finish the patch >> because it may be required some guessing, or some detail I am >> missing :-) that would allow mapping hal devices to xorg.conf >> devices, and then, code in the server would notice it and load >> only one driver for the device. > > The patch as it is is obviously extremely DDX-dependent, and thus breaks > KDrive and others horribly. We already have NewInputDeviceRequest, so > handling it in the DDX would be utterly trivial. Yes, it wasn't meant to be sent to upstream, but a possible way to fix the problem for the users, and also an exercise to understand the code. But I did not add it to Mandriva's X Server package because I knew it wasn't correct, and knew there were also problems with Kdrive that I still did not completely analyze neither fully understand. > Cheers, > Daniel Paulo From tapojoychatterjee at yahoo.co.in Tue Dec 18 06:23:28 2007 From: tapojoychatterjee at yahoo.co.in (Tapojoy chatterjee) Date: Tue, 18 Dec 2007 14:23:28 -0000 Subject: Fwd: Xephyr crashing on 8 bit connection attempt Message-ID: <93309.35010.qm@web7902.mail.in.yahoo.com> Hi when we use the command u specified it works ..only when we ask it connect it to XDM( provide an ip it crashes) u may try this to verify Xephyr :1 -ac -query localhost -once -screen 800x600x8 -fp /usr/share/X11/fonts/misc we are using Xorg -1.4 (7.3) and Xephyr is made from it....When we use a 7.2 based Xephyr it works on all systems..but it has that CAPSLOCK bug.. strace log is as shown below----- --------------------------------------------- execve("/bin/Xephyr", ["Xephyr", "-ac", "-query", "107.108.92.97", ":1", "-once", "-screen", "800x600x8", "-fp", "/usr/share/X11/fonts/misc/"], [/* 15 vars */]) = 0 brk(0) = 0x81a4000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbd000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libfontenc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libfontenc.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\r\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=19696, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbc000 mmap2(NULL, 23872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7fb6000 mmap2(0xb7fba000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xb7fba000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libpixman-1.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libpixman-1.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\'\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=193388, ...}) = 0 mmap2(NULL, 195080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f86000 mmap2(0xb7fb5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e) = 0xb7fb5000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libX11.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libX11.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\22"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=818784, ...}) = 0 mmap2(NULL, 822900, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ebd000 mmap2(0xb7f83000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc5) = 0xb7f83000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXext.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300&\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=52016, ...}) = 0 mmap2(NULL, 51132, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7eb0000 mmap2(0xb7ebc000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc) = 0xb7ebc000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libXfont.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libXfont.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\320"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=435856, ...}) = 0 mmap2(NULL, 482572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e3a000 mmap2(0xb7e9e000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x64) = 0xb7e9e000 mmap2(0xb7ea5000, 44300, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ea5000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libXau.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \n\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=7220, ...}) = 0 mmap2(NULL, 10164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e37000 mmap2(0xb7e39000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7e39000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\17\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=16452, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e36000 mmap2(NULL, 19384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e31000 mmap2(0xb7e35000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xb7e35000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3203\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=145188, ...}) = 0 mmap2(NULL, 147584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e0c000 mmap2(0xb7e2f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22) = 0xb7e2f000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/i586/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/cmov/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\33"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=26484, ...}) = 0 mmap2(NULL, 29236, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e04000 mmap2(0xb7e0a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7e0a000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20Z\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=1248904, ...}) = 0 mmap2(NULL, 1258876, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cd0000 mmap2(0xb7dfd000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12c) = 0xb7dfd000 mmap2(0xb7e01000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7e01000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\27\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=77808, ...}) = 0 mmap2(NULL, 80692, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cbc000 mmap2(0xb7ccf000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7ccf000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\f\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=9640, ...}) = 0 mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cb8000 mmap2(0xb7cba000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7cba000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libfreetype.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libfreetype.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\252\315"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=424488, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cb7000 mmap2(0xccc000, 421440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xccc000 mmap2(0xd2c000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x60) = 0xd2c000 close(3) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000K\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0777, st_size=67820, ...}) = 0 mmap2(NULL, 74204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ca4000 mmap2(0xb7cb3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7cb3000 mmap2(0xb7cb5000, 4572, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7cb5000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ca3000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ca3a30, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7dfd000, 8192, PROT_READ) = 0 set_tid_address(0xb7ca3a78) = 2812 rt_sigaction(SIGRTMIN, {0xb7ca8720, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb7ca8640, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfad1cf0, 40, (nil), 0}) = 0 geteuid32() = 0 getuid32() = 0 geteuid32() = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 brk(0) = 0x81a4000 brk(0x81c5000) = 0x81c5000 close(0) = 0 close(1) = 0 write(2, "", 0) = 0 getpgrp() = 2811 open("/tmp/.tX1-lock", O_WRONLY|O_CREAT|O_EXCL, 0644) = 0 write(0, " 2812\n", 11) = 11 fchmod(0, 0444) = 0 close(0) = 0 link("/tmp/.tX1-lock", "/tmp/.X1-lock") = -1 EEXIST (File exists) open("/tmp/.X1-lock", O_RDONLY) = 0 read(0, " 3390\n", 11) = 11 close(0) = 0 kill(3390, SIG_0) = -1 ESRCH (No such process) unlink("/tmp/.X1-lock") = 0 link("/tmp/.tX1-lock", "/tmp/.X1-lock") = 0 unlink("/tmp/.tX1-lock") = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 connect(0, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 fcntl64(0, F_SETFD, FD_CLOEXEC) = 0 access("/root/.Xauthority", R_OK) = -1 ENOENT (No such file or directory) writev(0, [{"l\0\v\0\0\0\0\0\0\0\0\0", 12}], 1) = 12 fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0 read(0, 0xbfad0d34, 8) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0\v\0\0\0?\0", 8) = 8 read(0, "\0\261\236\0\0\0@\1\377\377\37\0\0\1\0\0\24\0\377\377\1"..., 252) = 252 write(0, "7\0\5\0\0\0@\1=\0\0\0\10\0\0\0\377\377\377\0b\0\5\0\f\0"..., 64) = 64 read(0, 0xbfad0cf4, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\2\0\0\0\0\0\1\203\0\0\1\0\0\0\0\0\0\0\0\0\0\0\340"..., 32) = 32 read(0, "\1\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 write(0, "\203\0\1\0", 4) = 4 read(0, 0xbfad0c98, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1b\4\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\\\341"..., 32) = 32 writev(0, [{"b\0\5\0\t\0@\1", 8}, {"XKEYBOARD", 9}, {"\0\0\0", 3}], 3) = 20 read(0, 0xbfad0b4c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\5\0\0\0\0\0\1\224_\252\0\20\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 write(0, "\224\0\2\0\1\0\0\0", 8) = 8 read(0, 0xbfad0bec, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\1\6\0\0\0\0\0\1\0\0\0h\341\224\277\'\264\23\10(b3\10"..., 32) = 32 write(0, "7\0\4\0\1\0@\1=\0\0\0\0\0\0\0\1\0\t\0\2\0@\1=\0\0\0\0\0"..., 164) = 164 read(0, 0xbfad0a30, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 write(0, "\20\1\t\0\31\0@\1XDCCC_LINEAR_RGB_MATRICE"..., 36) = 36 read(0, 0xbfad0a30, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\v\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 stat64("/usr/lib/X11/Xcms.txt", 0xbfad07c0) = -1 ENOENT (No such file or directory) write(0, "\\\1\4\0 \0\0\0\3\0CCredI", 16) = 16 read(0, 0xbfad0d38, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\f\0\0\0\0\0\377\377\0\0\0\0\377\377\0\0\0\0\0\0"..., 32) = 32 write(0, "T\1\4\0 \0\0\0\377\377\0\0\0\0dI", 16) = 16 read(0, 0xbfad0d3c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\r\0\0\0\0\0\377\377\0\0\0\0\0\0\0\0\377\0\0\0\0"..., 32) = 32 futex(0xb7cbb070, FUTEX_WAKE, 2147483647) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXcursor.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXcursor.so.1", O_RDONLY) = 1 read(1, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\"\0"..., 512) = 512 fstat64(1, {st_mode=S_IFREG|0644, st_size=32536, ...}) = 0 mmap2(NULL, 35432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 1, 0) = 0xb7c9a000 mmap2(0xb7ca2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 1, 0x7) = 0xb7ca2000 close(1) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXrender.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXrender.so.1", O_RDONLY) = 1 read(1, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\23"..., 512) = 512 fstat64(1, {st_mode=S_IFREG|0644, st_size=28420, ...}) = 0 mmap2(NULL, 31368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 1, 0) = 0xb7c92000 mmap2(0xb7c99000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 1, 0x6) = 0xb7c99000 close(1) = 0 open("/home/friend/pixman/lib/tls/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/tls/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/friend/pixman/lib/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/tls/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/ICAClient/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i586/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/cmov/libXfixes.so.3", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libXfixes.so.3", O_RDONLY) = 1 read(1, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\17\0\000"..., 512) = 512 fstat64(1, {st_mode=S_IFREG|0755, st_size=13308, ...}) = 0 mmap2(NULL, 16168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 1, 0) = 0xb7c8e000 mmap2(0xb7c91000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 1, 0x2) = 0xb7c91000 close(1) = 0 writev(0, [{"5\1\4\0\3\0@\1=\0\0\0\1\0\1\0bE\4\0\6\0GB", 24}, {"RENDER", 6}, {"\0\0", 2}], 3) = 32 read(0, 0xbfad0b9c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\17\0\0\0\0\0\1\232\0\257\0\20\0\0\0\0\0\0\0\0\0"..., 32) = 32 write(0, "\232\0\3\0\0\0\0\0\n\0\0\0\232\1\1\0", 16) = 16 read(0, 0xbfad0c10, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0\20\0\0\0\0\0\0\0\0\0\n\0\0\0(b3\10H/\37\10\1\0\0\0"..., 32) = 32 read(0, "\1\263\21\0\257\0\0\0\26\0\0\0\1\0\0\0\7\0\0\0\2\0\0\0"..., 32) = 32 read(0, "\"\0\0\0\1\1 \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0"..., 700) = 700 open("/root/.Xdefaults", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=322, ...}) = 0 read(1, "XtDesk*Form*font: -adobe-helveti"..., 322) = 322 close(1) = 0 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=75128, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.a"..., 4096) = 4096 read(1, "R.iso885914\t\t\t\tbr_FR.ISO8859-14\n"..., 4096) = 4096 read(1, "ISO8859-1\nen.ISO-8859-1\t\t\t\t\ten_U"..., 4096) = 4096 read(1, "iso885915\t\t\t\tes_ES.ISO8859-15\nes"..., 4096) = 4096 read(1, "59-15\nfr_CA.ISO-8859-15\t\t\t\tfr_CA"..., 4096) = 4096 read(1, "59-1\nit_IT.iso88591\t\t\t\t\tit_IT.IS"..., 4096) = 4096 read(1, "\t\t\tnl_BE.ISO8859-15\nnl_BE at euro\t\t"..., 4096) = 4096 read(1, "K.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2\n"..., 4096) = 4096 read(1, "\t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\twa"..., 4096) = 4096 read(1, "us locale names\nISO8859-1\t\t\t\t\ten"..., 4096) = 4096 read(1, "O8859-5\nbg_BG.koi8r:\t\t\t\t\tbg_BG.K"..., 4096) = 4096 read(1, "\t\t\tde_LU.UTF-8\nGER_DE.8859:\t\t\t\t\t"..., 4096) = 4096 read(1, "1\nes_CR.utf8:\t\t\t\t\tes_CR.UTF-8\nes"..., 4096) = 4096 read(1, "fr_BE:\t\t\t\t\t\tfr_BE.ISO8859-1\nfr_B"..., 4096) = 4096 read(1, "8859-2\n# in was the old ISO code"..., 4096) = 4096 read(1, "mk_MK.CP1251\nmk_MK.utf8:\t\t\t\t\tmk_"..., 4096) = 4096 read(1, "SO8859-2\nro_RO.utf8:\t\t\t\t\tro_RO.U"..., 4096) = 4096 read(1, "O8859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UT"..., 4096) = 4096 read(1, "SO8859-8\nhrvatski:\t\t\t\t\thr_HR.ISO"..., 4096) = 1400 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=32294, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.d"..., 4096) = 4096 read(1, "so8859-1/XLC_LOCALE\t\t\tes_UY.ISO8"..., 4096) = 4096 read(1, "CALE\t\t\tsr_YU.ISO8859-5\nmicrosoft"..., 4096) = 4096 read(1, "XLC_LOCALE\t\t\tes_PE.UTF-8\nen_US.U"..., 4096) = 4096 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/lib/X11/locale/locale.alias", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=75128, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.a"..., 4096) = 4096 read(1, "R.iso885914\t\t\t\tbr_FR.ISO8859-14\n"..., 4096) = 4096 read(1, "ISO8859-1\nen.ISO-8859-1\t\t\t\t\ten_U"..., 4096) = 4096 read(1, "iso885915\t\t\t\tes_ES.ISO8859-15\nes"..., 4096) = 4096 read(1, "59-15\nfr_CA.ISO-8859-15\t\t\t\tfr_CA"..., 4096) = 4096 read(1, "59-1\nit_IT.iso88591\t\t\t\t\tit_IT.IS"..., 4096) = 4096 read(1, "\t\t\tnl_BE.ISO8859-15\nnl_BE at euro\t\t"..., 4096) = 4096 read(1, "K.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2\n"..., 4096) = 4096 read(1, "\t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\twa"..., 4096) = 4096 read(1, "us locale names\nISO8859-1\t\t\t\t\ten"..., 4096) = 4096 read(1, "O8859-5\nbg_BG.koi8r:\t\t\t\t\tbg_BG.K"..., 4096) = 4096 read(1, "\t\t\tde_LU.UTF-8\nGER_DE.8859:\t\t\t\t\t"..., 4096) = 4096 read(1, "1\nes_CR.utf8:\t\t\t\t\tes_CR.UTF-8\nes"..., 4096) = 4096 read(1, "fr_BE:\t\t\t\t\t\tfr_BE.ISO8859-1\nfr_B"..., 4096) = 4096 read(1, "8859-2\n# in was the old ISO code"..., 4096) = 4096 read(1, "mk_MK.CP1251\nmk_MK.utf8:\t\t\t\t\tmk_"..., 4096) = 4096 read(1, "SO8859-2\nro_RO.utf8:\t\t\t\t\tro_RO.U"..., 4096) = 4096 read(1, "O8859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UT"..., 4096) = 4096 read(1, "SO8859-8\nhrvatski:\t\t\t\t\thr_HR.ISO"..., 4096) = 1400 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/lib/X11/locale/locale.dir", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=32294, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.d"..., 4096) = 4096 read(1, "so8859-1/XLC_LOCALE\t\t\tes_UY.ISO8"..., 4096) = 4096 read(1, "CALE\t\t\tsr_YU.ISO8859-5\nmicrosoft"..., 4096) = 4096 read(1, "XLC_LOCALE\t\t\tes_PE.UTF-8\nen_US.U"..., 4096) = 4096 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/share/X11/locale/C/XI18N_OBJS", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=241, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "# CATEGORY(XLC|XIM|OM)\tSHARED_LI"..., 4096) = 241 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/lib/X11/locale/C/XI18N_OBJS", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=241, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c8d000 read(1, "# CATEGORY(XLC|XIM|OM)\tSHARED_LI"..., 4096) = 241 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c8d000, 4096) = 0 open("/usr/share/X11/locale/common/xlibi18n.so.2", O_RDONLY) = 1 read(1, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) = 512 fstat64(1, {st_mode=S_IFREG|0644, st_size=18980, ...}) = 0 mmap2(NULL, 21868, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 1, 0) = 0xb7c88000 mmap2(0xb7c8d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 1, 0x4) = 0xb7c8d000 close(1) = 0 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=75128, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c87000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.a"..., 4096) = 4096 read(1, "R.iso885914\t\t\t\tbr_FR.ISO8859-14\n"..., 4096) = 4096 read(1, "ISO8859-1\nen.ISO-8859-1\t\t\t\t\ten_U"..., 4096) = 4096 read(1, "iso885915\t\t\t\tes_ES.ISO8859-15\nes"..., 4096) = 4096 read(1, "59-15\nfr_CA.ISO-8859-15\t\t\t\tfr_CA"..., 4096) = 4096 read(1, "59-1\nit_IT.iso88591\t\t\t\t\tit_IT.IS"..., 4096) = 4096 read(1, "\t\t\tnl_BE.ISO8859-15\nnl_BE at euro\t\t"..., 4096) = 4096 read(1, "K.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2\n"..., 4096) = 4096 read(1, "\t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\twa"..., 4096) = 4096 read(1, "us locale names\nISO8859-1\t\t\t\t\ten"..., 4096) = 4096 read(1, "O8859-5\nbg_BG.koi8r:\t\t\t\t\tbg_BG.K"..., 4096) = 4096 read(1, "\t\t\tde_LU.UTF-8\nGER_DE.8859:\t\t\t\t\t"..., 4096) = 4096 read(1, "1\nes_CR.utf8:\t\t\t\t\tes_CR.UTF-8\nes"..., 4096) = 4096 read(1, "fr_BE:\t\t\t\t\t\tfr_BE.ISO8859-1\nfr_B"..., 4096) = 4096 read(1, "8859-2\n# in was the old ISO code"..., 4096) = 4096 read(1, "mk_MK.CP1251\nmk_MK.utf8:\t\t\t\t\tmk_"..., 4096) = 4096 read(1, "SO8859-2\nro_RO.utf8:\t\t\t\t\tro_RO.U"..., 4096) = 4096 read(1, "O8859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UT"..., 4096) = 4096 read(1, "SO8859-8\nhrvatski:\t\t\t\t\thr_HR.ISO"..., 4096) = 1400 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c87000, 4096) = 0 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=32294, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c87000 read(1, "#\t$XdotOrg: lib/X11/nls/locale.d"..., 4096) = 4096 read(1, "so8859-1/XLC_LOCALE\t\t\tes_UY.ISO8"..., 4096) = 4096 read(1, "CALE\t\t\tsr_YU.ISO8859-5\nmicrosoft"..., 4096) = 4096 read(1, "XLC_LOCALE\t\t\tes_PE.UTF-8\nen_US.U"..., 4096) = 4096 close(1) = 0 munmap(0xb7c87000, 4096) = 0 access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0 open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 1 fstat64(1, {st_mode=S_IFREG|0644, st_size=772, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c87000 read(1, "# $Xorg: C,v 1.3 2000/08/17 19:"..., 4096) = 772 read(1, "", 4096) = 0 close(1) = 0 munmap(0xb7c87000, 4096) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 open("/root/.Xdefaults-OEM000F00480CB8", O_RDONLY) = -1 ENOENT (No such file or directory) writev(0, [{"]\0\10\0\4\0@\1\3\0@\1\3\0@\1\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 64}, {"MIT-SHM", 7}, {"\0", 1}], 3) = 72 read(0, 0xbfad0c8c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\264\25\0\0\0\0\0\1\221N\244\2\0\0\300\4\0\0\0\0\0\0"..., 32) = 32 shmget(IPC_PRIVATE, 1, IPC_CREAT|0777) = 4587574 shmat(4587574, 0, 0) = 0xb7c87000 write(0, "\221\1\4\0\5\0@\0016\0F\0\1\0@\1+\0\1\0", 20) = 20 read(0, 0xbfad0d40, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0\27\0\0\0\0\0\16\0`\1\0\0\0\0\0\0\0\0X\341\224\277"..., 32) = 32 shmdt(0xb7c87000) = 0 shmctl(4587574, IPC_64|IPC_RMID, 0) = 0 rt_sigaction(SIGALRM, {0x8161ad0, [ALRM], 0}, NULL, 8) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol) write(2, "_XSERVTrans", 11) = 11 write(2, "SocketOpenCOTSServer: Unable to "..., 54) = 54 write(2, "_XSERVTrans", 11) = 11 write(2, "Open: transport open failed for "..., 56) = 56 write(2, "_XSERVTrans", 11) = 11 write(2, "MakeAllCOTSServerListeners: fail"..., 62) = 62 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 1 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 setsockopt(1, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(1, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(1, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 setsockopt(1, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0 listen(1, 128) = 0 getsockname(1, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 uname({sys="Linux", node="OEM000F00480CB8", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 umask(0) = 022 lstat64("/tmp/.X11-unix", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=80, ...}) = 0 unlink("/tmp/.X11-unix/X1") = 0 bind(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X1"}, 19) = 0 listen(3, 128) = 0 umask(022) = 0 socket(PF_NETLINK, SOCK_RAW, 0) = 4 bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(4, {sa_family=AF_NETLINK, pid=2812, groups=00000000}, [12]) = 0 time(NULL) = 1198005935 sendto(4, "\24\0\0\0\22\0\1\3\257\36hG\0\0\0\0\0\342\331\267", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\364\0\0\0\20\0\2\0\257\36hG\374\n\0\0\0\0\4\3\1\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 496 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\257\36hG\374\n\0\0\0\0\0\0\1\0\0\0I\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 sendto(4, "\24\0\0\0\26\0\1\3\260\36hG\0\0\0\0\0\342\331\267", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"<\0\0\0\24\0\2\0\260\36hG\374\n\0\0\2\10\200\376\1\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\260\36hG\374\n\0\0\0\0\0\0\1\0\0\0\10"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(4) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {0x8161550, [HUP], 0}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x8161500, [INT], 0}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8161500, [TERM], 0}, {SIG_DFL}, 8) = 0 open("/etc/X1.hosts", O_RDONLY) = -1 ENOENT (No such file or directory) rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR1, {SIG_DFL}, {SIG_IGN}, 8) = 0 getppid() = 2811 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol) write(2, "XDMCP warning: INET6 UDP socket "..., 48) = 48 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 sendto(4, "\0\1\0\2\0\1\0", 7, 0, {sa_family=AF_INET, sin_port=htons(177), sin_addr=inet_addr("107.108.92.97")}, 16) = 7 clock_gettime(CLOCK_MONOTONIC, {13629, 637915659}) = 0 clock_gettime(CLOCK_MONOTONIC, {13629, 638165663}) = 0 rt_sigaction(SIGUSR1, {0x8054b60, [USR1], 0}, {SIG_DFL}, 8) = 0 shmget(IPC_PRIVATE, 1920000, IPC_CREAT|0777) = 4620346 shmat(4620346, 0, 0) = 0xb7ab3000 write(0, "\221\1\4\0\6\0@\1:\200F\0\0\0@\1\f\0\5\0\2\0@\1\f\0\0\0"..., 144) = 144 read(0, 0xbfad1cf0, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0\34\0\0\0\0\0\16\0`\1\0\0\0\0\0\0\0\0X\341\224\277"..., 32) = 32 mmap2(NULL, 483328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a3d000 rt_sigaction(SIGSEGV, {0x8090d00, [SEGV], SA_RESTART}, {SIG_DFL}, 8) = 0 clock_gettime(CLOCK_MONOTONIC, {13629, 660851180}) = 0 clock_gettime(CLOCK_MONOTONIC, {13629, 660923983}) = 0 open("/home/friend/xorg_7.3/lib/xserver/SecurityPolicy", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "error opening security policy fi"..., 84) = 84 time(NULL) = 1198005935 brk(0x81ec000) = 0x81ec000 open("/home/friend/xorg_7.4/var/lib/X11/xkb/rules/base", O_RDONLY) = -1 ENOENT (No such file or directory) clock_gettime(CLOCK_MONOTONIC, {13631, 800375331}) = 0 write(0, "e\1\2\0\10\370@\1", 8) = 8 read(0, 0xbfad1c6c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\fv\34\0\2\0@\1\0\1\0\0 \2\217\0\1\0 \10\30v3\10x\337\224"..., 32) = 32 read(0, "\f\0\34\0\2\0@\1\0\0\217\0 \3\311\1\0\0\34\10\3602 \10"..., 32) = 32 read(0, "\f\0\34\0\2\0@\1\0\0\0\0\0\1\217\0\0\0\34\10\3602 \10("..., 32) = 32 read(0, 0xbfad1c6c, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\4\35\0\340\3\0\0\1\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\33\377\0\0\33\377\0\0"..., 3968) = 3968 open("/home/friend/xorg_7.4/var/lib/X11/xkb/rules/base", O_RDONLY) = -1 ENOENT (No such file or directory) brk(0x820d000) = 0x820d000 open("/usr/share/X11/fonts/misc/fonts.dir", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0555, st_size=525, ...}) = 0 fstat64(5, {st_mode=S_IFREG|0555, st_size=525, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a3c000 read(5, "8\n6x13.pcf.gz -misc-fixed-medium"..., 4096) = 525 read(5, "", 4096) = 0 read(5, "", 4096) = 0 close(5) = 0 munmap(0xb7a3c000, 4096) = 0 open("/usr/share/X11/fonts/misc/fonts.alias", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0755, st_size=710, ...}) = 0 fstat64(5, {st_mode=S_IFREG|0755, st_size=710, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a3c000 read(5, "! $XConsortium: fonts.alias,v 1."..., 4096) = 710 read(5, "", 4096) = 0 close(5) = 0 munmap(0xb7a3c000, 4096) = 0 open("/proc/meminfo", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a3c000 read(5, "MemTotal: 101400 kB\nMemFre"..., 1024) = 676 close(5) = 0 munmap(0xb7a3c000, 4096) = 0 open("/usr/share/X11/fonts/misc/7x14.pcf.gz", O_RDONLY) = 5 read(5, "\37\213\10\0\240EuA\0\3\354\334etUg\233\6\340\35\332\357"..., 8192) = 8192 read(5, "\376\344\362P\347\17\374\265\315\374\353]g\337\304\274"..., 8192) = 8192 brk(0x8233000) = 0x8233000 mmap2(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7a1b000 read(5, "\32\345\375S\235\247r\273\375R:\303\332=\302\362\276(*"..., 8192) = 8192 read(5, "Ew\347\202\312\334\32rw\27M\276\367\356*\231\204\0247{"..., 8192) = 8192 read(5, "\25\374\251\340O\5\177*\370S\301\237\n\376T\360\247\202"..., 8192) = 8192 read(5, "\304\311\3468\251\352\3748\206}\222]\262\341\322\35[;\326"..., 8192) = 2402 read(5, "", 8192) = 0 close(5) = 0 open("/usr/share/X11/fonts/misc/cursor.pcf.gz", O_RDONLY) = 5 read(5, "\37\213\10\0000\332\3038\0\3\355\233\177pT\327u\307\317"..., 8192) = 5097 read(5, "", 8192) = 0 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0 clock_gettime(CLOCK_MONOTONIC, {13631, 889487213}) = 0 clock_gettime(CLOCK_MONOTONIC, {13631, 889559619}) = 0 clock_gettime(CLOCK_MONOTONIC, {13631, 889646851}) = 0 ioctl(0, FIONREAD, [0]) = 0 write(0, "8\1\4\0\1\0@\1\4\0\0\0\0\0\377\0\221\3\n\0\2\0@\1\1\0@"..., 60) = 60 read(0, 0xbfad1600, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0 \0\0\0\0\0\2\0@\1\0\0\0\0\0\0\0\0X\341\224\277\\8"..., 32) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 14554957}) = 0 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\0\0\0\0 \3X\2\0\0\0\0\30"..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0\"\0\0\0\0\0\2\0@\1\0\0\0\0\0\0\0\0X\341\224\277\\"..., 32) = 32 select(256, [1 3 4], NULL, NULL, {0, 0}) = 1 (in [4], left {0, 0}) recvfrom(4, "\0\1\0\5\0002\0\0\0\25localhost.localdomain\0"..., 8192, 0, {sa_family=AF_INET, sin_port=htons(177), sin_addr=inet_addr("107.108.92.97")}, [16]) = 56 sendto(4, "\0\1\0\7\0Q\0\1\1\0\0\1\0\4kl\\2\0\0\0\0\3\0\22MIT-MAG"..., 87, 0, {sa_family=AF_INET, sin_port=htons(177), sin_addr=inet_addr("107.108.92.97")}, 16) = 87 clock_gettime(CLOCK_MONOTONIC, {13632, 124637838}) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 124790051}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 124874356}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 125025137}) = 0 select(256, [1 3 4], NULL, NULL, {0, 20000}) = 1 (in [4], left {0, 20000}) recvfrom(4, "\0\1\0\10\0.\0\20\236\251\0\0\0\0\0\22MIT-MAGIC-COOKIE"..., 8192, 0, {sa_family=AF_INET, sin_port=htons(177), sin_addr=inet_addr("107.108.92.97")}, [16]) = 52 sendto(4, "\0\1\0\n\0\27\0\20\236\251\0\1\0\17MIT-unspecified", 29, 0, {sa_family=AF_INET, sin_port=htons(177), sin_addr=inet_addr("107.108.92.97")}, 16) = 29 clock_gettime(CLOCK_MONOTONIC, {13632, 126152502}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 126221074}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 126287086}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 126426508}) = 0 select(256, [1 3 4], NULL, NULL, {0, 20000}) = 1 (in [1], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 129423876}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 129503236}) = 0 accept(1, {sa_family=AF_INET, sin_port=htons(39762), sin_addr=inet_addr("107.108.92.97")}, [16]) = 5 setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("107.108.92.50")}, [16]) = 0 getpeername(5, {sa_family=AF_INET, sin_port=htons(39762), sin_addr=inet_addr("107.108.92.97")}, [16]) = 0 fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 130478556}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 130623733}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 130863460}) = 0 read(5, "l\0\v\0\0\0\22\0\20\0\0\0MIT-MAGIC-COOKIE-1\0\0"..., 4092) = 48 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 131139925}) = 0 select(256, [1 3 4], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 131319984}) = 0 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\0\v\0\0\0W\0\0\261\236\0\0\0 \0\377\377\37\0\0\1\0\0"..., 356}], 1) = 356 clock_gettime(CLOCK_MONOTONIC, {13632, 131721222}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 131910898}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 132186059}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 132249686}) = 0 read(5, "7\0\6\0\0\0 \0H\0\0\0\f\0\0\0\1\0\0\0\0\0\0\0b\0\5\0\f"..., 4096) = 68 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\353\2\0\0\0\0\0\1\205\0\0\2\0\0\0\0\0\0\0\0\0\0\0(\35"..., 64}], 1) = 64 clock_gettime(CLOCK_MONOTONIC, {13632, 132783448}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 132965812}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 133202691}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 133266328}) = 0 read(5, "\205\0\1\0", 4096) = 4 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1u\4\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\34\32"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 133711741}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 133892168}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 134128794}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 134192467}) = 0 read(5, "b\0\5\0\t\0 \0XKEYBOARD\0\0\0", 4096) = 20 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\353\5\0\0\0\0\0\1\213X\224\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 134632588}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 134811181}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 135062788}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 135126122}) = 0 read(5, "\213\0\2\0\1\0\0\0", 4096) = 8 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\1\6\0\0\0\0\0\1\0\0\0(\32\255\277\367\353\r\10(u\37"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 135546498}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 135685098}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 136266902}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 136331381}) = 0 read(5, "-\0\5\0\1\0 \0\6\0\0\0cursor\0\0b\0\4\0\6\0\5\0REND"..., 4096) = 36 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\353\10\0\0\0\0\0\1\226\0\233\0\0\0\0\6\0\0\0\\w\37\10"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 136832106}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 137015775}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 137253430}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 137317095}) = 0 read(5, "\226\0\3\0\0\0\0\0\n\0\0\0\226\1\1\0", 4096) = 16 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\0\t\0\0\0\0\0\0\0\0\0\n\0\0\0(u\37\10\330\200\33\10"..., 936}], 1) = 936 clock_gettime(CLOCK_MONOTONIC, {13632, 137804911}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 137956419}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 142985791}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 143050642}) = 0 read(5, "5 \4\0\2\0 \0H\0\0\0\'\0\32\0007r\4\0\3\0 \0\2\0 \0\0\0"..., 4096) = 2896 read(5, "4\16\0U6\16\0]C\22\0r\223C\0\316\273]\0\372\277_\0\377"..., 1232) = 1232 read(5, "\2\0 \0*\0\0\0\0\0\0\0006\0\2\0\2\0 \0\226\33\4\0\5\0 "..., 4088) = 4088 read(5, "\5\1\0\t\6\1\0\n\3\0\0\5\0\0\0\1\2\0\0\4\0\0\0\1\0\0\0"..., 84) = 84 read(5, "\6\0 \0*\0\0\0\0\0\0\0006\0\2\0\6\0 \0\226\33\4\0\t\0 "..., 4088) = 4088 read(5, "\0\0\0\0\1\0\0\2\1\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 84) = 84 read(5, "\n\0 \0*\0\0\0\0\0\0\0006\0\2\0\n\0 \0\226\33\4\0\r\0 "..., 4088) = 4088 read(5, "\5\1\0\10\3\1\0\6\3\1\0\6\3\1\0\6\0\0\0\0\1\0\0\2\0\0\0"..., 84) = 84 read(5, "\16\0 \0*\0\0\0\0\0\0\0006\0\2\0\16\0 \0\226\33\4\0\21"..., 4088) = 4088 read(5, "\0\0\0\0\0\0\0\1\1\0\0\2\1\0\0\2\0\0\0\0\0\0\0\1\1\0\0"..., 84) = 84 read(5, "\22\0 \0*\0\0\0\0\0\0\0006\0\2\0\22\0 \0\226\33\4\0\25"..., 4088) = 4088 read(5, "\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\2\0\0\0\0\0\0\0"..., 84) = 84 read(5, "\26\0 \0*\0\0\0\0\0\0\0006\0\2\0\26\0 \0\226\33\4\0\31"..., 4088) = 4088 read(5, "\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 84) = 84 read(5, "\32\0 \0*\0\0\0\0\0\0\0006\0\2\0\32\0 \0\226\33\4\0\35"..., 4088) = 4088 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 84) = 84 read(5, "\36\0 \0*\0\0\0\0\0\0\0006\0\2\0\36\0 \0\226\33\4\0!\0"..., 4088) = 4088 read(5, "\5\1\0\t\3\1\0\6\5\1\0\10\10\2\0\r\10\2\0\r\2\0\0\4\2\0"..., 84) = 84 read(5, "\"\0 \0*\0\0\0\0\0\0\0006\0\2\0\"\0 \0\226\33\4\0%\0 \0"..., 4088) = 4088 read(5, "\v\3\0\22\7\2\0\f\7\2\0\v\5\1\0\t\1\0\0\2\3\1\0\6\3\1\0"..., 84) = 84 read(5, "&\0 \0*\0\0\0\0\0\0\0006\0\2\0&\0 \0\226\33\4\0)\0 \0("..., 4088) = 4088 read(5, "\7\2\0\v\3\0\0\5\5\1\0\t\10\2\0\r\5\1\0\10\4\1\0\7\1\0"..., 84) = 84 --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 153759394}) = 0 select(256, [1 3 4], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 153954411}) = 0 read(5, "*\0 \0*\0\0\0\0\0\0\0006\0\2\0*\0 \0\226\33\4\0-\0 \0,"..., 4088) = 4088 read(5, "\6\1\0\n\2\0\0\4\0\0\0\0\0\0\0\0\1\0\0\2\1\0\0\3\1\0\0"..., 84) = 84 read(5, ".\0 \0*\0\0\0\0\0\0\0006\0\2\0.\0 \0\226\33\4\0001\0 \000"..., 4088) = 260 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\353x\0\0\0\0\0\1\225Z\232\5\0\0\0\4\0\0\0\226\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 155843410}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 156042457}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 156286564}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 156350952}) = 0 read(5, "\225\0\3\0\3\0\0\0\0\0\0\0", 4096) = 12 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\365y\0\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\32\255"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 156800329}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 156938814}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 157218556}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 157282035}) = 0 read(5, "\225\27\5\0002\0 \0\5\0\0\0watch\0 \0\2\0\4\0H\0\0\0\0"..., 4096) = 48 clock_gettime(CLOCK_MONOTONIC, {13632, 158142638}) = 0 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\0}\0\0\0\0\0\1\0\0\0(u\37\10\0\0\0\0\30\32\255\277\354"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 158522061}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 158588226}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 158786652}) = 0 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\201\1\35\1 \0\r\0\201\1"..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0$\0\0\0\0\0\2\0@\1\0\0\0\0\30v3\10X\341\224\277\\8"..., 32) = 32 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\201\1*\1-\0\23\0\201\1*"..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0&\0\0\0\0\0\2\0@\1\0\0\0\0\30v3\10X\341\224\277\\8"..., 32) = 32 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\207\1=\1\'\0\7\0\207\1="..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0(\0\0\0\0\0\2\0@\1\0\0\0\0\30v3\10X\341\224\277\\8"..., 32) = 32 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 161155361}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 161220775}) = 0 read(5, "b\27\4\0\10\0 \0XINERAMA", 4096) = 16 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\353~\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 161701642}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 161819377}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 161964669}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [5], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 162201296}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 162265015}) = 0 read(5, "+\27\1\0", 4096) = 4 read(5, 0x81f7750, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(5, [{"\1\0\177\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\30\32\255\277"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 162682090}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 162747042}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 162882860}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 1 (in [1], left {0, 10000}) clock_gettime(CLOCK_MONOTONIC, {13632, 169382411}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 169448226}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 169599178}) = 0 accept(1, {sa_family=AF_INET, sin_port=htons(39763), sin_addr=inet_addr("107.108.92.97")}, [16]) = 6 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 getsockname(6, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("107.108.92.50")}, [16]) = 0 getpeername(6, {sa_family=AF_INET, sin_port=htons(39763), sin_addr=inet_addr("107.108.92.97")}, [16]) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 170508478}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 170575111}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 170721047}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 170963591}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 171026702}) = 0 read(6, "l\0\v\0\0\0\22\0\20\0\0\0MIT-MAGIC-COOKIE-1\0\0"..., 4092) = 48 clock_gettime(CLOCK_MONOTONIC, {13632, 171229465}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 171364806}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 171546895}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\v\0\0\0W\0\0\261\236\0\0\0@\0\377\377\37\0\0\1\0\0"..., 356}], 1) = 356 clock_gettime(CLOCK_MONOTONIC, {13632, 171918620}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 172067211}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 172209435}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 172448686}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 172512060}) = 0 read(6, "7\0\6\0\0\0@\0H\0\0\0\f\0\0\0\1\0\0\0\0\0\0\0b\0\5\0\f"..., 4096) = 68 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\2\0\0\0\0\0\1\205\0\0\2\0\0\0\0\0\0\0\0\0\0\0(\35"..., 64}], 1) = 64 clock_gettime(CLOCK_MONOTONIC, {13632, 173029252}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 173136281}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 173273554}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) clock_gettime(CLOCK_MONOTONIC, {13632, 173777924}) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 173917490}) = 0 read(6, "\205\0\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1l\4\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\34\32"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 174343301}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 174449266}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 174586818}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 174826165}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 174889618}) = 0 read(6, "b\0\5\0\t\0@\0XKEYBOARD\0\0\0", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\5\0\0\0\0\0\1\213X\224\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 175330513}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 175435459}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 175572033}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 175810262}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 175873776}) = 0 read(6, "\213\0\2\0\1\0\0\0", 4096) = 8 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\1\6\0\0\0\0\0\1\0\0\0(\32\255\277\367\353\r\10\0l\37"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 176310698}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 176375303}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 176552435}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 176792057}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 176855417}) = 0 read(6, "c\0\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\32\7\0I\0\0\0\0l\37\10\1\0\0\0\0\20\0\0\0\0\0\0\0\0"..., 324}], 1) = 324 clock_gettime(CLOCK_MONOTONIC, {13632, 177316459}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 177381644}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 177518563}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 193531726}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 193602523}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 193665616}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 193729887}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 193875073}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 200175327}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 200240371}) = 0 read(6, "\22\0\24\0H\0\0\0\27\0\0\0\37\0\0\0\10\0\0\0008\0\0\0X"..., 4096) = 92 clock_gettime(CLOCK_MONOTONIC, {13632, 200469366}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\n\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\30\32\255\277"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 200873907}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 200983946}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 201127891}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 18000}) = 1 (in [6], left {0, 18000}) clock_gettime(CLOCK_MONOTONIC, {13632, 201370229}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 201433915}) = 0 read(6, "", 4096) = 0 shutdown(6, 2 /* send and receive */) = 0 close(6) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 201897589}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 201966203}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 202104582}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 17000}) = ? ERESTARTNOHAND (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) clock_gettime(CLOCK_MONOTONIC, {13632, 203760452}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 203825207}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 203887636}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 203950977}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 204087170}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 15000}) = 1 (in [1], left {0, 15000}) clock_gettime(CLOCK_MONOTONIC, {13632, 206753917}) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 206977479}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 207049747}) = 0 accept(1, {sa_family=AF_INET, sin_port=htons(39764), sin_addr=inet_addr("107.108.92.97")}, [16]) = 6 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 getsockname(6, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("107.108.92.50")}, [16]) = 0 getpeername(6, {sa_family=AF_INET, sin_port=htons(39764), sin_addr=inet_addr("107.108.92.97")}, [16]) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 207876768}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 207941643}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 208082490}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 11000}) = 1 (in [6], left {0, 11000}) clock_gettime(CLOCK_MONOTONIC, {13632, 208339745}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 208403420}) = 0 read(6, "l\0\v\0\0\0\22\0\20\0\0\0MIT-MAGIC-COOKIE-1\0\0"..., 4092) = 48 clock_gettime(CLOCK_MONOTONIC, {13632, 208605948}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 208741268}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 208923417}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\v\0\0\0W\0\0\261\236\0\0\0@\0\377\377\37\0\0\1\0\0"..., 356}], 1) = 356 clock_gettime(CLOCK_MONOTONIC, {13632, 209293843}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 209439004}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 209579148}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 9000}) = 1 (in [6], left {0, 9000}) clock_gettime(CLOCK_MONOTONIC, {13632, 209818771}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 209881787}) = 0 read(6, "7\0\6\0\0\0@\0H\0\0\0\f\0\0\0\1\0\0\0\0\0\0\0b\0\5\0\f"..., 4096) = 68 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\2\0\0\0\0\0\1\205\0\0\2\0\0\0\0\0\0\0\0\0\0\0(\35"..., 120}], 1) = 120 clock_gettime(CLOCK_MONOTONIC, {13632, 210400581}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 210505723}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 210644020}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 8000}) = 1 (in [6], left {0, 8000}) clock_gettime(CLOCK_MONOTONIC, {13632, 210883325}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 210946868}) = 0 read(6, "\205\0\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1l\4\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\34\32"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 211366772}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 211470677}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 211607920}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 7000}) = 1 (in [6], left {0, 7000}) clock_gettime(CLOCK_MONOTONIC, {13632, 211846245}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 211909931}) = 0 read(6, "b\0\5\0\t\0@\0XKEYBOARD\0\0\0", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\5\0\0\0\0\0\1\213X\224\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 212349758}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 212454314}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 212591338}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 6000}) = 1 (in [6], left {0, 6000}) clock_gettime(CLOCK_MONOTONIC, {13632, 212830141}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 212893674}) = 0 read(6, "\213\0\2\0\1\0\0\0", 4096) = 8 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\1\6\0\0\0\0\0\1\0\0\0(\32\255\277\367\353\r\10\0l\37"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 213315156}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 213442524}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 213581219}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 5000}) = 1 (in [6], left {0, 5000}) clock_gettime(CLOCK_MONOTONIC, {13632, 213820230}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 213883880}) = 0 read(6, "w\0\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\7\0\0\0\0\0\1\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 214306386}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 214371348}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 214548580}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 4000}) = 1 (in [6], left {0, 4000}) clock_gettime(CLOCK_MONOTONIC, {13632, 214799584}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 214863573}) = 0 read(6, "<\0\2\0\0\0@\0+\0\1\0", 4096) = 12 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\t\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\30\32\255\277"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 215311166}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 215419790}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 215557223}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 3000}) = 1 (in [6], left {0, 3000}) clock_gettime(CLOCK_MONOTONIC, {13632, 215795924}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 215859432}) = 0 read(6, "", 4096) = 0 shutdown(6, 2 /* send and receive */) = 0 close(6) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 216235452}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 216300995}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 216437169}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 2000}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 223527841}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 223594833}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 223657960}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 223721606}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 224306305}) = 0 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\177\1\"\0017\0*\0\177\1"..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0*\0\0\0\0\0\2\0@\1\0\0\0\0\30v3\10X\341\224\277\\8"..., 32) = 32 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = ? ERESTARTNOHAND (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) clock_gettime(CLOCK_MONOTONIC, {13632, 233787027}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 233854256}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 233917443}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 233981841}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 234131006}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 253521374}) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 253669066}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 253731990}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 253796045}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 253939793}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 20000}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 273553593}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 273627839}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 273691508}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 273756061}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 273906332}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 10000}) = 1 (in [1], left {0, 10000}) clock_gettime(CLOCK_MONOTONIC, {13632, 281260917}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 281328538}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 281400836}) = 0 accept(1, {sa_family=AF_INET, sin_port=htons(39765), sin_addr=inet_addr("107.108.92.97")}, [16]) = 6 setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 getsockname(6, {sa_family=AF_INET, sin_port=htons(6001), sin_addr=inet_addr("107.108.92.50")}, [16]) = 0 getpeername(6, {sa_family=AF_INET, sin_port=htons(39765), sin_addr=inet_addr("107.108.92.97")}, [16]) = 0 fcntl64(6, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 282325454}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 282390649}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 282536565}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 1000}) = 1 (in [6], left {0, 1000}) clock_gettime(CLOCK_MONOTONIC, {13632, 282796747}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 282860625}) = 0 read(6, "l\0\v\0\0\0\22\0\20\0\0\0MIT-MAGIC-COOKIE-1\0\0"..., 4092) = 48 clock_gettime(CLOCK_MONOTONIC, {13632, 283066013}) = 0 --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 283895828}) = 0 write(0, "\221\3\n\0\2\0@\1\1\0@\1 \3X\2\177\1\"\0017\0*\0\177\1"..., 44) = 44 read(0, 0xbfad1740, 32) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=0, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(0, "\1\0,\0\0\0\0\0\2\0@\1\0\0\0\0\30v3\10X\341\224\277\\8"..., 32) = 32 select(256, [1 3 4 5], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 285285862}) = 0 setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\v\0\0\0W\0\0\261\236\0\0\0@\0\377\377\37\0\0\1\0\0"..., 356}], 1) = 356 clock_gettime(CLOCK_MONOTONIC, {13632, 285773756}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 285899163}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 286044095}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 286326992}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 286391183}) = 0 read(6, "7\0\6\0\0\0@\0H\0\0\0\f\0\0\0\1\0\0\0\0\0\0\0b\0\5\0\f"..., 4096) = 68 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\2\0\0\0\0\0\1\205\0\0\2\0\0\0\0\0\0\0\0\0\0\0(\35"..., 120}], 1) = 120 clock_gettime(CLOCK_MONOTONIC, {13632, 286916564}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 286981452}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 287163039}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 287402746}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 287466397}) = 0 read(6, "\205\0\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1l\4\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\34\32"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 287886941}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 287951522}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 288128784}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 288368153}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 288432146}) = 0 read(6, "b\0\5\0\t\0@\0XKEYBOARD\0\0\0", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\5\0\0\0\0\0\1\213X\224\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 288871692}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 288975744}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 289112824}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 289351868}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 289415913}) = 0 read(6, "\213\0\2\0\1\0\0\0", 4096) = 8 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\1\6\0\0\0\0\0\1\0\0\0(\32\255\277\367\353\r\10Xl\37"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 289838118}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 289902843}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 290039288}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 290319422}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 290383085}) = 0 read(6, "b\0\4\0\10\0\0\0XINERAMA", 4096) = 16 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\7\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 290845205}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 290910103}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 291047356}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 291453099}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 291517527}) = 0 read(6, "\2\0\4\0H\0\0\0\0\10\0\0\0\0\2\0[\0\2\1 \0\0\0\0\0\0\0"..., 4096) = 1048 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\32\t\0\0\2\0\0\0\1\37\10\1\0\0\0\0\20\0\0\0\0\0\0\0"..., 2080}], 1) = 2080 clock_gettime(CLOCK_MONOTONIC, {13632, 292102584}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 292183344}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 292334938}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 292763341}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 292827759}) = 0 read(6, "\20\0\6\0\r\0\0\0_XSETTINGS_S0\0\0\0\20\0\7\0\23\0\0\0"..., 4096) = 68 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\n\0\0\0\0\0\242\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 96}], 1) = 96 clock_gettime(CLOCK_MONOTONIC, {13632, 293325246}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 293390092}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 293600766}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 293841788}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 293905272}) = 0 read(6, "\3\0\2\0H\0\0\0\16X\2\0H\0\0\0", 4096) = 16 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\0\r\0\3\0\0\0!\0\0\0\1\0\0\1\377\377\377\377\0\0\0\0"..., 76}], 1) = 76 clock_gettime(CLOCK_MONOTONIC, {13632, 294361377}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 294426371}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 294604087}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 294843432}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 294906776}) = 0 read(6, "\2\0\4\0H\0\0\0\0\10\0\0\0\0\2\0$S\1\0\27\0\2\0\242\0\0"..., 4096) = 28 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\21\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 295444363}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 295547015}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 295688278}) = 0 select(256, [1 3 4 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 295960806}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 296024248}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 296091007}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 296153972}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 296288769}) = 0 select(256, [1 3 4 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 296520599}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 296583873}) = 0 read(6, "%\0\1\0\1\10\r\0\1\0@\0H\0\0\0\n\0\n\0\n\0\n\0\0\0\1\0"..., 4096) = 92 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\25\0\0\0\0\0\245\0\0\0\0\0B\0\354\276\27\10Xl\37"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 297107206}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 297213268}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 297351806}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 297608852}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 297672354}) = 0 read(6, "\20\0\5\0\f\0@\0_NET_WM_NAME", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\26\0\0\0\0\0\246\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 298111816}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 298176475}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 298313150}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 299024230}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 299088833}) = 0 read(6, "\22\0\10\0\1\0@\0\246\0\0\0\245\0\0\0\10AME\10\0\0\0gd"..., 4096) = 92 clock_gettime(CLOCK_MONOTONIC, {13632, 299298085}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 299387938}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31\27\0\1\0@\0\246\0\0\0+\3\320\0\0\276\27\0100O\""..., 96}], 1) = 96 clock_gettime(CLOCK_MONOTONIC, {13632, 299728639}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 299793912}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 299976923}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 300218524}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 300282192}) = 0 read(6, "\22\0\10\0\1\0@\0\247\0\0\0\245\0\0\0\10AME\10\0\0\0gd"..., 4096) = 88 clock_gettime(CLOCK_MONOTONIC, {13632, 300488344}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 300563369}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31\32\0\1\0@\0\247\0\0\0,\3\320\0\0\276\27\10\300O"..., 96}], 1) = 96 clock_gettime(CLOCK_MONOTONIC, {13632, 300907232}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 301012394}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 301151725}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 301391088}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 301454565}) = 0 read(6, "\20\0\6\0\r\0@\0WM_TAKE_FOCUS\0\0\0", 4096) = 24 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\35\0\0\0\0\0\251\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 301901293}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 302006564}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 302142895}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 302381302}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 302445020}) = 0 read(6, "\20\0\5\0\f\0@\0_NET_WM_PING", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\36\0\0\0\0\0\252\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 302878890}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 302982526}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 303121950}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 303360982}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 303454240}) = 0 read(6, "\20\0\5\0\f\0@\0WM_PROTOCOLS", 4096) = 20 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353\37\0\0\0\0\0\253\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 303893676}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 303958312}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 304138028}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 304392600}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 304456723}) = 0 read(6, "\22\0\t\0\1\0@\0\253\0\0\0\4\0\0\0 OLS\3\0\0\0\250\0\0"..., 4096) = 268 clock_gettime(CLOCK_MONOTONIC, {13632, 304664474}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 304771298}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 304845653}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31 \0\1\0@\0\253\0\0\0000\3\320\0\0\276\27\10\340P"..., 128}], 1) = 128 clock_gettime(CLOCK_MONOTONIC, {13632, 305182334}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 305246883}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 305431925}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 305671708}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 305734965}) = 0 read(6, "\22\0\t\0\1\0@\0\254\0\0\0\37\0\0\0\10OLS\v\0\0\0en_US"..., 4096) = 56 clock_gettime(CLOCK_MONOTONIC, {13632, 305936299}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31\'\0\1\0@\0\254\0\0\0001\3\320\0\0\276\27\10\240"..., 64}], 1) = 64 clock_gettime(CLOCK_MONOTONIC, {13632, 306271352}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 306377110}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 306515303}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 306754184}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 306817636}) = 0 read(6, "\22\0\7\0\1\0@\0\255\0\0\0\6\0\0\0 OLS\1\0\0\0\33\n\0\0"..., 4096) = 52 clock_gettime(CLOCK_MONOTONIC, {13632, 307027702}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31)\0\1\0@\0\255\0\0\0003\3\320\0\0\276\27\10\370R"..., 64}], 1) = 64 clock_gettime(CLOCK_MONOTONIC, {13632, 307362869}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 307427722}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 307604930}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 307843611}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 307907007}) = 0 read(6, "\22\0\7\0\1\0@\0\256\0\0\0!\0\0\0 OLS\1\0\0\0\0\0\0\0b"..., 4096) = 44 clock_gettime(CLOCK_MONOTONIC, {13632, 308116856}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31+\0\1\0@\0\256\0\0\0004\3\320\0\0\276\27\10XS\"\10"..., 64}], 1) = 64 clock_gettime(CLOCK_MONOTONIC, {13632, 308461570}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 308564126}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 308703575}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 308942575}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 309006319}) = 0 read(6, "\225\0\3\0\3\0\0\0\0\0\0\0", 4096) = 12 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\365-\0\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\32\255"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 309450322}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 309515134}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 309694490}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 309933735}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 309997195}) = 0 read(6, "\20\0\6\0\17\0\0\0_NET_WM_DESKTOP\0\20\0\5\0\f\0\4\0"..., 4096) = 384 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353.\0\0\0\0\0\257\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 416}], 1) = 416 clock_gettime(CLOCK_MONOTONIC, {13632, 310525558}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 310590683}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 310739970}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 311027093}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311091091}) = 0 read(6, "\22\0\t\0\1\0@\0\"\0\0\0\37\0\0\0\10ESK\t\0\0\0gdmlogi"..., 4096) = 236 clock_gettime(CLOCK_MONOTONIC, {13632, 311291465}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311367755}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311437882}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311509347}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311577953}) = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\34\31;\0\1\0@\0\"\0\0\0007\3\320\0\0\276\27\10HV\"\10"..., 192}], 1) = 192 clock_gettime(CLOCK_MONOTONIC, {13632, 311926400}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 311991196}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 312171771}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 312411732}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 312475353}) = 0 read(6, "b\0\3\0\4\0@\0SYNC", 4096) = 12 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353B\0\0\0\0\0\1\212V\222\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 312907543}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 312972282}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 313149388}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 313388823}) = 0 --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 313788432}) = 0 read(6, "\212\0\2\0\3\0@\0", 4096) = 8 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1lC\0\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\34\32\255"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 314222566}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 314327877}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 314467264}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 314706635}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 314770031}) = 0 read(6, "b\0\4\0\7\0@\0MIT-SHM\0", 4096) = 16 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353D\0\0\0\0\0\1\201A\200\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 315201394}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 315305618}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 315442415}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 315681680}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 315745120}) = 0 read(6, "\201\0\1\0", 4096) = 4 geteuid32() = 0 getegid32() = 0 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\1E\0\0\0\0\0\1\0\1\0\0\0\0\0\2\0\0\0\0\0\0\0\34\32\255"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 316294993}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 316359636}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 316535967}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 316776105}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 316839445}) = 0 read(6, "b\0\6\0\17\0@\0XInputExtension\0", 4096) = 24 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353F\0\0\0\0\0\1\203B\201\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 317292331}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 317356998}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 317534356}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 317774061}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 317837304}) = 0 read(6, "b\0\6\0\17\0@\0XInputExtension\0", 4096) = 24 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\353G\0\0\0\0\0\1\203B\201\0\20\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 318274349}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 318339311}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 318515812}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 318755973}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 318819331}) = 0 read(6, "\203\1\6\0\17\0@\0XInputExtension\0", 4096) = 24 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\1H\0\0\0\0\0\1\0\4\0\1\20\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32}], 1) = 32 clock_gettime(CLOCK_MONOTONIC, {13632, 319271038}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 319374739}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 319511970}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 319750485}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 319813582}) = 0 read(6, "\203\2\1\0", 4096) = 4 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\2I\0008\0\0\0\4\365\31\10\340\31\255\277\10\32\255\277"..., 256}], 1) = 256 clock_gettime(CLOCK_MONOTONIC, {13632, 320248202}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 320313332}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 320449881}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 1 (in [6], left {0, 20000}) clock_gettime(CLOCK_MONOTONIC, {13632, 320734198}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 320797793}) = 0 read(6, "\203\3\2\0\3\0@\0", 4096) = 8 read(6, 0x82212d8, 4096) = -1 EAGAIN (Resource temporarily unavailable) writev(6, [{"\1\3J\0\2\0\0\0\4\365\31\10\340\31\255\277\10\32\255\277"..., 40}], 1) = 40 clock_gettime(CLOCK_MONOTONIC, {13632, 321218573}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 321282916}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 321418888}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 20000}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {13632, 333547218}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 333618298}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 333681329}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 333745429}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 333967349}) = 0 select(256, [1 3 4 5 6], NULL, NULL, {0, 10000}) = 1 (in [6], left {0, 10000}) clock_gettime(CLOCK_MONOTONIC, {13632, 334220634}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 334284548}) = 0 read(6, "", 4096) = 0 shutdown(6, 2 /* send and receive */) = 0 close(6) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 334766375}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 334832969}) = 0 ioctl(0, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 334971509}) = 0 select(256, [1 3 4 5], NULL, NULL, {0, 9000}) = 1 (in [5], left {0, 9000}) clock_gettime(CLOCK_MONOTONIC, {13632, 335253532}) = 0 clock_gettime(CLOCK_MONOTONIC, {13632, 335317163}) = 0 read(5, "", 4096) = 0 shutdown(5, 2 /* send and receive */) = 0 close(5) = 0 munmap(0xb7a1b000, 139264) = 0 close(1) = 0 close(3) = 0 unlink("/tmp/.X11-unix/X1") = 0 unlink("/tmp/.X1-lock") = 0 exit_group(0) = ? ----- Original Message ---- From: Puneet Goel To: tapojoychatterjee at yahoo.co.in Sent: Tuesday, 18 December, 2007 7:18:14 PM Subject: Fwd: Xephyr crashing on 8 bit connection attempt ---------- Forwarded message ---------- From: Dodji Seketeli Date: Dec 18, 2007 4:19 PM Subject: Re: Xephyr crashing on 8 bit connection attempt To: pratish ganguly Cc: xorg at lists.freedesktop.org On Tue, Dec 18, 2007 at 03:00:34PM +0530, pratish ganguly wrote: > Dear Dodji > > The command that I am using is > > Xephyr :1 -ac -once -screen 800x600x8 -query 107.108.92.131 -fp > /usr/share/X11/fonts/misc/ I tried something similar (without the -query part) to launch Xephyr on the Xorg server running on my local machine, and it runs fine with Xephyr from git master tip. What happens when you just try: Xephyr :1 -ac -once -screen 800x600x8 -fb /usr/share/X11/fonts/misc/ Cheers. -- Dodji Seketeli http://www.seketeli.org/dodji _______________________________________________ xorg mailing list xorg at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg DELETE button is history. Unlimited mail storage is just a click away. Go to https://edit.india.yahoo.com/config/eval_register -------------- next part -------------- An HTML attachment was scrubbed... URL: