[ANNOUNCE] xf86-input-vmmouse 12.6.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (3): Remove xorgconfig xorgcfg from See Also list in man page Make --with-hal* configure options match their help output Map Solaris/Sun compiler #defines to gcc equivalents Shelley Gong (1): 1) Fix bug where motion notify events were being sent with every button event. GIT tag: xf86-input-vmmouse-12.6.4 df950f43c46895b5015cea759866da31 xf86-input-vmmouse-12.6.4.tar.bz2 31a36e7dfdbde6ba5ec1101c0186bbaee70b096e xf86-input-vmmouse-12.6.4.tar.bz2 http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.4.tar.bz2 28ed9c84edba1da222cfa5f93fafa928 xf86-input-vmmouse-12.6.4.tar.gz c099d0cfd99e97e464ad2a22292bb98027ec09d2 xf86-input-vmmouse-12.6.4.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.4.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoI4FkACgkQ+NaxlGp1aC4mLACfS4/V9M52uxPulDSS6Pp3mYZm cTsAoJO6vM4U7KJPLhRm7BPrhim6Brit =N1sW -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-geode 2.11.2
Chris Ball (5): Build fix: set EXA_DRIVER_KNOWN_MAJOR=3. configure: use AC_DEFINE instead of shell substitution Build fix: Include config.h earlier Revert EXA 3 build fix. Release 2.11.2. Kyle McMartin (1): Crasher fix: Use ExaDriverAlloc() to calloc the EXA struct. git tag: xf86-video-geode-2.11.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-geode-2.11.2.tar.bz2 MD5: 4c652ecba772f705296b8e52d746857c xf86-video-geode-2.11.2.tar.bz2 SHA1: 6528b45f3d08bb1685b23a620226f3f8263e9ebe xf86-video-geode-2.11.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-geode-2.11.2.tar.gz MD5: dc9cbe88f38f82e27dbfb66f9f99fc98 xf86-video-geode-2.11.2.tar.gz SHA1: 8f9b810c863aa883c495e4284764a5db898ee35d xf86-video-geode-2.11.2.tar.gz -- Chris Ball c...@laptop.org ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.7.1
This is a maintenance release on the 2.7 branch. Compared to 2.7.0 it consists only of a few carefully hand-picked fixes for bugs, (including GPU crashers). We encourage all users of 2.7.0 to upgrade to 2.7.1. We have verified that several of the reported bugs of GPU crashes, (mouse continues to move, but otherwise X is totally unresponsive), are fixed with the commit by Keith Packard in 2.7.1 to correct the computation of the batch space required. If you have previously reported a GPU-crash bug in bugs.freedesktop.org, please test with 2.7.1 and report your findings in the bug. If the crash is fixed, please celebrate with us! If the crash persists, please attach the output of intel_gpu_dump available here (and hopefully packaged in your distribution of choice soon): git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools (Requires Linux kernel = 2.6.30) Thanks to everyone who has helped to improve this driver! -Carl PS. The 2.7.1 release is equivalent (other than the version number) to the 2.7.0.901 release candidate announced earlier. How to obtain the release - git tag: 2.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.1.tar.bz2 MD5: 0eed17138da18ff1fb2b8ab0f076d957 xf86-video-intel-2.7.1.tar.bz2 SHA1: f863ee65b4b7779077af9f819b07033264284628 xf86-video-intel-2.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.1.tar.gz MD5: e8cc1d6fe60e23891704b3453f1f9dba xf86-video-intel-2.7.1.tar.gz SHA1: e43894e3d96f4b45e1191bc05bc2b8880844e15e xf86-video-intel-2.7.1.tar.gz Bug fixes since 2.7.0: -- * KMS: Hook up output properties for RANDR, (this allows output properties to be controlled in the KMS case just as in the UMS case). [Zhenyu Wang zhenyu.z.w...@intel.com] * Fix multiplication error when computing required batch space. This could fix any number of cases where the driver did inexplicable things (due to having computed the wrong size). [Keith Packard kei...@keithp.com] * Hold reference to video binding table until all rects are painted. This prevent general chaos in the buffer manager. [Keith Packard kei...@keithp.com] * Split i915 textured video commands to fit into batch buffers. Video and 3D setup commands share the same batch buffer, so without this fix, various problems could occur when video and 3D clients were both heavily active at the same time. [Keith Packard kei...@keithp.com] * Fix crash with XV with large virtual display ( 2049). [Albert Damen al...@gmx.net] * Provide missing value to 3D_STATE_VERTEX_BUFFERS command. We don't know that this was causing any problem, but the change does bring the driver into conformance with what the specification says the hardware requires here. [Keith Packard kei...@keithp.com] 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] xf86-video-geode 2.11.2
Chris Ball (5): Build fix: set EXA_DRIVER_KNOWN_MAJOR=3. configure: use AC_DEFINE instead of shell substitution Build fix: Include config.h earlier Revert EXA 3 build fix. Release 2.11.2. Kyle McMartin (1): Crasher fix: Use ExaDriverAlloc() to calloc the EXA struct. git tag: xf86-video-geode-2.11.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-geode-2.11.2.tar.bz2 MD5: 4c652ecba772f705296b8e52d746857c xf86-video-geode-2.11.2.tar.bz2 SHA1: 6528b45f3d08bb1685b23a620226f3f8263e9ebe xf86-video-geode-2.11.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-geode-2.11.2.tar.gz MD5: dc9cbe88f38f82e27dbfb66f9f99fc98 xf86-video-geode-2.11.2.tar.gz SHA1: 8f9b810c863aa883c495e4284764a5db898ee35d xf86-video-geode-2.11.2.tar.gz -- Chris Ball c...@laptop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
Emanuele Tamponi schrieb: In data lunedì 11 maggio 2009 14:48:51, walter harms ha scritto: maybe you can reproduce that with xev ? does ist happen with other inputs devices also ? keyboard ? I'll try with xev. Every mouse device stops working: wireless mouse and builtin trackpad. sounds like a strange bug in the subssystem. This is beyond my capabilities :( re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
On Tue, May 12, 2009 at 09:49:08AM +0200, walter harms wrote: Emanuele Tamponi schrieb: In data lunedì 11 maggio 2009 14:48:51, walter harms ha scritto: maybe you can reproduce that with xev ? does ist happen with other inputs devices also ? keyboard ? I'll try with xev. Every mouse device stops working: wireless mouse and builtin trackpad. sounds like a strange bug in the subssystem. This is beyond my capabilities :( no, actually. this is how input devices work. the physical devices are abstracted away through the virtual core pointer. all events go through this core pointer device, and if an application grabs it then events are no longer sent to anyone else. same with the keyboard. hence if you have a rogue grab, all devices seem to stop working. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
Peter Hutterer schrieb: On Tue, May 12, 2009 at 09:49:08AM +0200, walter harms wrote: Emanuele Tamponi schrieb: In data lunedì 11 maggio 2009 14:48:51, walter harms ha scritto: maybe you can reproduce that with xev ? does ist happen with other inputs devices also ? keyboard ? I'll try with xev. Every mouse device stops working: wireless mouse and builtin trackpad. sounds like a strange bug in the subssystem. This is beyond my capabilities :( no, actually. this is how input devices work. the physical devices are abstracted away through the virtual core pointer. all events go through this core pointer device, and if an application grabs it then events are no longer sent to anyone else. same with the keyboard. hence if you have a rogue grab, all devices seem to stop working. but only mouse events are missing, the keyboard seems to work fine At least i would notice very fast if someone is eating my letters. I think it is unlikely that a programm would only grap a mouse but not the keyboard. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xorg support to import options for non-Input sections?
I am trying to find out whether I can define options for non-input devices via HAL fdi files. My goal is to specify settings for sections like my video card, monitor or screen. I haven't been able to find anything that seems relevant anywhere and all examples I have found are exclusively related to keyboard or pointer settings. Is this possible (or planned)? Thanks! Kevin signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
On Tue, May 12, 2009 at 1:58 AM, Kevin Stange ke...@simguy.net wrote: I am trying to find out whether I can define options for non-input devices via HAL fdi files. My goal is to specify settings for sections like my video card, monitor or screen. I haven't been able to find anything that seems relevant anywhere and all examples I have found are exclusively related to keyboard or pointer settings. Is this possible (or planned)? No. Only the input devices pick up configuration through HAL, and I think people would prefer if that went away some day. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
On Tue, May 12, 2009 at 05:57:00PM +1000, Peter Hutterer wrote: no, actually. this is how input devices work. the physical devices are abstracted away through the virtual core pointer. all events go through this core pointer device, and if an application grabs it then events are no longer sent to anyone else. same with the keyboard. hence if you have a rogue grab, all devices seem to stop working. Are there any debugging facilities for finding out which X client has the grab? I once spent an hour killing all processes one by one until I found the one responsible (gnome-settings-daemon): http://mg.pov.lt/blog/xorg-snafu.html Marius Gedminas -- IBM motto: We found five vowels hiding in a corner, and we used them _all_ for the 'eieio' instruction so that we wouldn't have to use them anywhere else -- Linus Torvalds signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
On Tue, May 12, 2009 at 10:11:24AM +0200, walter harms wrote: Peter Hutterer schrieb: no, actually. this is how input devices work. the physical devices are abstracted away through the virtual core pointer. all events go through this core pointer device, and if an application grabs it then events are no longer sent to anyone else. same with the keyboard. hence if you have a rogue grab, all devices seem to stop working. but only mouse events are missing, the keyboard seems to work fine At least i would notice very fast if someone is eating my letters. I think it is unlikely that a programm would only grap a mouse but not the keyboard. To the extent of my understanding it's the usual thing in X land: applications (or, rather, toolkits) implement things like popup menus and drag-and-drop by grabbing only the mouse, while other applications (e.g. SSH/GPG password dialogs) grab only the keyboard. Marius Gedminas -- No sane person should use frame buffers if they have the choice. -- Linus Torvalds on lkml signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XSetWMProperties
Hi, What's the xcb replacement for XSetWMProperties() ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: server GLX version: GLX 1.3, GLX 1.4
Am Dienstag 12 Mai 2009 06:41:39 schrieben Sie: Thank you for your replys. Is there any chance to see server side support for GLX 1.3/1.4 soon? I found an article on Phoronix saying that GLX 1.4 support was planned for xorg-server 1.5: Yeah, it was added to xorg-server-1.5 ... so update your server, and you should be good to go. I'm afraid not. I have updated to xorg-server-1.6.1.901, but glxinfo still reports GLX 1.2. Also, in glxserver.h the define in line 70 is #define GLX_SERVER_MINOR_VERSION 2 and in glxscreen.c I see in line 165 static char GLXServerVersion[] = 1.2; It is the same in master: http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxserver.h http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxscreens.c Do these two entries need to be changed? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
Matt Price wrote: hi, snip So i'm wondering: does anyone out there have a multiseat system that actually can suspend and hibernate successfully? And if so, do you use the -sharevts switch when starting X, or do you have some other trick for getting the x sessions to display simultaneously? Hi Matt, I run a two-seater but never got suspend/hibernate to work. Did you make progress? Hugo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
Hugo Vanwoerkom escreveu: Matt Price wrote: hi, snip So i'm wondering: does anyone out there have a multiseat system that actually can suspend and hibernate successfully? And if so, do you use the -sharevts switch when starting X, or do you have some other trick for getting the x sessions to display simultaneously? Hi Matt, I run a two-seater but never got suspend/hibernate to work. Did you make progress? Mix this kind of things (suspend/hibernate + multiseat) can be explosive. Don't do that - at least until the KMS, with rootless servers, definitely arrives. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
On Tue, May 12, 2009 at 10:23 AM, Kevin Stange ke...@simguy.net wrote: Dan Nicholson wrote: On Tue, May 12, 2009 at 1:58 AM, Kevin Stange ke...@simguy.net wrote: I am trying to find out whether I can define options for non-input devices via HAL fdi files. Â My goal is to specify settings for sections like my video card, monitor or screen. Â I haven't been able to find anything that seems relevant anywhere and all examples I have found are exclusively related to keyboard or pointer settings. Is this possible (or planned)? No. Only the input devices pick up configuration through HAL, and I think people would prefer if that went away some day. So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. The reason I kind of like this method is because I don't have to define the device in the xorg.conf, so if it's not present/detected I'm basically not telling xorg to expect it (or so it seems to me). Does xorg keep track of relevant sections should the devices appear via HAL later to load in their options? Right, those are the reasons the HAL fdi is being used now for configuration and it's the way you should be doing it if you want hotpluggable input devices. The reason it's disliked is because it's an abuse of HAL's fdi system. No one has a plan for a better system wide configuration as far as I know, though. I have an idea for specifying an InputClass in xorg.conf, but it only exists in my mind. :) What is more being pushed for is that users just setup the input devices in their session rather than relying on a system-wide configuration. The input properties code supports this (try the xinput app), but it's not widely used yet. I suppose the definitions are necessarily more important for input devices which get hotplugged a lot more than video cards. The HAL hotplugging is only wired up for input devices. I think for video cards (or more likely outputs like monitors and projectors), the idea is to use drm to get notification from the kernel when hotplug events occur, but I could be way off base there. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
On Tue, 2009-05-12 at 14:29 -0300, Tiago Vignatti wrote: Hugo Vanwoerkom escreveu: Matt Price wrote: hi, snip So i'm wondering: does anyone out there have a multiseat system that actually can suspend and hibernate successfully? And if so, do you use the -sharevts switch when starting X, or do you have some other trick for getting the x sessions to display simultaneously? Hi Matt, I run a two-seater but never got suspend/hibernate to work. Did you make progress? Mix this kind of things (suspend/hibernate + multiseat) can be explosive. Don't do that - at least until the KMS, with rootless servers, definitely arrives. i never got it to work. it's a shame, because i still consider hibernate an essential element of the system. there's work right now to merge tuxonice, finally, but the truth is that this functionality has never been taken seriously by linus or the other main kernel devs. bummer, really. matt Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Matt Price matt.pr...@utoronto.ca ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: multiseat, -sharevts, and suspend/hibernate
-Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Tiago Vignatti Sent: Tuesday, May 12, 2009 10:29 AM To: Hugo Vanwoerkom Cc: x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate Mix this kind of things (suspend/hibernate + multiseat) can be explosive. Don't do that - at least until the KMS, with rootless servers, definitely arrives. I'm confused. What does rootless servers have to do with multiseat? Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
McDonald, Michael-p7438c escreveu: I'm confused. What does rootless servers have to do with multiseat? In the current implementation, multiseat implies in several servers in parallel, which in turn implies in hardware accesses in parallel (mostly not coordinated by anyone), which in turn mess your system. Uoow! Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
Colin Guthrie wrote: 'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) And for non-Linux systems? HAL is OS-agnostic, udev seems very Linux specific. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
On Tue, 12 May 2009 10:46:43 -0700 Dan Nicholson dbn.li...@gmail.com wrote: On Tue, May 12, 2009 at 10:23 AM, Kevin Stange ke...@simguy.net The reason I kind of like this method is because I don't have to define the device in the xorg.conf, so if it's not present/detected I'm basically not telling xorg to expect it (or so it seems to me). Does xorg keep track of relevant sections should the devices appear via HAL later to load in their options? Right, those are the reasons the HAL fdi is being used now for configuration and it's the way you should be doing it if you want hotpluggable input devices. The reason it's disliked is because it's an abuse of HAL's fdi system. No one has a plan for a better system wide configuration as far as I know, though. I have an idea for specifying an InputClass in xorg.conf, but it only exists in my mind. :) What is more being pushed for is that users just setup the input devices in their session rather than relying on a system-wide configuration. I think this should really be the way to go. Though I guess that is more of a distribution issue, than one of Xorg. For the keyboard a call to setxkbmap should be enough. The input properties code supports this (try the xinput app), but it's not widely used yet. Thanks for the hint. I was looking for a tool to set pointer properties programmatically. I suppose the definitions are necessarily more important for input devices which get hotplugged a lot more than video cards. The HAL hotplugging is only wired up for input devices. I think for video cards (or more likely outputs like monitors and projectors), the idea is to use drm to get notification from the kernel when hotplug events occur, but I could be way off base there. I hope not. The sooner HAL dies the better (don't want to start a flame war here. but I have a strong aversion to HAL). harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: multiseat, -sharevts, and suspend/hibernate
-Original Message- From: Tiago Vignatti [mailto:vigna...@freedesktop.org] Sent: Tuesday, May 12, 2009 2:02 PM To: McDonald, Michael-p7438c Cc: x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate McDonald, Michael-p7438c escreveu: I'm confused. What does rootless servers have to do with multiseat? In the current implementation, multiseat implies in several servers in parallel, which in turn implies in hardware accesses in parallel (mostly not coordinated by anyone), which in turn mess your system. Uoow! I understand the difficulties in running multiple X servers. I don't understand how rootless servers are going to make it easier. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Colin Guthrie wrote: 'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) And for non-Linux systems? HAL is OS-agnostic, udev seems very Linux specific. Well, there's DeviceKit, but I don't think anyone has any plans for DeviceKit-input or DeviceKit-graphics. I'd personally like to see an abstraction layer rather than putting one into Xorg. You don't consider HAL an reasonable abstraction layer? robert. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Robert Noland rnol...@2hip.net 2Hip Networks 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: Xorg support to import options for non-Input sections?
On Tue, May 12, 2009 at 3:33 PM, Robert Noland rnol...@2hip.net wrote: On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Colin Guthrie wrote: 'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) And for non-Linux systems? HAL is OS-agnostic, udev seems very Linux specific. Well, there's DeviceKit, but I don't think anyone has any plans for DeviceKit-input or DeviceKit-graphics. I'd personally like to see an abstraction layer rather than putting one into Xorg. You don't consider HAL an reasonable abstraction layer? Not when its creators are trying to get rid of it. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg support to import options for non-Input sections?
On Tue, 2009-05-12 at 16:16 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 3:33 PM, Robert Noland rnol...@2hip.net wrote: On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Colin Guthrie wrote: 'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) And for non-Linux systems? HAL is OS-agnostic, udev seems very Linux specific. Well, there's DeviceKit, but I don't think anyone has any plans for DeviceKit-input or DeviceKit-graphics. I'd personally like to see an abstraction layer rather than putting one into Xorg. You don't consider HAL an reasonable abstraction layer? Not when its creators are trying to get rid of it. Well, I think that our gnome folks are planning to support DeviceKit as it's replacement. If we are going to support dynamic device detection, then I think the most reasonable approach is to support an OS independent or at least cross platform API. robert. -- Dan -- Robert Noland rnol...@2hip.net 2Hip Networks 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: Xorg support to import options for non-Input sections?
On Tue, May 12, 2009 at 4:41 PM, Robert Noland rnol...@2hip.net wrote: On Tue, 2009-05-12 at 16:16 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 3:33 PM, Robert Noland rnol...@2hip.net wrote: On Tue, 2009-05-12 at 15:24 -0700, Dan Nicholson wrote: On Tue, May 12, 2009 at 2:41 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Colin Guthrie wrote: 'Twas brillig, and Kevin Stange at 12/05/09 18:23 did gyre and gimble: So you're saying this HAL method is widely (or narrowly, but by the right people) disliked? Using Gentoo it seems to be encouraged, and I've seen indications other distros (like Ubuntu) have picked up the technique as well. HAL will eventually be phased out in favour of getting more direct information from udev. I'm not sure how that will impact the Xorg side of things but i'd imagine the end solution will be in some way related to udev. (this is just a guess tho) And for non-Linux systems? HAL is OS-agnostic, udev seems very Linux specific. Well, there's DeviceKit, but I don't think anyone has any plans for DeviceKit-input or DeviceKit-graphics. I'd personally like to see an abstraction layer rather than putting one into Xorg. You don't consider HAL an reasonable abstraction layer? Not when its creators are trying to get rid of it. Well, I think that our gnome folks are planning to support DeviceKit as it's replacement. If we are going to support dynamic device detection, then I think the most reasonable approach is to support an OS independent or at least cross platform API. Right. The issue is that DeviceKit is not a catch all for any piece of hardware that could show up like HAL is. There are smaller niche DKs like DeviceKit-disks and DeviceKit-power right now. Like I said, I don't think anyone is planning DeviceKit-input to abstract input devices. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
On Tue, May 12, 2009 at 3:30 PM, McDonald, Michael-p7438c michael.mcdon...@gdc4s.com wrote: -Original Message- From: Tiago Vignatti [mailto:vigna...@freedesktop.org] Sent: Tuesday, May 12, 2009 2:02 PM To: McDonald, Michael-p7438c Cc: x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate McDonald, Michael-p7438c escreveu: I'm confused. What does rootless servers have to do with multiseat? In the current implementation, multiseat implies in several servers in parallel, which in turn implies in hardware accesses in parallel (mostly not coordinated by anyone), which in turn mess your system. Uoow! I understand the difficulties in running multiple X servers. I don't understand how rootless servers are going to make it easier. If your server is rootless, than by necessity it must properly obtain resources and will not be allowed to stomp on another processes' resources. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
On Tue, May 12, 2009 at 04:35:51PM +0300, Marius Gedminas wrote: On Tue, May 12, 2009 at 05:57:00PM +1000, Peter Hutterer wrote: no, actually. this is how input devices work. the physical devices are abstracted away through the virtual core pointer. all events go through this core pointer device, and if an application grabs it then events are no longer sent to anyone else. same with the keyboard. hence if you have a rogue grab, all devices seem to stop working. Are there any debugging facilities for finding out which X client has the grab? I once spent an hour killing all processes one by one until I found the one responsible (gnome-settings-daemon): http://mg.pov.lt/blog/xorg-snafu.html if you have a second machine you can ssh+gdb in and look at CLIENT_BITS(inputInfo.pointer-deviceGrab.grab-resource). this should give you the client mask for the grab, and with xwininfo -root -children -all you can then match that up with a running client (that's from memory, no guarantees) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.7.1
This is a maintenance release on the 2.7 branch. Compared to 2.7.0 it consists only of a few carefully hand-picked fixes for bugs, (including GPU crashers). We encourage all users of 2.7.0 to upgrade to 2.7.1. We have verified that several of the reported bugs of GPU crashes, (mouse continues to move, but otherwise X is totally unresponsive), are fixed with the commit by Keith Packard in 2.7.1 to correct the computation of the batch space required. If you have previously reported a GPU-crash bug in bugs.freedesktop.org, please test with 2.7.1 and report your findings in the bug. If the crash is fixed, please celebrate with us! If the crash persists, please attach the output of intel_gpu_dump available here (and hopefully packaged in your distribution of choice soon): git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools (Requires Linux kernel = 2.6.30) Thanks to everyone who has helped to improve this driver! -Carl PS. The 2.7.1 release is equivalent (other than the version number) to the 2.7.0.901 release candidate announced earlier. How to obtain the release - git tag: 2.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.1.tar.bz2 MD5: 0eed17138da18ff1fb2b8ab0f076d957 xf86-video-intel-2.7.1.tar.bz2 SHA1: f863ee65b4b7779077af9f819b07033264284628 xf86-video-intel-2.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.1.tar.gz MD5: e8cc1d6fe60e23891704b3453f1f9dba xf86-video-intel-2.7.1.tar.gz SHA1: e43894e3d96f4b45e1191bc05bc2b8880844e15e xf86-video-intel-2.7.1.tar.gz Bug fixes since 2.7.0: -- * KMS: Hook up output properties for RANDR, (this allows output properties to be controlled in the KMS case just as in the UMS case). [Zhenyu Wang zhenyu.z.w...@intel.com] * Fix multiplication error when computing required batch space. This could fix any number of cases where the driver did inexplicable things (due to having computed the wrong size). [Keith Packard kei...@keithp.com] * Hold reference to video binding table until all rects are painted. This prevent general chaos in the buffer manager. [Keith Packard kei...@keithp.com] * Split i915 textured video commands to fit into batch buffers. Video and 3D setup commands share the same batch buffer, so without this fix, various problems could occur when video and 3D clients were both heavily active at the same time. [Keith Packard kei...@keithp.com] * Fix crash with XV with large virtual display ( 2049). [Albert Damen al...@gmx.net] * Provide missing value to 3D_STATE_VERTEX_BUFFERS command. We don't know that this was causing any problem, but the change does bring the driver into conformance with what the specification says the hardware requires here. [Keith Packard kei...@keithp.com] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: multiseat, -sharevts, and suspend/hibernate
-Original Message- From: Dan Nicholson [mailto:dbn.li...@gmail.com] Sent: Tuesday, May 12, 2009 4:51 PM To: McDonald, Michael-p7438c Cc: vigna...@freedesktop.org; x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate If your server is rootless, than by necessity it must properly obtain resources and will not be allowed to stomp on another processes' resources. Ahhh. You're defining the kernel's KMS screen as the root window, therefore all window systems, X included, are rootless. Got it. Thanks. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
On Tue, May 12, 2009 at 5:37 PM, McDonald, Michael-p7438c michael.mcdon...@gdc4s.com wrote: -Original Message- From: Dan Nicholson [mailto:dbn.li...@gmail.com] Sent: Tuesday, May 12, 2009 4:51 PM To: McDonald, Michael-p7438c Cc: vigna...@freedesktop.org; x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate If your server is rootless, than by necessity it must properly obtain resources and will not be allowed to stomp on another processes' resources. Ahhh. You're defining the kernel's KMS screen as the root window, therefore all window systems, X included, are rootless. Got it. Thanks. No, I was thinking more that if the xserver is not run by root, it can't just have its way with the PCI resources. Then it can't wreak havoc on what another xserver is doing with them, either. So, I think that Tiago means that if the xserver is rootless, then it will implicitly be accessing the hardware properly though the kernel and will not interfere with another xserver trying to access the hardware. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: multiseat, -sharevts, and suspend/hibernate
-Original Message- From: Dan Nicholson [mailto:dbn.li...@gmail.com] Sent: Tuesday, May 12, 2009 5:48 PM To: McDonald, Michael-p7438c Cc: vigna...@freedesktop.org; x...@freedesktop.org Subject: Re: multiseat, -sharevts, and suspend/hibernate No, I was thinking more that if the xserver is not run by root, it can't just have its way with the PCI resources. Then it can't wreak havoc on what another xserver is doing with them, either. So, I think that Tiago means that if the xserver is rootless, then it will implicitly be accessing the hardware properly though the kernel and will not interfere with another xserver trying to access the hardware. OK, so he meant running without root permissions. A rootless server has an existing meaning and I couldn't see how that would help multiseat. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.1
Carl Worth wrote: * Fix crash with XV with large virtual display ( 2049). [Albert Damen al...@gmx.net] It's not what I would call fixed. With 2.6.*, XV with large virtual display would crash the server. With 2.7.1, it just gives BadAlloc errors and shows nothing. That's still pretty far from the 2.3.* behavior, where it Actually Worked. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
