Re: latest git xserver without hal causes Hotplugging to be a bit tricky
Le 27/11/2010 05:24, Justin Mattock a écrit : Section ServerFlags Option AutoAddDevices False EndSection Remove that. You've just disabled input hotplugging. is there a new option that I need to add to xorg.conf in order to startx and have radeon work right as well as the mouse and keyboard? or is this dependant on hal and/or device manager? (machine is a macbook pro) Install xf86-input-evdev. That's the 'new' input driver everyone should be using, it handles pretty much everything: keyboards, mice, trackpads, etc. Once that works, you may want to install a specific driver like -synaptic (most touchpads) or -wacom (tablets), if you have such hardware. The -kbd and -mouse drivers are still maintained but not recommended, as they completely bypass the kernel's input stack. Cheers, Rémi ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Any plan to promote coordinats to 32 bits?
Le 23/11/2010 17:22, Alan Coopersmith a écrit : Several? I've yet to see many common monitors larger than 2560 pixels, so that's still 14 screens wide/high. http://insitu.lri.fr/Projects/WILD Yes this is research, yes we won't have that on our wrist watches any time soon... But! InSitu's (virtual) wall is already 20480x6400 which is less than an order of magnitude away from the 16bit limit. The next research team that does this sort of insane setup will probably blow the limit. And we did have an X running on that (using metisse), fully capable of using the entire screen real estate. Food for thoughts :) Rémi ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] font releases, second and final part
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, And here are the final font releases. Like in my previous batch, all changes are by Gaétan and Jesse. Here's the list of all download URLs along with checksums: http://xorg.freedesktop.org/archive/individual/font/font-arabic-misc-1.0.3.tar.bz2 MD5: cc0726e4a277d6ed93b8e09c1f195470 font-arabic-misc-1.0.3.tar.bz2 SHA1: 322ae41e74deea8de11fa077fd0e0191927a667c font-arabic-misc-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-arabic-misc-1.0.3.tar.gz MD5: 918457df65ef93f09969c6ab01071789 font-arabic-misc-1.0.3.tar.gz SHA1: 186b05721e6fea0c1b0d600704c67fdb0d777e55 font-arabic-misc-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-100dpi-1.0.3.tar.bz2 MD5: 9f11ade089d689b9d59e0f47d26f39cd font-bh-100dpi-1.0.3.tar.bz2 SHA1: 47d5e50be9e78695017650a088da52bfcf1eeb40 font-bh-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-100dpi-1.0.3.tar.gz MD5: 09e63a5608000531179e1ab068a35878 font-bh-100dpi-1.0.3.tar.gz SHA1: 3845c95b62b94dc119ed2bb75bec48bf6c6d1e9a font-bh-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-75dpi-1.0.3.tar.bz2 MD5: 565494fc3b6ac08010201d79c677a7a7 font-bh-75dpi-1.0.3.tar.bz2 SHA1: 7290567d42a0f5adb6a3ad170524bb7ed59871d7 font-bh-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-75dpi-1.0.3.tar.gz MD5: 88fec4ebc4a265684bff3abdd066f14f font-bh-75dpi-1.0.3.tar.gz SHA1: 0372601465344d9e5638b59fc3fc3d933be8de7f font-bh-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 MD5: c8b73a53dcefe3e8d3907d3500e484a9 font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 SHA1: bc4f804e49db8c6add04f52ffb1c0cd63e714b2c font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz MD5: 5f716f54e497fb4ec1bb3a5d650ac6f7 font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz SHA1: 3e9b56f2baedd7c1eda5b2e73c7e51c2807abe8e font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 MD5: f6d65758ac9eb576ae49ab24c5e9019a font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 SHA1: 3c6678e6bbb2bd352baaf610a8f6aac9c5140c85 font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz MD5: cab8a44ae329aab7141c7adeef0daf5a font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz SHA1: bfe3c96e37de55b7d7dc0c225c1713dcd8de1063 font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-type1-1.0.3.tar.bz2 MD5: 53ed9a42388b7ebb689bdfc374f96a22 font-bh-type1-1.0.3.tar.bz2 SHA1: 69ff038d38015cd305a4cd4d1a921fe3bd08bbde font-bh-type1-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-type1-1.0.3.tar.gz MD5: 62d4e8f782a6a0658784072a5df5ac98 font-bh-type1-1.0.3.tar.gz SHA1: d7da5d0d0fa7f78977f51094b2d5245183c822be font-bh-type1-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-100dpi-1.0.3.tar.bz2 MD5: 6b223a54b15ecbd5a1bc52312ad790d8 font-bitstream-100dpi-1.0.3.tar.bz2 SHA1: 138376f8683c09b9068c7c124842a7af9f0fcc2e font-bitstream-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-100dpi-1.0.3.tar.gz MD5: c27bf37e9b8039f93bd90b8131ed37ad font-bitstream-100dpi-1.0.3.tar.gz SHA1: 2b4df89a59d93d01393c9ea21517cce575717ecf font-bitstream-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-75dpi-1.0.3.tar.bz2 MD5: d7c0588c26fac055c0dd683fdd65ac34 font-bitstream-75dpi-1.0.3.tar.bz2 SHA1: 975e9f7872483394ebd87610f8bbc924d99bea34 font-bitstream-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-75dpi-1.0.3.tar.gz MD5: 4ff6c5d6aebe69371e27b09ad8313d25 font-bitstream-75dpi-1.0.3.tar.gz SHA1: d75e182737ef5667e2e538b081e9a6c07ff7a53c font-bitstream-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-speedo-1.0.2.tar.bz2 MD5: 13f6f107be164cfbf6be40d35ecf0c0f font-bitstream-speedo-1.0.2.tar.bz2 SHA1: e299d2bd2a84c98be5202435c8355e73e0282970 font-bitstream-speedo-1.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-speedo-1.0.2.tar.gz MD5: f0a777b351cf5adefefcf4823e0c1c01 font-bitstream-speedo-1.0.2.tar.gz SHA1: 303f2a2c4dd3a5a29b1e3ec0a91e4433cbf6dad8 font-bitstream-speedo-1.0.2.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-type1-1.0.3.tar.bz2 MD5: 5e0c9895d69d2632e2170114f8283c11 font-bitstream-type1-1.0.3.tar.bz2 SHA1: 7633551be3525c501278e81259b22ad9a893de4d font-bitstream-type1-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-type1-1.0.3.tar.gz MD5: ff91738c4d3646d7999e00aa9923f2a0
[ANNOUNCE] font releases, second and final part
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, And here are the final font releases. Like in my previous batch, all changes are by Gaétan and Jesse. Here's the list of all download URLs along with checksums: http://xorg.freedesktop.org/archive/individual/font/font-arabic-misc-1.0.3.tar.bz2 MD5: cc0726e4a277d6ed93b8e09c1f195470 font-arabic-misc-1.0.3.tar.bz2 SHA1: 322ae41e74deea8de11fa077fd0e0191927a667c font-arabic-misc-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-arabic-misc-1.0.3.tar.gz MD5: 918457df65ef93f09969c6ab01071789 font-arabic-misc-1.0.3.tar.gz SHA1: 186b05721e6fea0c1b0d600704c67fdb0d777e55 font-arabic-misc-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-100dpi-1.0.3.tar.bz2 MD5: 9f11ade089d689b9d59e0f47d26f39cd font-bh-100dpi-1.0.3.tar.bz2 SHA1: 47d5e50be9e78695017650a088da52bfcf1eeb40 font-bh-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-100dpi-1.0.3.tar.gz MD5: 09e63a5608000531179e1ab068a35878 font-bh-100dpi-1.0.3.tar.gz SHA1: 3845c95b62b94dc119ed2bb75bec48bf6c6d1e9a font-bh-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-75dpi-1.0.3.tar.bz2 MD5: 565494fc3b6ac08010201d79c677a7a7 font-bh-75dpi-1.0.3.tar.bz2 SHA1: 7290567d42a0f5adb6a3ad170524bb7ed59871d7 font-bh-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-75dpi-1.0.3.tar.gz MD5: 88fec4ebc4a265684bff3abdd066f14f font-bh-75dpi-1.0.3.tar.gz SHA1: 0372601465344d9e5638b59fc3fc3d933be8de7f font-bh-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 MD5: c8b73a53dcefe3e8d3907d3500e484a9 font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 SHA1: bc4f804e49db8c6add04f52ffb1c0cd63e714b2c font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz MD5: 5f716f54e497fb4ec1bb3a5d650ac6f7 font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz SHA1: 3e9b56f2baedd7c1eda5b2e73c7e51c2807abe8e font-bh-lucidatypewriter-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 MD5: f6d65758ac9eb576ae49ab24c5e9019a font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 SHA1: 3c6678e6bbb2bd352baaf610a8f6aac9c5140c85 font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz MD5: cab8a44ae329aab7141c7adeef0daf5a font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz SHA1: bfe3c96e37de55b7d7dc0c225c1713dcd8de1063 font-bh-lucidatypewriter-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bh-type1-1.0.3.tar.bz2 MD5: 53ed9a42388b7ebb689bdfc374f96a22 font-bh-type1-1.0.3.tar.bz2 SHA1: 69ff038d38015cd305a4cd4d1a921fe3bd08bbde font-bh-type1-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bh-type1-1.0.3.tar.gz MD5: 62d4e8f782a6a0658784072a5df5ac98 font-bh-type1-1.0.3.tar.gz SHA1: d7da5d0d0fa7f78977f51094b2d5245183c822be font-bh-type1-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-100dpi-1.0.3.tar.bz2 MD5: 6b223a54b15ecbd5a1bc52312ad790d8 font-bitstream-100dpi-1.0.3.tar.bz2 SHA1: 138376f8683c09b9068c7c124842a7af9f0fcc2e font-bitstream-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-100dpi-1.0.3.tar.gz MD5: c27bf37e9b8039f93bd90b8131ed37ad font-bitstream-100dpi-1.0.3.tar.gz SHA1: 2b4df89a59d93d01393c9ea21517cce575717ecf font-bitstream-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-75dpi-1.0.3.tar.bz2 MD5: d7c0588c26fac055c0dd683fdd65ac34 font-bitstream-75dpi-1.0.3.tar.bz2 SHA1: 975e9f7872483394ebd87610f8bbc924d99bea34 font-bitstream-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-75dpi-1.0.3.tar.gz MD5: 4ff6c5d6aebe69371e27b09ad8313d25 font-bitstream-75dpi-1.0.3.tar.gz SHA1: d75e182737ef5667e2e538b081e9a6c07ff7a53c font-bitstream-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-speedo-1.0.2.tar.bz2 MD5: 13f6f107be164cfbf6be40d35ecf0c0f font-bitstream-speedo-1.0.2.tar.bz2 SHA1: e299d2bd2a84c98be5202435c8355e73e0282970 font-bitstream-speedo-1.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-speedo-1.0.2.tar.gz MD5: f0a777b351cf5adefefcf4823e0c1c01 font-bitstream-speedo-1.0.2.tar.gz SHA1: 303f2a2c4dd3a5a29b1e3ec0a91e4433cbf6dad8 font-bitstream-speedo-1.0.2.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-bitstream-type1-1.0.3.tar.bz2 MD5: 5e0c9895d69d2632e2170114f8283c11 font-bitstream-type1-1.0.3.tar.bz2 SHA1: 7633551be3525c501278e81259b22ad9a893de4d font-bitstream-type1-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-bitstream-type1-1.0.3.tar.gz MD5: ff91738c4d3646d7999e00aa9923f2a0
[ANNOUNCE] font releases, part 1
Hi all, As promised, here's a first batch of font releases, hopefully in time for the upcoming katamari. For now, I've only tackled adobe-* fonts, the rest will come later once I get round to it. The major changes for these fives releases are - CVS tags purges by Jesse Adkins - font-util macro bump to 1.2 by Gaétan Nadon Follows a list of all urls, MD5 and SHA1 checksums: http://xorg.freedesktop.org/archive/individual/font/font-adobe-100dpi-1.0.3.tar.bz2 MD5: 1347c3031b74c9e91dc4dfa53b12f143 font-adobe-100dpi-1.0.3.tar.bz2 SHA1: 53311cbd604f18bd9570727105a4222473d363e3 font-adobe-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-100dpi-1.0.3.tar.gz MD5: ba61e7953f4f5cec5a8e69c262bbc7f9 font-adobe-100dpi-1.0.3.tar.gz SHA1: be4841c7cc0c8d0505aaba8d04147098381f9aaf font-adobe-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-75dpi-1.0.3.tar.bz2 MD5: 6c9f26c92393c0756f3e8d614713495b font-adobe-75dpi-1.0.3.tar.bz2 SHA1: 6a2ec569336b5646682a14eee3c7790274beffd1 font-adobe-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-75dpi-1.0.3.tar.gz MD5: 7a414bb661949cec938938fd678cf649 font-adobe-75dpi-1.0.3.tar.gz SHA1: aa2a8acf4e5a45d579ce5e7c7c69c40f7039de68 font-adobe-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.bz2 MD5: 66fb6de561648a6dce2755621d6aea17 font-adobe-utopia-100dpi-1.0.4.tar.bz2 SHA1: 9e80cf5bbd5522a5cfad2a9f8f8fce86de0f0226 font-adobe-utopia-100dpi-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.gz MD5: 128416eccd59b850f77a9b803681da3c font-adobe-utopia-100dpi-1.0.4.tar.gz SHA1: fec0c4810069bb47182d300fb73737b218ada56e font-adobe-utopia-100dpi-1.0.4.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.bz2 MD5: e99276db3e7cef6dccc8a57bc68aeba7 font-adobe-utopia-75dpi-1.0.4.tar.bz2 SHA1: 50e837322a09f1a7c40fb78fc6aad1a157284507 font-adobe-utopia-75dpi-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.gz MD5: 74c73a5b73c6c3224b299f1fc033e508 font-adobe-utopia-75dpi-1.0.4.tar.gz SHA1: c8ed4daf49a4db89b0f9df125420b299a93747a6 font-adobe-utopia-75dpi-1.0.4.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-type1-1.0.4.tar.bz2 MD5: fcf24554c348df3c689b91596d7f9971 font-adobe-utopia-type1-1.0.4.tar.bz2 SHA1: 3113cfafb91c2c53df6a1fae57dca6c50fb8ce20 font-adobe-utopia-type1-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-type1-1.0.4.tar.gz MD5: b0676c3495acabad519ee98a94163904 font-adobe-utopia-type1-1.0.4.tar.gz SHA1: 289c4641ed48f509315c9dbfe60f4641f7458569 font-adobe-utopia-type1-1.0.4.tar.gz Cheers, Rémi signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] font releases, part 1
Hi all, As promised, here's a first batch of font releases, hopefully in time for the upcoming katamari. For now, I've only tackled adobe-* fonts, the rest will come later once I get round to it. The major changes for these fives releases are - CVS tags purges by Jesse Adkins - font-util macro bump to 1.2 by Gaétan Nadon Follows a list of all urls, MD5 and SHA1 checksums: http://xorg.freedesktop.org/archive/individual/font/font-adobe-100dpi-1.0.3.tar.bz2 MD5: 1347c3031b74c9e91dc4dfa53b12f143 font-adobe-100dpi-1.0.3.tar.bz2 SHA1: 53311cbd604f18bd9570727105a4222473d363e3 font-adobe-100dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-100dpi-1.0.3.tar.gz MD5: ba61e7953f4f5cec5a8e69c262bbc7f9 font-adobe-100dpi-1.0.3.tar.gz SHA1: be4841c7cc0c8d0505aaba8d04147098381f9aaf font-adobe-100dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-75dpi-1.0.3.tar.bz2 MD5: 6c9f26c92393c0756f3e8d614713495b font-adobe-75dpi-1.0.3.tar.bz2 SHA1: 6a2ec569336b5646682a14eee3c7790274beffd1 font-adobe-75dpi-1.0.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-75dpi-1.0.3.tar.gz MD5: 7a414bb661949cec938938fd678cf649 font-adobe-75dpi-1.0.3.tar.gz SHA1: aa2a8acf4e5a45d579ce5e7c7c69c40f7039de68 font-adobe-75dpi-1.0.3.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.bz2 MD5: 66fb6de561648a6dce2755621d6aea17 font-adobe-utopia-100dpi-1.0.4.tar.bz2 SHA1: 9e80cf5bbd5522a5cfad2a9f8f8fce86de0f0226 font-adobe-utopia-100dpi-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.gz MD5: 128416eccd59b850f77a9b803681da3c font-adobe-utopia-100dpi-1.0.4.tar.gz SHA1: fec0c4810069bb47182d300fb73737b218ada56e font-adobe-utopia-100dpi-1.0.4.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.bz2 MD5: e99276db3e7cef6dccc8a57bc68aeba7 font-adobe-utopia-75dpi-1.0.4.tar.bz2 SHA1: 50e837322a09f1a7c40fb78fc6aad1a157284507 font-adobe-utopia-75dpi-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.gz MD5: 74c73a5b73c6c3224b299f1fc033e508 font-adobe-utopia-75dpi-1.0.4.tar.gz SHA1: c8ed4daf49a4db89b0f9df125420b299a93747a6 font-adobe-utopia-75dpi-1.0.4.tar.gz http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-type1-1.0.4.tar.bz2 MD5: fcf24554c348df3c689b91596d7f9971 font-adobe-utopia-type1-1.0.4.tar.bz2 SHA1: 3113cfafb91c2c53df6a1fae57dca6c50fb8ce20 font-adobe-utopia-type1-1.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/font/font-adobe-utopia-type1-1.0.4.tar.gz MD5: b0676c3495acabad519ee98a94163904 font-adobe-utopia-type1-1.0.4.tar.gz SHA1: 289c4641ed48f509315c9dbfe60f4641f7458569 font-adobe-utopia-type1-1.0.4.tar.gz Cheers, Rémi signature.asc Description: This is a digitally signed message part ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXt 1.0.8
Hi all, I've just release libXt 1.0.8. It's just a maintenance release with most patches fixing build issues (on Hurd and for cross-compile setups) or improving autotools use. Below is the short log since the previous release. Cheers, Rémi Alan Coopersmith (2): Fix make distcheck (./util/makestrs.1 left after distclean) Update Sun license notices to current X.Org standard form Gaetan Nadon (6): .gitignore: use common defaults with custom section # 24239 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 Deploy the new XORG_DEFAULT_OPTIONS #24242 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES COPYING: add missing copyright notices Jeremy Huddleston (2): This is not a GNU project, so declare it foreign. darwin: xnu doesn't support poll on ttys on the master side. Rémi Cardona (2): Don't install makestrs on the system libXt 1.0.8 git tag: libXt-1.0.8 http://xorg.freedesktop.org/archive/individual/lib/libXt-1.0.8.tar.bz2 MD5: fb7d2aa5b24cd5fe9b238a26d88030e7 libXt-1.0.8.tar.bz2 SHA1: d5e3dfba90a12169771399b3e2ccae07243489c9 libXt-1.0.8.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXt-1.0.8.tar.gz MD5: 6f8ef20cf0f0645e2a34b39a7dcd882b libXt-1.0.8.tar.gz SHA1: 1a560c3fc1cd4bbc9e73910616cb91887b014131 libXt-1.0.8.tar.gz signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXt 1.0.8
Hi all, I've just release libXt 1.0.8. It's just a maintenance release with most patches fixing build issues (on Hurd and for cross-compile setups) or improving autotools use. Below is the short log since the previous release. Cheers, Rémi Alan Coopersmith (2): Fix make distcheck (./util/makestrs.1 left after distclean) Update Sun license notices to current X.Org standard form Gaetan Nadon (6): .gitignore: use common defaults with custom section # 24239 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 Deploy the new XORG_DEFAULT_OPTIONS #24242 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES COPYING: add missing copyright notices Jeremy Huddleston (2): This is not a GNU project, so declare it foreign. darwin: xnu doesn't support poll on ttys on the master side. Rémi Cardona (2): Don't install makestrs on the system libXt 1.0.8 git tag: libXt-1.0.8 http://xorg.freedesktop.org/archive/individual/lib/libXt-1.0.8.tar.bz2 MD5: fb7d2aa5b24cd5fe9b238a26d88030e7 libXt-1.0.8.tar.bz2 SHA1: d5e3dfba90a12169771399b3e2ccae07243489c9 libXt-1.0.8.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXt-1.0.8.tar.gz MD5: 6f8ef20cf0f0645e2a34b39a7dcd882b libXt-1.0.8.tar.gz SHA1: 1a560c3fc1cd4bbc9e73910616cb91887b014131 libXt-1.0.8.tar.gz signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Le 29/01/2010 00:41, Russell Shaw a écrit : What i really meant was Forget existing widget toolkits. One can write their own that is much better than the existing ones, if you architect the thing right. Doing that is not a small job. Takes a lot of time just to think about before even writing any code. Right, so let me sum up. Dirk wants to write a full-screen app, with very little interaction with other windows. This is a trivial task for _any_ modern toolkit (gtk, qt, efl, sdl, hell even motif or swing, etc). Your suggestion to Dirk is for him to completely _ignore_ the current toolkits and to start all over from scratch, dropping 10~15 years worth of common knowledge from all the current X-based toolkits. Dirk, please try using one of the current toolkits first. And if you don't like one, try another one, don't write Xlib code directly. That's the toolkit guys' problem, it shouldn't be yours. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xrandr: Remove test against RANDR_MAJOR/RANDR_MINOR, already done by configure script
Le 04/11/2009 14:28, Yann Droneaud a écrit : xrandr.c uses structures defined inX11/extensions/Xrandr.h provided by 'libXrandr' package but tests structures availability through RANDR_MAJOR/RANDR_MINOR defined inX11/extensions/randr.h provided by 'randrproto' package. Sometimes they are not in sync so it's safer to rely on checks made by configure script through pkg-config. In my test case, XRRPanning structure is not defined in Xrandr.h, RANDR_MAJOR is 1 and RANDR_MINOR 2 but xrandr.c try to use it anyway. (for the record, XRRPanning was added in libXrandr-1.2.91). Pushed to master. Don't forget to sign-off your patches next time :) Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xinit 1.2.0
Hi all, Here's a new release of xinit. While no longer part of the Katamari, it has seen quite a few changes, Alan's cleanups being more than responsible for the new minor version. Cheers Alan Coopersmith (7): Migrate to xorg macros 1.3 XORG_DEFAULT_OPTIONS Purge ancient server names from help, add newer server names instead Drop ancient A/UX compatibility hack Drop ancient SunWindows compatibility check Man page updates Strip RCS/CVS tags Use platform-specific X server names in man pages for cygwin darwin Andres Salomon (1): app/xinit: make startx's $? a useful value Jeremy Huddleston (6): Apple: Use MAC_OS_X_VERSION_MIN_REQUIRED instead of __MAC_OS_X_VERSION_MIN_REQUIRED launchd: Added --with-launchd-id-prefix option to set non-standard launchd id prefix (org.x is still default) launchd: Include LAUNCHD_ID_PREFIX in the socket name for reverse lookup to tell which launchd id owns $DISPLAY launchd: Update the DISPLAY envvar to not have a - ... call me paranoid, but I feel safer without it This is not a GNU project, so declare it foreign. Apple: Export X11_PREFS_DOMAIN for children (quartz-wm) Jon TURNEY (1): Cygwin can also have spaces in $HOME Paulo Cesar Pereira de Andrade (1): Correct make distcheck for recent git versions. Robert Macomber (1): startx: fix misparsing of initial client and server arguments which begin with / or ./ Rémi Cardona (2): make XINITDIR configurable at build-time, default is unchanged xinit 1.2.0 git tag: xinit-1.2.0 http://xorg.freedesktop.org/archive/individual/app/xinit-1.2.0.tar.bz2 MD5: fe1696cab2fbed6fa059d0cd1c53ac13 xinit-1.2.0.tar.bz2 SHA1: 85a838c2010f27ef6d09d6ec4b1208a66cc8d697 xinit-1.2.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinit-1.2.0.tar.gz MD5: 81d6b7ede77a4f3fd115e8dfa7de4754 xinit-1.2.0.tar.gz SHA1: afe487eebcd4754cc147045b0cf71e14a2324500 xinit-1.2.0.tar.gz signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xinit 1.2.0
Hi all, Here's a new release of xinit. While no longer part of the Katamari, it has seen quite a few changes, Alan's cleanups being more than responsible for the new minor version. Cheers Alan Coopersmith (7): Migrate to xorg macros 1.3 XORG_DEFAULT_OPTIONS Purge ancient server names from help, add newer server names instead Drop ancient A/UX compatibility hack Drop ancient SunWindows compatibility check Man page updates Strip RCS/CVS tags Use platform-specific X server names in man pages for cygwin darwin Andres Salomon (1): app/xinit: make startx's $? a useful value Jeremy Huddleston (6): Apple: Use MAC_OS_X_VERSION_MIN_REQUIRED instead of __MAC_OS_X_VERSION_MIN_REQUIRED launchd: Added --with-launchd-id-prefix option to set non-standard launchd id prefix (org.x is still default) launchd: Include LAUNCHD_ID_PREFIX in the socket name for reverse lookup to tell which launchd id owns $DISPLAY launchd: Update the DISPLAY envvar to not have a - ... call me paranoid, but I feel safer without it This is not a GNU project, so declare it foreign. Apple: Export X11_PREFS_DOMAIN for children (quartz-wm) Jon TURNEY (1): Cygwin can also have spaces in $HOME Paulo Cesar Pereira de Andrade (1): Correct make distcheck for recent git versions. Robert Macomber (1): startx: fix misparsing of initial client and server arguments which begin with / or ./ Rémi Cardona (2): make XINITDIR configurable at build-time, default is unchanged xinit 1.2.0 git tag: xinit-1.2.0 http://xorg.freedesktop.org/archive/individual/app/xinit-1.2.0.tar.bz2 MD5: fe1696cab2fbed6fa059d0cd1c53ac13 xinit-1.2.0.tar.bz2 SHA1: 85a838c2010f27ef6d09d6ec4b1208a66cc8d697 xinit-1.2.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinit-1.2.0.tar.gz MD5: 81d6b7ede77a4f3fd115e8dfa7de4754 xinit-1.2.0.tar.gz SHA1: afe487eebcd4754cc147045b0cf71e14a2324500 xinit-1.2.0.tar.gz signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nightly builds?
Le 06/11/2009 08:48, Tormod Volden a écrit : 1. Nightly builds. Did wonders for Mozilla. Binary of main supported architectures (linux/i386, opensolaris, whatever someone will be able to commit to build nightly). Download and run. Report bugs. Xorg is not your standard application. In nearly all distros, X is configured differently, with different paths, etc. So even if we did do binary builds, it would be much harder for users to actually download and run. And now that X drivers are being trimmed down in favor of kernel drivers, that only makes things more complex. For Ubuntu there is the xorg-edgers PPA (personal package archive) which have done exactly this for years: https://launchpad.net/~xorg-edgers In Gentoo, we have the x11 overlay which provides live packages. Whenever the user builds one of our live packages, the code is fetched from git and completely rebuilt. And with a single command, users can rebuild all live packages. As far as testing is concerned, both our approaches are extremely easy for end-users and completely integrated with the distro's package manager. 2. Make the source build easier, so people will build and run it from source for the more obscure platforms. My answer to that would be build.sh or jhbuild. All the info is written down in the wiki [1]. Sure it could probably be easier, but it's not like there's nothing at all. But building from source _is_ tricky and you have to have some prior knowledge before building large source trees like Xorg. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xrandr: Remove test against RANDR_MAJOR/RANDR_MINOR, already done by configure script
Le 04/11/2009 14:28, Yann Droneaud a écrit : xrandr.c uses structures defined inX11/extensions/Xrandr.h provided by 'libXrandr' package but tests structures availability through RANDR_MAJOR/RANDR_MINOR defined inX11/extensions/randr.h provided by 'randrproto' package. Sometimes they are not in sync so it's safer to rely on checks made by configure script through pkg-config. In my test case, XRRPanning structure is not defined in Xrandr.h, RANDR_MAJOR is 1 and RANDR_MINOR 2 but xrandr.c try to use it anyway. (for the record, XRRPanning was added in libXrandr-1.2.91). configure.ac deps on xrandr = 1.3. Reviewed-by: Rémi Cardona r...@gentoo.org I'll push it to master in a few days if no-one objects. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Screens with Intel hardware
Le 28/09/2009 11:00, Pradeep Reddy a écrit : Hi, What is the possibility to make separate X-screens with Intel graphics controller? Do anyone succeeded. Please post me their Xorg.conf or give me any tips ... It's not possible with the current -intel driver. If you want separate X screens, you'll have to layer Xnest/Xepyhr instances on top of Xorg. Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server aborting at first keypress or mouse movement
Le mercredi 16 septembre 2009 à 23:35 +0200, Didier Spaier a écrit : quote Section ServerFlags Option AllowEmptyInput false Option AutoAddDevices false Option AutoEnableDevices false EndSection /quote AutoAddDevices is enough to disable HAL support at run-time. quote (EE) config/hal: couldn't initialise context: unknown error (null) It's a bug, one that has already been fixed [1] in both master and in newer versions from the 1.6 branch. 1.6.3.901 should work just fine. Upgrading to 1.6.3.901 is strongly advised. Hope that helps Rémi [1] http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branchid=397f7c42cd775f1dbfced58bc1dfaead48e86440 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dead space elimination
Le 16/09/2009 16:00, Vincent Legoll a écrit : On Wed, Sep 16, 2009 at 3:42 PM, Jozef Rihajose1...@gmail.com wrote: one more thing. if you plan to go on with patching of Xorg sources, please consider there might be multiple dead areas based on the position of the monitors (e. g. one above and the other one below) Yes, if I get useful directions (mentoring, hint hint) I'll try to do something that work for more than 2 screens, with different resolutions, taking screen positionning / rotation into account, etc... I'm even thinking of different warping policies: - translate: warp to suitable location on other screen - blocking: stay on the current screen, do not enter forbidden area - jump into corner of the other screen but maybe only one of those will feel natural You guys might want to look into what's been done by HCI researchers in this area. One such article that comes to mind is Mouse Ether [1] which describes and tries to address the problems of dead space between monitors. There are many more articles on the topic in various HCI related conferences, those might definitely be a good start as those folks have already cleared a lot of theoretical and technical problems. Hope that helps. Rémi [1] http://www.patrickbaudisch.com/publications/2004-Baudisch-CHI04-MouseEther.pdf ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libSM 1.1.1
Hi all, Second time around, with a GPG signature this time. Here's a new release of libSM with quite a bit of code churn but no real new feature. See small ChangeLog below. Thanks, Rémi Adam Jackson (1): Avoid memcpy(foo, NULL, n), that's just nonsense. Alan Coopersmith (1): Add README with pointers to mailing list, bugzilla git repos Caolan McNamara (1): Bug #17644: Fix valgrind warning in _SmcProcessMessage Diego Elio 'Flameeyes' Pettenò (1): Use FreeBSD uuid functions when available. Julien Cristau (2): If we don't have libuuid, build without it instead of failing Typo fix Paulo Cesar Pereira de Andrade (2): avoid gcc warnings for libSM Janitor: ansification, make distcheck, compiler warnings. Rémi Cardona (1): libSM 1.1.1, update libtool version git tag: libSM-1.1.1 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.bz2 MD5: 6889a45549665b1fa05fc518d179 libSM-1.1.1.tar.bz2 SHA1: dc535af7328dee9a6121b85c3f8041656681a195 libSM-1.1.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.gz MD5: 1ee90d479298e48df7bb86a7ccbe00c9 libSM-1.1.1.tar.gz SHA1: 511a203cc5340c6cd621e88020843b9a10a90af0 libSM-1.1.1.tar.gz signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libSM 1.1.1
Hi all, Second time around, with a GPG signature this time. Here's a new release of libSM with quite a bit of code churn but no real new feature. See small ChangeLog below. Thanks, Rémi Adam Jackson (1): Avoid memcpy(foo, NULL, n), that's just nonsense. Alan Coopersmith (1): Add README with pointers to mailing list, bugzilla git repos Caolan McNamara (1): Bug #17644: Fix valgrind warning in _SmcProcessMessage Diego Elio 'Flameeyes' Pettenò (1): Use FreeBSD uuid functions when available. Julien Cristau (2): If we don't have libuuid, build without it instead of failing Typo fix Paulo Cesar Pereira de Andrade (2): avoid gcc warnings for libSM Janitor: ansification, make distcheck, compiler warnings. Rémi Cardona (1): libSM 1.1.1, update libtool version git tag: libSM-1.1.1 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.bz2 MD5: 6889a45549665b1fa05fc518d179 libSM-1.1.1.tar.bz2 SHA1: dc535af7328dee9a6121b85c3f8041656681a195 libSM-1.1.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.gz MD5: 1ee90d479298e48df7bb86a7ccbe00c9 libSM-1.1.1.tar.gz SHA1: 511a203cc5340c6cd621e88020843b9a10a90af0 libSM-1.1.1.tar.gz signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libSM 1.1.1
Hi all, Here's a new release of libSM with quite a bit of code churn but no real new feature. See small ChangeLog below. This being my first Xorg release, I apologize in advance for any screw ups. Thanks, Rémi Adam Jackson (1): Avoid memcpy(foo, NULL, n), that's just nonsense. Alan Coopersmith (1): Add README with pointers to mailing list, bugzilla git repos Caolan McNamara (1): Bug #17644: Fix valgrind warning in _SmcProcessMessage Diego Elio 'Flameeyes' Pettenò (1): Use FreeBSD uuid functions when available. Julien Cristau (2): If we don't have libuuid, build without it instead of failing Typo fix Paulo Cesar Pereira de Andrade (2): avoid gcc warnings for libSM Janitor: ansification, make distcheck, compiler warnings. Rémi Cardona (1): libSM 1.1.1, update libtool version git tag: libSM-1.1.1 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.bz2 MD5: 6889a45549665b1fa05fc518d179 libSM-1.1.1.tar.bz2 SHA1: dc535af7328dee9a6121b85c3f8041656681a195 libSM-1.1.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libSM-1.1.1.tar.gz MD5: 1ee90d479298e48df7bb86a7ccbe00c9 libSM-1.1.1.tar.gz SHA1: 511a203cc5340c6cd621e88020843b9a10a90af0 libSM-1.1.1.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev keyboard, messed arrow keys - how to fix it?
Le 12/07/2009 20:22, Tomasz Chmielewski a écrit : When using an evdev keyboard, arrow keys do not work as they should: - Left, Down - key works, but do not repeat - Up - key do not work at all - Right - works correctly Already reported at https://bugs.freedesktop.org/show_bug.cgi?id=17925 FTR, there's an increasing number of users getting bit by this, among various distro. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-siliconmotion 1.7.2
Le 10/07/2009 05:18, Robby Workman a écrit : Even with the patch applied to xorg-server-1.6.2, siliconmotion still errors out wanting xf86Parser.h and both nv and ati error out wanting xf86CursorPriv.h Am I missing something terribly obvious here? :/ You probably didn't run autoreconf after patching. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-siliconmotion 1.7.2
Le 10/07/2009 00:17, Robby Workman a écrit : In this case, it seems that xf86Parser.h isn't installed to /usr/include/xorg by xorg-server any more, while the nv issue was failure to include a private xorg header, but the point remains the same, I think... Hi Robby, You might want to add [1] to your xserver install. This will fix your nv build issue. Cheers, Rémi [1] http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branchid=396d3a7762abd0dd84042833b75f2ebf9d100bb0 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
Le jeudi 02 juillet 2009 à 09:27 -0700, Keith Packard a écrit : On Thu, 2009-07-02 at 12:48 +0200, Michel Dänzer wrote: You're probably right, glad it's not really an ABI breakage after all. Did you see the patch I proposed to fix the ABI breakage and provide both interfaces? Testing would be greatly appreciated as I only have Intel hardware these days... I'll backport the patch to Gentoo ASAP for some wider testing. Thanks for the patch. Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
Keith Packard a écrit : Could I get you to bisect for the problem? (it works for me...) It works for me as well unfortunately, I'll help the user to get the bisect ASAP. Thanks -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'server-1.6-branch' - 10 commits
Julien Cristau a écrit : This might not actually be due to ABI breakage, but mostly exposing an xf86-video-intel bug. When running a server without these changes, and xf86-video-intel hacked to disable dri2 on kms, the server crashes in libdrm_intel::drm_intel_gem_bo_alloc_internal(), i.e. the same thing that happens with the updated server, where DRI2ScreenInit() bails out. I haven't tried driver 2.7.1 or UMS. After talking with Julien, it seems that the 1.6.2 RC2 KMS failure I reported in the announce thread is the same bug. We've started tracking this in here. http://bugs.freedesktop.org/show_bug.cgi?id=22537 Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
Le 30/06/2009 01:03, Keith Packard a écrit : Kristian Høgsberg (1): Support setTexBuffer2 in AIGLX. Keith, That patch requires either some #ifdefs to make it build with mesa 7.4, or mesa's minimum version needs to be pushed to 7.5 in configure.ac. I have a preference for the former option, but the latter would fine too. Your call. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
Le 30/06/2009 01:03, Keith Packard a écrit : Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've pulled the remaining queued patches and have pushed this as 1.6.1.902 (1.6.2 RC2). If no-one finds any catastrophic bugs, I'll push this out as 1.6.2 shortly. This bug [1] is probably worth waiting for, as I've only been tracking the nominations page with our packages. So, one of the commits since Eamon's xace: Fix a bad device access hook call. seems to have broken KMS somehow. [1] http://bugs.freedesktop.org/show_bug.cgi?id=22537 Thanks for the new release Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: redirecting X11 output to a file
Le 14/06/2009 12:05, Werner LEMBERG a écrit : I want to compare the graphical output of different versions of a program pixel by pixel. To do that, I would like to divert the contents of the program's (single) X11 frame directly to a file -- a kind of automatic capturing without manual selection of the window. xwd is probably what you're looking for. convert should then be able to convert the dump's content to png or whatever format you like. Cheers, Rémi Cardona ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xfs problem on Ubuntu/Intrepid
Pierre Frenkiel a écrit : How can you explain that xfs needs to be restarted to work properly? This bug has already been fixed in xserver 1.6 and up. https://bugzilla.redhat.com/show_bug.cgi?id=430416 http://lists.freedesktop.org/archives/xorg/2008-August/037554.html http://cgit.freedesktop.org/~remi/xserver/commit/?id=f8dd80d13bb5313a11b38b280f8ad3e22f0a6300 Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to make xorg prefer nvidia over nv driver in a xorg.conf less configuration?
Francesco Pretto a écrit : 1) You've pointed me the driver loading priority is hardcoded in Xorg so can't be changed by normal users. Maybe HAL fdi policies files can be used to accomodate my task? HAL is only used for input drivers. So the answer here is no as well. 2) If there's no configurable option to solve this, this would de definitively a lacking feature: Xorg can't prefer one driver instead of another in a xorg.conf less configuration. So you want a configurable option *without* a configuration file? What's wrong with having a _really_ dumb xorg.conf that only has one Device section? In any case, feel free to send patches to this mailing list. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changing Xorg-Configuration on the fly
Leif Bergerhoff a écrit : How can I do this, or where can I find appropriate functions that will help me to do the job? Unless you're using the closed nVidia driver, the xrandr tool will do _exactly_ what you're looking for. Take a look at man xrandr, especially the --pos option. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Bug in Xextproto
Le 27/03/2009 19:55, Simon Thum a écrit : Hi, I'm bitten by this issue too and I'm somewhat lost with this. The patch has not yet been applied or commented on xorg, so I just want to make sure it's seen. Then render.h also needs something like this... Can't we work something out with Qt folks? Cheers Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Removing shadows underneath windows when using xcompmgr
Marius Gedminas a écrit : There are two more compositing managers that I've heard of: Metacity and whatever XFCE uses. Last time I checked, Metacity's compositing code looked very similar to xcompmgr's (using plain render, etc). I would be surprised if one were significantly faster than the other. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Auto-repeat with evdev 2.2.0
Martin MOKREJŠ a écrit : Confirming this issue with xf86-input-evdev-2.2.0 and xorg-server-1.5.3-r3 on Gentoo linux ~x86. I used to have xf86-input-evdev-2.1.3 before. I haven't tested the patch - yet. Donnie just committed 2.2.0-r1 with that patch. Consider the bug fixed :) Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: nvidia driver in lenny
Érico Teixeira a écrit : I´m trying to install nvidia driver in lenny [...] #lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics You have an Intel graphics card... You probably want the Intel driver instead. Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.2
Le 24/02/2009 23:46, Eric Anholt a écrit : Here comes a pretty significant bugfix release for the 2.6 2D series. In my limited testing, here's what I have so far : - 2.6.28 + EXA : works fine, seems to have actually solved a few 855 specific bugs, fencing maybe? - 2.6.28 + UXA : Acid Mode (tm) quickly followed by a xorg lock-up, SysReq keys to the rescue - git 2.6.29 + EXA/UXA : everything except the cursor looks like it got passed through a blender, I can barely make out the colors. I'm guessing broken tiling maybe? That's it for now, I'll try to bisect the first 2 issues. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: No package 'xcb-xlib' found
Le 24/02/2009 03:01, Pedro Izecksohn a écrit : Where it may be found? You need to rebuild xcb. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Drawing minimized windows
Le 16/02/2009 07:55, John Hamel a écrit : To clarify, I'm not just talking about previewing a window when you hover over it on the taskbar (which I assume would be done by accessing a snapshot of the window), I'm talking about having the window continue to be drawn while minimized so that compiz can access it to use in other functions such as scale and switcher. (An older version did have a hack to do it at one point.) Like Keith said, tell compiz not to Unmap windows when minimizing them and you'll be able to access their Composite pixmap all the time. Applications should continue to update their windows in this configuration. If it makes you feel any better, that's what we do in Metisse and it works fine. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Le 12/02/2009 09:38, Rene Rebe a écrit : Even more annoying is that the kdrive xvesa was deleted from the xorg-server git repository some weeks ago! http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d21fbf00648307208146aca0837ec63ea490659 Too bad the commit message does not even indicate why, ... Because it had been severely broken by other changes in the server and no-one really cared about it anyway. You'll probably be much better off using kdrive's Xfbdev on top of uvesafb or another kernel fb driver. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Rene Rebe a écrit : The random regressions and feature removal in the open source world these days really make one wonder. As far as Xvesa is concerned, it's hardly random at all. It's a pile of code that did the same job as the kernel's frame buffer infrastructure. Even regular Xorg has been going that way too with GEM and KMS. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Performance of XRenderCompositeTrapezoids in the aliased case
Le 02/02/2009 19:52, Clemens Eisserer a écrit : 2.) What do you think about a data structure where EXA drivers could tell EXA which features they support. This way EXA could e.g. choose to use A8 instead of A1 only when it really needed? This could help in various cases to decide which route to go. I think Geode users would love to see this since the HW doesn't even do A8 but only ARGB32, and for them, the glyph cache was major regression since it uses a lot of A8 pixmaps. Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: Disable all hotplugging features without CONFIG_HAL
Le 29/01/2009 02:19, Peter Hutterer a écrit :
Why do we need that on top of commit ace38fafb062372dcd3d56378b5b8f86525c6241?
xfree86: without CONFIG_HAL, Auto{Add|Enable}Devices and AEI is false.
Dan,
you might want to grab commit a54153e669fd293a47f0077bf25505dd545ddce2
along with Peter's patch. We're shipping both these patches in our
package for 1.5.3.
-
xfree86: don't reset Auto(Add|Enable)Devices, use defaults from xf86Globals
Without this, commit ace38fafb062372dcd3d56378b5b8f86525c6241 is useless
when HAL support is disabled.
Signed-off-by: Julien Cristau jcris...@debian.org
-
Cheers,
Rémi
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg server should wait HAL if it's not avail during init
Tino Keitel a écrit : If I got this right, this implies that HAL still detaches from the terminal after startup I'm just pointing out that HAL has all the necessary mechanisms for Doing It Right (tm). I don't know when the deamon process detaches from the console. This is left as an exercise for the OP. The original poster might want to look at the HAL code to make sure that it is indeed doing the right thing or not. With all the bits already in place, it shouldn't be hard to fix HAL, if it indeed needs fixing. Cheers :) -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg server should wait HAL if it's not avail during init
Tino Keitel a écrit : On Tue, Jan 20, 2009 at 10:18:10 +0100, Matija Šuklje wrote: Dne torek 20. januarja 2009 je Yan Li napisal(a): I suggest we add a short (5 seconds) busy-wait if hald is not usable. Isn't that more of a (distro's) init system problem? The problem is that most of those service dependency stuff ignores the fact that daemons may need some time to really become available for service. They just start a service and don't have a way to check if the service is really available. hald already has a pipe set up between the launcher process and the daemon process. The launcher process exits when it receives a message on the pipe from the daemon. Maybe that message could be delayed until HAL is _really_ up and running. This way, a proper init system will make X start up wait on hald being fully up. NB, I have only checked this file : http://cgit.freedesktop.org/hal/tree/hald/hald.c, I have no idea what goes on after the fork. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug in interaction between freeglut and mesa-7.3-rc2
Le 19/01/2009 08:52, Florian Echtler a écrit : Apologies. I misread the original message. For whatever reason (blame it on being Friday), I thought you were replacing glXMakeCurrent with glXMakeContextCurrent, not the other way around. Never mind, I was starting to get confused, too.. :-) There are two bugs in freeglut: - It calls a GLX 1.3 function on a system that doesn't support GLX 1.3. Could you check for GLX 1.3 at compile time? I suppose not, but maybe there is a way? You should check it at run-time, like any other X extension. The GLX spec [1] has a section on how to do precisely that. GLX 1.1 and newer implementations should support the version-querying calls such as glXQueryExtension and glXQueryVersion. [1] http://www.opengl.org/documentation/specs/glx/glx1.4.pdf Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/4] Cursor's update inside kernel only
Le 19/01/2009 19:03, Jesse Barnes a écrit : Gah, yeah forgot about drag drop of big icons... Maybe Kristian was right that all cursors should be done in software; hardware just doesn't provide the flexibility desktops want these days. Maybe there could be a way to prioritize input events over rendering requests within the server, but going full software for the cursor sounds like the best solution. It's only a pixmap after all... Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Window Manager: Intercepting mouse events
Le 16/01/2009 02:02, Bipin George Mathew a écrit : Is it possible to use a combination of XGrabButton on the root window and use XSendEvent to send the transformed co-ordinates? Here's a snippet of XSendEvent's man page : --- The XSendEvent function identifies the destination window, determines which clients should receive the specified events, and ignores any active grabs. --- It's still the server that determines which window gets the event. In a composited server, either the server needs to know the 3D geometry of each window (which I think is a bad idea), or you need to be able to specify which top-level window will receive the event. But I think with XGrabButton and XSendEvent, you'll run into other problems, such as receiving the input you've generated yourself. So for every click, you would have to Ungrab, SendEvent and Grab again... At least, that's how I understand it. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Window Manager: Intercepting mouse events
Le 12/01/2009 21:29, Bipin George Mathew a écrit : I am writing a window manager where I am transforming the window contents (using the composite extensions). After applying the transformation, I also need to ensure that mouse events are transformed and redirected to the XClients appropriately. What is the best way to do so? I came across this X Event extension - Xevie - Is this extension recommended for this WM use-case? There's no official extension to do that. And XEvIE has been broken for years and was removed a couple weeks ago from master. Besides, it didn't do what you want. Compiz folks had Xserver patches to add mesh-type OpenGL-like transforms to windows. Don't know what state those patches are in... Metisse (shameless plug) has working input-redirection but it requires an additional X server process. Both approaches have their advantages and shortcomings, pick your poison. :) Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Le 10/01/2009 17:58, Alan Coopersmith a écrit : It was moved to the module because the server never calls it directly - only the mouse module does, and if you're using another driver, like evdev or void, then the code is never called at all. Thanks for the explanation. Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Le 10/01/2009 05:45, Alan Coopersmith a écrit : The big change in 1.4.0 is the move of the OS-specific mouse handling code from the Xorg server to the mouse driver. This code was removed from the Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse driver to run with Xorg 1.6. Hi Alan, Just wondering: can this version of xf86-input-mouse get along with Xorg 1.5 or will they both attempt to control the same OS-specific details? Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Brainstorm] LinkKit for Xorg
Le 10/01/2009 03:10, Paulo César Pereira de Andrade a écrit : Xorg (and to some extent XFree86) loadable modules aren't really of much use, as modules cannot be properly unloaded, there is no dependency information; a module doesn't list it's dependencies in any form, causing frequently one to need to load a lot more code/data then required. Hi Paulo, Why not implement that instead? Sounds like reviving LinkKit will bring more cruft rather than clean up the current code... What's your ulterior motives with LinkKit anyway? Just curious :) Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PULL] input fixes for server-1.5-branch
Le 25/11/2008 02:09, Peter Hutterer a écrit : Ajax, Please pull a few input fixes for server-1.5-branch: What about this patch from you? We've had it in our branch for a while and it helped quite a few users. http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.0-force-SwitchCoreKeyboard-for-evdev.patch?view=markup Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] fix CARD* redefinition in xf86-video-intel
Hi all, Arjan sent a patch a month ago about this build bug. Basically, bios_reader.c redefines CARD* which is defined in some versions of hw/xfree86/ddc/edid.h, but was removed when vdif.h was dropped last year. Here's my attempt to fix it, hopefully in a better way (ie, new drivers should build with older servers). Thanks -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] From 6e8bf145b6b7449f81799581fdf5e5583a6d12ce Mon Sep 17 00:00:00 2001 From: =?utf-8?q?R=C3=A9mi=20Cardona?= [EMAIL PROTECTED] Date: Mon, 24 Nov 2008 13:26:27 +0100 Subject: [PATCH] xfree86: include X11/Xmd.h in edid.h to define CARD16 Xmd used to be included by the now defunct vdif.h, this should fix hacks in DDX video drivers (especially -intel) --- hw/xfree86/ddc/edid.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h index a4e79da..041bbfd 100644 --- a/hw/xfree86/ddc/edid.h +++ b/hw/xfree86/ddc/edid.h @@ -12,6 +12,8 @@ #ifndef _EDID_H_ #define _EDID_H_ +#include X11/Xmd.h + /* read complete EDID record */ #define EDID1_LEN 128 #define BITS_PER_BYTE 9 -- 1.6.0.4 From cd63414bc0efa0b9f1691e28be9ddfca9fef0486 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?R=C3=A9mi=20Cardona?= [EMAIL PROTECTED] Date: Mon, 24 Nov 2008 13:31:20 +0100 Subject: [PATCH] include X11/Xmd.h to define CARD16 needed by edid.h --- src/bios_reader/bios_reader.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/bios_reader/bios_reader.c b/src/bios_reader/bios_reader.c index 2a6906d..1e41778 100644 --- a/src/bios_reader/bios_reader.c +++ b/src/bios_reader/bios_reader.c @@ -38,9 +38,11 @@ #include ../i830_bios.h -typedef uint8_t CARD8; -typedef uint16_t CARD16; -typedef uint32_t CARD32; +/* backwards compatibility with edid.h from xorg-server 1.5 and older */ +#ifndef CARD16 +#include X11/Xmd.h +#endif + #define _PARSE_EDID_ #include edid.h -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] drop unused HAVE_LIBDRM_2_2
Hi all, Is there any reason not to apply this? airlied suggested I bring this here for further review. Thanks -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] From 6afd482e905aec048333fdd72579a08478a3f27a Mon Sep 17 00:00:00 2001 From: =?utf-8?q?R=C3=A9mi=20Cardona?= [EMAIL PROTECTED] Date: Mon, 17 Nov 2008 09:56:49 +0100 Subject: [PATCH] drop unused HAVE_LIBDRM_2_2 --- configure.ac|3 --- include/dix-config.h.in |3 --- 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 4bea8ac..3713050 100644 --- a/configure.ac +++ b/configure.ac @@ -861,9 +861,6 @@ AM_CONDITIONAL(DRI2, test x$DRI2 == xyes) if test x$DRI = xyes || test x$DRI2 = xyes; then PKG_CHECK_MODULES([LIBDRM], [libdrm = 2.3.0]) - PKG_CHECK_EXISTS(libdrm = 2.2.0, -[AC_DEFINE([HAVE_LIBDRM_2_2], 1, -[Has version 2.2 (or newer) of the drm library])]) AC_SUBST(LIBDRM_CFLAGS) AC_SUBST(LIBDRM_LIBS) fi diff --git a/include/dix-config.h.in b/include/dix-config.h.in index 5739a05..65b5950 100644 --- a/include/dix-config.h.in +++ b/include/dix-config.h.in @@ -121,9 +121,6 @@ /* Define to 1 if you have the inttypes.h header file. */ #undef HAVE_INTTYPES_H -/* Define to 1 if you have version 2.2 (or newer) of the drm library */ -#undef HAVE_LIBDRM_2_2 - /* Have Quartz */ #undef XQUARTZ -- 1.6.0.3 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP / Gnome / KDE / Data transfer / GTK QT / Xorg extension
Le 12/11/2008 22:54, Jean-Francois Bouchard a écrit : Problem : We experience very slow scroll speed (lets say, cat /var/log/messages) in Gnome terminal via XDMCP. (1M file : 1.5 minute to display) [snip] On the fat server ... X Protocol Version 11, Revision 0, Release 6.8.2 Kernel 2.6.9-78.0.1.ELsmp Gnome 2.8 ^^^ That's your problem, right there. vte as shipped in Gnome 2.8 was very slow and major performance profiling was done later on (in 2.12 or 2.14, I'm not sure). You should definitely try to update your fat server to a more recent Gnome stack. It might not be perfect and there's probably some more room left for improvements, but I think you'll find it a huge win over what you are currently using. Cheers Rémi Cardona ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Le 16/11/2008 02:43, Keith Packard a écrit : Anything on master is going into 1.6, unless we find regressions. Reading your mail, I was under the impression you'd be starting a 1.6 branch on top of 1.5 and then cherry-picking DRI2 and RR1.3 patches on top of it. I'm glad to hear you'll be using master directly. Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Le 14/11/2008 22:13, Keith Packard a écrit : I volunteered to manage an X server 1.6 release, tentatively scheduled for the end of the year (yes, this year, 2008). This release will include DRI2 and RandR 1.3 support. I'd like to know how much of the new Xinput stuff will be ready in time. Any chance to get the glyph cache in 1.6 or is it still considered too experimental? Thanks Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xcomposite examples
iain a écrit : On Thu, 2008-11-13 at 17:03 +0500, Alexei Babich wrote: Hi, all. Can anybody tell me, where I can find examples of the simple usage of the Xcomposite extension? For example, implementations of save_unders, backing_store, anything else, etc. Articles, books, howtos,... Thank you. http://ktown.kde.org/~fredrik/composite_howto.html xcompmgr is a good example too. It's quite straightforward once you rip out the code to handle/generate shadows. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] candidate patches for server-1.5-branch inclusion
Le 08/11/2008 01:58, Maarten Maathuis a écrit : This commit fixed that issue: http://cgit.freedesktop.org/xorg/xserver/commit/?id=21c116219cd5c6845a0955f2d88fdb5fab5c17cf Thanks for follow-up, Maarten. I've added this patch to the branch. For those who might be interested, I've rebased the EXA backport branch on top of xorg-server-1.5.3 and it's still available at the same location. http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch) Could this branch be considered for inclusion later on? Thanks Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] trivial patch to fix build using latin-but-not-quite locales (Turkish for example)
Hi all, Here's a small oneliner patch to fix xserver's build using locales that have latin-based alphabets but have different uppercasing/lowercasing rules as Western languages, such as Turkish [1]. Basically, this patch forces LC_ALL=C when running awk to generate hw/xfree86/common/xf86DefModeSet.c to force English lowercasing rules. This patch is currently applied in Gentoo on top of 1.5.2. Thanks [1] http://en.wikipedia.org/wiki/Dotted_and_dotless_I#In_computing -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] From 8918c50440de301887af8006f2dc72d64adf9f9c Mon Sep 17 00:00:00 2001 From: Remi Cardona [EMAIL PROTECTED] Date: Sat, 18 Oct 2008 12:23:51 +0200 Subject: [PATCH] force LC_ALL=C when running awk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This bug was reported by a user trying to build the server with a Turkish locale (tr_TR). The problem is that the Turkish alphabet is latin-based, but not entirely similar. The bug comes from vesamodes which has Interlaced, which is then converted to lowercase by modelines2c.awk. Execept that with a Turkish locale tolower(Interlaced) is not interlaced but ınterlaced, which the rest of the script fails to understand. This patch forces LC_ALL=C when running the awk script to always get the intended latin en_US alphabet. --- hw/xfree86/common/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/common/Makefile.am b/hw/xfree86/common/Makefile.am index 0f44075..723973a 100644 --- a/hw/xfree86/common/Makefile.am +++ b/hw/xfree86/common/Makefile.am @@ -24,7 +24,7 @@ BUSSOURCES = xf86isaBus.c xf86pciBus.c xf86fbBus.c xf86noBus.c $(SBUS_SOURCES) MODEDEFSOURCES = $(srcdir)/vesamodes $(srcdir)/extramodes xf86DefModeSet.c: $(srcdir)/modeline2c.awk $(MODEDEFSOURCES) - cat $(MODEDEFSOURCES) | $(AWK) -f $(srcdir)/modeline2c.awk $@ + cat $(MODEDEFSOURCES) | LC_ALL=C $(AWK) -f $(srcdir)/modeline2c.awk $@ BUILT_SOURCES = xf86DefModeSet.c -- 1.6.0.2 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Jesse Barnes a écrit : And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? I would say yes. dmesg says : [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged while Xorg.0.log says : (II) intel(0): xf86BindGARTMemory: bind key 5 at 0x03bff000 (pgoffset 15359) (EE) intel(0): Failed to pin back buffer: Cannot allocate memory Fatal server error: Couldn't bind memory for BO back buffer I've attached full logs on the intel-gfx mailing list : http://lists.freedesktop.org/archives/intel-gfx/2008-October/thread.html#348 Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. Again, any help will be greatly appreciated. Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Eric Anholt a écrit : I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. Hum, my apologies. Since I hadn't seen any announcement on xorg-announce since 2.3.1, I had wrongly assumed that version to be the latest release. Thanks, I'll get back to packing then :) Cheers ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Rémi Cardona a écrit : rendering errors in Firefox 3 and gnome-terminal (both of which use render). I've built everything using libdrm 2.4.0, so that's not an issue anymore. However, I can definitely confirm the rendering errors on my 855GM. See the attached screen shot. Should I file a bug? Thanks inline: Capture.png___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
