[ANNOUNCE] xf86-input-vmmouse 12.6.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brown paper bag release. There was a pointless call to iopl() in the detection utility which made it non-portable to non-Linux operating systems. Philip Langdale (2): Remove call to iopl(). It's not portable and isn't necessary. Bump for 12.6.1 release. GIT tag: xf86-input-vmmouse-12.6.1 4e05e89d8b9503ced5fb4662cabbefbd xf86-input-vmmouse-12.6.1.tar.bz2 a0613f940d0ec4ede1eecdd91d0cac2f62b442b7 xf86-input-vmmouse-12.6.1.tar.bz2 http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.1.tar.bz2 5f6c837fc371e33437b0c80758f042c7 xf86-input-vmmouse-12.6.1.tar.gz 1373f14bbc028116628e6708294da6586276415e xf86-input-vmmouse-12.6.1.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkBbvQACgkQ+NaxlGp1aC7r+gCgs0TI/XqIPplLfxyoKMhIA/mZ cuAAnjZOGbVY2dQsZA6DT641U7YCEgAX =Rd+L -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.4.98
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. Looks like we won't get *all* the blockers fixed, but I think we did pretty well. Changelog from 2.4.97 below. Thanks, Jesse Adam Jackson (1): Fix Mac mini crash in DDC mode probe Bryce Harrington (1): Add TV out quirk for HP Compaq nx6110 Carl Worth (8): Examine picture repeatType as well as repeat field. Add support for RepeatPad and RepeatReflect. Prefer repeatType field over using both repeat and repeatType. Fallback to software for RepeatNone with transformed RGB-only pictures. Revert Fallback to software for RepeatNone with transformed RGB-only pictures. Rename default_color to border_color Document and use 'legacy' border color mode Disable frame buffer compression by default for GM965. Daniel Stone (1): i830: Fix timer leak Dave Airlie (1): mode: fix missing comma David Schleef (1): Bug #17277: fix upscaling limit Eamon Walsh (2): Remove unused exa_pixmap_key. Change uxa private keys to integer variables. Eric Anholt (12): Add some MCHBAR registers for debugging tile swizzling issues. Bug #17446: Don't try to manage IRQs in GEM mode. Track move of bufmgr functions to libdrm_intel. Track the move of irq emit/wait to fake bufmgr. Track move of exec to bufmgr, and restoration of emit/wait funcs for non-drm. Work around libpciaccess reporting a 0 rom size by guessing. Add support for RepeatPad and RepeatReflect to 915 and 830-class Render accel. Fix bios_reader build against old servers. Fix driver build against server 1.4.2. Add a GTT dumper for G4x debugging. Fix broken stolen memory counting on G4X. Remove gratuitous flushing in EXA after solid operations. Fabio (1): Man page patch to clarify meaning of VideoRam option with i810/i815 Jesse Barnes (15): Update version to post-2.5 Fix UXA build for distcheck Fix build when using kernel DRM headers Only BO map render state if kernel mode setting is active Add Cappuccino SlimPRO SP625F to no LVDS quirks list Add no TV out quirk for HP Compaq nx6110 Revert Add no TV out quirk for HP Compaq nx6110 Update supported hardware list Work around gcc uninitialized variable warnings Use -Werror by default Use VBT LFP info pointers by default Be more verbose about panel data in VBIOS dumper Revert Use -Werror by default Document more VBIOS functionality Update version to 2.4.98 for 2.5.0 release candidate Julien Cristau (1): Typo fix Keith Packard (6): Use uintptr_t instead of uint64_t to hold pointer value Eliminate INT10 call to get BIOS contents i830 nondrm batch buffer insertion was missing ADVANCE_LP_RING() call For non-DRM, add NOOPs after BATCH_BUFFER_START to verify completion XAA tiling support was mis-computing adjusted pitch (4 instead of 2) Handle differently tiled front/back/depth/third in DRI window management Lukas Hejtmanek (1): Fix driver build against server master. Olivier Fourdan (1): Fix ordering of VGA vs. plane disable Robert Noland (2): Check for drm before calling modeset ioctl. Fix typo in last commit Shuang He (1): Fix a typo in G965 texture video code Stefan Dirsch (1): Pipe A force quirk for Toshiba Satellite A30. Xiang, Haihao (4): Put back check for pI830-hw_status in setting hws in non-GEM mode. Move bufmgr init earlier so it's available at I830DRIDoMappings time. Put back check for pI830-hw_status in setting hws in non-GEM mode. Move bufmgr init earlier so it's available at I830DRIDoMappings time. Zhenyu Wang (15): Destroy bufmgr after allocation finish Fix X exit crash in NoAccel Disable render standby Add support for G41 chipset Check display stride limit when allocate front buffer Fix output detection for DVI-I Bug #16515: Fix VT switch with DVI on G45 Do force CRT detect sequence twice on 4 series chipset Render register clock gating disable fix on 4 series chipset Bug #16631: add option for SDVO force detect Put forware VBIOS data parsing Remove Lenovo T61 TV quirk Bug #17892: Fix possible crash in CRT probe Make GTT dumper work on other 9XX chips Don't handle irq in GEM mode git tag: xf86-video-intel-2.4.98.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.98.0.tar.bz2 MD5: e3ab56e8d15205ab63978d0336fd385f xf86-video-intel-2.4.98.0.tar.bz2 SHA1: 8213fc95ceaa347cf96f70375d8820818b406400 xf86-video-intel-2.4.98.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.98.0.tar.gz MD5: 9ed649916cc1f1a57bcdde6619c294d6
[ANNOUNCE] xf86-input-vmmouse 12.6.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brown paper bag release. There was a pointless call to iopl() in the detection utility which made it non-portable to non-Linux operating systems. Philip Langdale (2): Remove call to iopl(). It's not portable and isn't necessary. Bump for 12.6.1 release. GIT tag: xf86-input-vmmouse-12.6.1 4e05e89d8b9503ced5fb4662cabbefbd xf86-input-vmmouse-12.6.1.tar.bz2 a0613f940d0ec4ede1eecdd91d0cac2f62b442b7 xf86-input-vmmouse-12.6.1.tar.bz2 http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.1.tar.bz2 5f6c837fc371e33437b0c80758f042c7 xf86-input-vmmouse-12.6.1.tar.gz 1373f14bbc028116628e6708294da6586276415e xf86-input-vmmouse-12.6.1.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkBbvQACgkQ+NaxlGp1aC7r+gCgs0TI/XqIPplLfxyoKMhIA/mZ cuAAnjZOGbVY2dQsZA6DT641U7YCEgAX =Rd+L -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: On Fri, Oct 24, 2008 at 08:50:20AM +0200, Søren Hauberg wrote: 2008/10/24 Peter Hutterer [EMAIL PROTECTED]: Touchscreen support (courtesy of Søren) enables devices that report only BTN_TOUCH capability, but no BTN_LEFT, BTN_RIGHT, etc. Great! The only major thing left is then to be able to calibrate a touch screen. I haven't been able to come up with anything better than my original patch, which essentially did a if (is_touch_screen) transform_data_according_to_calibration () for every event. My impression is that you don't like this approach. Is that correct? I wasn't happy with it because I wanted to avoid double scaling (once in the driver, once in the server). But as I haven't found a better way to get the same thing (not w/o changing the server and XI), I'm willing to put it in. Need to have a look at it again though. While I know zilch about all this stuff, would the input redirection stuff help here? I read the article recently about how compiz is using this approach (albeit with patches that may or may not be the final way to do it). http://smspillaz.wordpress.com/2008/10/21/input-redirection-update/ -- 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: modular: Changes to 'master'
Hi, On Tue, Oct 21, 2008 at 09:51:45AM -0700, Keith Packard wrote: On Tue, 2008-10-21 at 18:15 +0200, Luc Verhaegen wrote: Is there a single technical reason why shipping both is a problem? For the same reason the kernel avoids shipping multiple drivers for the same hardware -- we want a unique PCI-ID - driver mapping so that all X.org downstream users share the same code base for their hardware. Forking driver development is a great way to explore new ideas and demonstrate new technologies, but in the long-term, we really want the best ideas to be integrated into a single driver for each device. Well, there might be some merit in only having a single driver for each piece of hardware (though I'm not entirely convinced of that) -- but on what grounds do you decide which one gets the preference? Dropping radeonhd looks like a totally arbitrary decision to me. After all, radeonhd has been added before radeon gained newer chipset support, and I really fail to see why radeon-now-with-r500+ should be treated as the official driver, and radeonhd as some alien... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Fri, Oct 24, 2008 at 11:43:03AM +0200, Søren Hauberg wrote: Yeah, I can understand that. As I think I've made quite clear in previous posts: I'm stupid. That is, I don't really know X. So, here's a stupid question [1]: the server scales from what ever the driver reports to some range. So, how does the server know the range of the input, and the range of the output? xf86InitValuatorAxisStruct() provides the server with the range. If the range is valid (i.e. min max), then the server scales absolute coordinates from the device into the min..max range. However, you can only supply this range when you initialise the device. The server does not support a change in range at runtime. To be more precise, the protocol doesn't provide a method to inform clients about this change, hence you're not allowed to touch it (the server doesn't care). The patch I suggested scaled the raw x-coordinate from the touch screen from [a_x, b_x] to [min_x, max_x], where a is the smallest value reportable by the touch screen, and b is the largest. min_x and max_x are the values available in pEvdev. It seems to me that scaling is a linear transformation, so the two scalings (in the driver and in the server) should be reducable to one scaling, by combining the parameters of the two scalings. I'm not sure of this as I don't know which parameters are used in the server. it can be combined, if you specify the correct min/max range in the config (or you let it get picked up from the kernel). Then the driver doesn't need scaling, the server does it. For calibration, that doesn't work. Or to be more precise, it only works if you restart the server with the calibrated values. Otherwise, you need a separate (duplicate) scaling mechanism in the driver. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
ati radeon : hangs between CTRL+ALT+Fx's
Hi, I have an ugly problem with X hangs. Just a while ago, before xorg-server 1.5.2, xf86-video-ati used to work perfect, even with hibernation. Now xf86-video-ati from git hangs by blanking 2 thirds of the screen, when switching CTRL+ALT+Fx or resuming from hibernation. DRI option enabled or not, it makes no difference; or with or without drm and radeon modules builtin. (those from git x11-drm do not work with 2.6.26 kernel.) Finding similar posts, I tried using NoAccel on: seems to work, yes, but too slow. Option AccelMethod set to EXA has a similar behaviour. These group of options together seem to mask the bug, especially XAANoPixmapCache, just that alone takes longer to freeze again. Option XAANoImageWriteRect# Option XAANoOffscreenPixmaps # Option XAANoPixmapCache # Option XAANoScreenToScreenCopy# Option XAANoSolidFillRect # Option XAANoSolidFillTrap # The device section is: Section Device # Identifier ATI Radeon Xpress 200M [RC410] # Driver radeon # # Chipset ATI Radeon XPRESS 200M 5A62 (PCIE) # ChipID 0x5A62 # BusID PCI:1:5:0 # # Option Monitor-LVDS LCD 15.4'' WXGA# Option Monitor-VGA-0 Missing # # #: sw_cursor is needed for some ati and radeon cards :# ## Option SW_cursor true # Option DynamicClocks on # # #: (II) Render acceleration unsupported on Radeon 9500/9700 and newer. :# Option RenderAccel off# #0 Option NoAccel on # #0 Option AccelMethod EXA# Option AccelMethod XAA# # Option XAANoImageWriteRect# Option XAANoOffscreenPixmaps # Option XAANoPixmapCache # Option XAANoScreenToScreenCopy# Option XAANoSolidFillRect # Option XAANoSolidFillTrap # # Option NoDDC true # Option DDCMode off# Option IgnoreEDIDon # #! Option BusType PCI# Option VGAAccess off# Option Int10 off# # #x Option UseInternalAGPGARTyes# Option GARTSize 64 # Option AGPMode 4 # Option AGPFastWrite 1 # Option DMAForXv 1 # # Option EnablePageFlip1 # Option ColorTiling 1 # Option SubPixelOrder RGB# # #! Option DRI off# Option DRI off# # #! Option ModeDebug false # Option Backingstore on # EndSection # Is this a server or a driver or a conf. bug? Thanks -- S. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ati radeon : hangs between CTRL+ALT+Fx's
On Fri, Oct 24, 2008 at 8:45 AM, Sebastian Glita [EMAIL PROTECTED] wrote: Hi, I have an ugly problem with X hangs. Just a while ago, before xorg-server 1.5.2, xf86-video-ati used to work perfect, even with hibernation. Now xf86-video-ati from git hangs by blanking 2 thirds of the screen, when switching CTRL+ALT+Fx or resuming from hibernation. DRI option enabled or not, it makes no difference; or with or without drm and radeon modules builtin. (those from git x11-drm do not work with 2.6.26 kernel.) Finding similar posts, I tried using NoAccel on: seems to work, yes, but too slow. Option AccelMethod set to EXA has a similar behaviour. Try removing all of the options in your config and see if that helps. Also, this option: Option AGPFastWrite 1 Will almost always cause problems. Remove that. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: failed to find pci graphics card - Self compiled xorg from git
On Friday 24 October 2008 15:43:44 Bill Crawford wrote: On Friday 24 October 2008 15:37:57 Mateusz Jan Dominikowski wrote: BusidPCI:0:1:1 Try 0:1:0 Ignore me, I'm especially blind today. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/24 Peter Hutterer [EMAIL PROTECTED]: it can be combined, if you specify the correct min/max range in the config (or you let it get picked up from the kernel). Then the driver doesn't need scaling, the server does it. For calibration, that doesn't work. Or to be more precise, it only works if you restart the server with the calibrated values. Otherwise, you need a separate (duplicate) scaling mechanism in the driver. Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: On Fri, Oct 24, 2008 at 10:59:25AM +0100, Colin Guthrie wrote: It seems that my usb mouse wanted to make double clicks rather than single clicks when I tried this driver. Not overly sure why! When trying to update the xserver and getting inspired by the Fedora patches, I noticed a few that related to double events and AllowEmptyInput setting. As I had AllowEmptyInput set to on, could this be responsible for turning the two single clicks events into one double click? Right, the server is picking the same device up twice (evdev + kbd/mouse). Unfortunately, only some of these patches are upstream yet. Your setup needs: 1. the xserver patch to switch the console mode to RAW (d936a423) 2. the xserver patch to enable AllowEmptyInput to TRUE (0b56b44a) 3. the patch below to disable kbd/mouse if AEI is on. This is one that would break non-linux systems and leave them without input. I need to fix that up. For now, just having a ServerLayout section in your config should do the job. Probably no config should work too, but I haven't tried that without 3. yet. Thanks for the info Peter. I did actually have the patch below already applied but had to turn AEI off to get keyboard support at KDM login. I suspect I just need to make sure I load evdev in my xorg.conf which it doesn't seem to do ATM Thanks for confirming my suspicions as to what the problem is as I can probably puzzle it out from there. Of course I'll need to sort out the DRI lockups too but that's another thread! 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
xf86-video-intel-2.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I've compiled the latest kernel, 2.6.28-rc1 which is supposed to have GEM support and also installed xf86-video-intel-2.5.0. I use: - - xorg-server-1.5.2 - - mesa-7.2 - - libdrm-2.4 How can I tell if gem works? So far glxgears fpd dropped from ~950 (with driver 2.4.2) to ~530 with the latest drivers and I haven't seen any other improvements in 2d. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkB7IoACgkQDFMMPo7m60YLuQCff1yIXYfv14phXEzWj6s1zF39 tRgAn0gXck/nkO0viZ3duPHColjeFzZn =40Ql -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] candidate patches for server-1.5-branch inclusion
On Fri, Oct 24, 2008 at 5:57 PM, Rémi Cardona [EMAIL PROTECTED] wrote: Hi all, Here's a branch with all the patches that we currently plan on shipping in Gentoo. http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch) The first 37 patches are backports from git master, basically all the patches that touched exa/ since the branching for 1.5. Only a few got thrown out : - those that only touched shmPutImage() and friends - the patch that modifies the devPrivates With this branch, git diff --stat server-1.5-branch..master exa/ reports only 4 insertions and 2 deletions. It also includes a backport of a build fix, and another patch that fixes a build issue with KDrive's Xvesa with newer kernels. If accepted, this one should be applied to master as well. This branch builds and runs successfully (so far at least) and our test users can confirm all the improvements brought by the glyphs cache. Thanks for considering it. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I'd like to point the glyph cache isn't entirely bug free yet. https://bugs.freedesktop.org/show_bug.cgi?id=18065 Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
On Fri, 2008-10-24 at 10:55 +0100, Colin Guthrie wrote: Hi, I'm wondering if anyone can advice of how to address this lockup? I'm running mesa master from a couple days ago + a few minor patches (quite similar to the Fedora dev package) + xserver 1.5.2 + patches (very similar to the Fedora dev package - I also cherry picked the dix backtrace stuff too). I'm using intel 2.5.0. I'm getting the [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. error but I know that's somewhat misleading. As I have the backtrace cherry-picks from master the following was dumped into my log. [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f67798bbf46] 5: /etc/X11/X [0x484115] 6: /etc/X11/X [0x4671d7] 7: /lib64/libpthread.so.0 [0x7f677cf38d20] 8: /lib64/libpthread.so.0 [0x7f677cf37694] 9: /lib64/libpthread.so.0 [0x7f677cf32f34] 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f677cf32941] 11: /usr/lib64/libdrm_intel.so.1 [0x7f6779ed6664] 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) [0x7f6768dc9d1f] 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f6768dde202] 14: /usr/lib64/libdricore.so(_mesa_Flush+0x64) [0x7f67689e158c] 15: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c5a9b] 16: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c1e32] 17: /etc/X11/X(Dispatch+0x364) [0x447464] 18: /etc/X11/X(main+0x45d) [0x42d64d] 19: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f677b8d8316] 20: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] I don't have anything special in my kernel and I'm not using GEM. My h/w is i945GM. The above was with an older evdev, but (as it was mentioned, I upgraded to 2.0.99.2 and got the following (similar output): [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f48dc25d1a7] 5: /etc/X11/X [0x484115] 6: /etc/X11/X [0x4671d7] 7: /lib64/libpthread.so.0 [0x7f48df8dad20] 8: /lib64/libpthread.so.0 [0x7f48df8d9694] 9: /lib64/libpthread.so.0 [0x7f48df8d4f34] 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f48df8d4941] 11: /usr/lib64/libdrm_intel.so.1 [0x7f48dc878664] 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) [0x7f48cb76ad1f] 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f48cb77f202] 14: /usr/lib64/dri/i915_dri.so [0x7f48cb76c7ba] 15: /usr/lib64/dri/i915_dri.so(intelTexImage2D+0x7d) [0x7f48cb76d4f3] 16: /usr/lib64/libdricore.so(_mesa_TexImage2D+0x2a9) [0x7f48cb3fdc71] 17: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd36d933] 18: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd360a87] 19: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd35fa42] 20: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd363e32] 21: /etc/X11/X(Dispatch+0x364) [0x447464] 22: /etc/X11/X(main+0x45d) [0x42d64d] 23: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f48de27a316] 24: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] (evdev itself did odd things but that's another story!) Any ideas? So, it looks like somebody leaked the lock in libdrm, or we're attempting to double-lock it. The second seems unlikely since we batchbuffer_flush so regularly, but it's hard to say. Could you get a gdb backtrace? A lot of information is missing in server backtraces. Also, does whatever app you're running that causes this failure run in direct rendering mode? That may make it easier to get a decent backtrace. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] 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: xf86-video-intel-2.5.0
On Fri, 2008-10-24 at 18:40 +0300, Bogdan Burlacu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I've compiled the latest kernel, 2.6.28-rc1 which is supposed to have GEM support and also installed xf86-video-intel-2.5.0. I use: - - xorg-server-1.5.2 - - mesa-7.2 - - libdrm-2.4 How can I tell if gem works? So far glxgears fpd dropped from ~950 (with driver 2.4.2) to ~530 with the latest drivers and I haven't seen any other improvements in 2d. You need master or intel-2008-q3 branch of mesa. Mesa 7.2 shipped without GEM because it hadn't made it into the kernel yet. (Also, obglxgearsisnotabenchmark) -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] 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: Ansification of X.Org code other cleanup work
Peter Breitenlohner wrote: On Mon, 20 Oct 2008, Alan Coopersmith wrote: If someone wanted to organize a janitorial squad to tackle these and help new people work through them to get to the point where they were ready for commit access, we'd love you forever (or at least until you turn us down when we then volunteer you to be the next release manager). [2] 41 open bugs: http://bugs.freedesktop.org/buglist.cgi?keywords=janitorproduct=Xorgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED Hi Paulo, looking through that list, I noticed that your #15082 (app/xfs) has already addressed a problem (redefined) I also noticed recently. You also mention two other problems: I fully agree with the prototype and declaration BecomeDaemon (void). To Paulo and Alan, I'm not so sure about Paulos proposal to add a prototype for SnfSetFormat in xfs/os/config.c. I'd rather think that this function ought to be declared in one of the headers installed by libXfont. (Is there a policy decision?) I think I just followed some pattern elsewhere, but really, prototypes should be in header files, and the file actually defining the function should also include that header. To all, moreover, I think one should add if test x$GCC = xyes; then GCC_WARNINGS=-Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs -fno-strict-aliasing CFLAGS=$GCC_WARNINGS $CFLAGS fi to each and every configure.ac (if not already present) and address the problems uncovered this way. For ansification, you would also want at least -Wold-style-definition. I also used -Wbad-function-cast and -Wdeclaration-after-statement, but I think I only submited patches for code mixed with declarations, what I think is now supported by Xorg (I just dislike it :-), if one needs new variables, start a new block, otherwise pray all compilers will have the same semantics, i.e. variables have function scope or block scope, etc). To Paulo and Alan, there are additional problems with xfs: The xfs(1) manpage states (under -daemon) that the daemon will delete the pidfile upon exit: not true. In addition SetDaemonState in xfs/os/utils.c has code to produce an error message that another xfs process is already running. This never happens because StorePid always return either 0 or -1, and would be problematic because there may well be two daemons using different ports. Fact is, however, that when I try to start a second daemon on the same port, that process overwrites the original pidfile and then dies (probably because it can't create the socket). Not very nice. I don't remember all the details, but if you look at http://cvsweb.xfree86.org/cvsweb/xc/programs/xfs/ seven years ago I did several patches for xfs, to correct an exploit, but instead of just fixing the exploit, I made a program that would connect and feed /dev/urandom data as packets. I think I corrected like 50 buffer overruns just by doing that, until it stayed like one week properly handling the random data (and closing connection, etc). But most likely it did not check all combinations, and one could start adding random data after some initial valid data exchange have been done; this could also be done for the X Server, or any kind of server (and probably there should already exist some kind of generic stress test tool for this kind of test somewhere). regards Peter Breitenlohner [EMAIL PROTECTED] Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel-2.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: On Fri, 2008-10-24 at 18:40 +0300, Bogdan Burlacu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I've compiled the latest kernel, 2.6.28-rc1 which is supposed to have GEM support and also installed xf86-video-intel-2.5.0. I use: - - xorg-server-1.5.2 - - mesa-7.2 - - libdrm-2.4 How can I tell if gem works? So far glxgears fpd dropped from ~950 (with driver 2.4.2) to ~530 with the latest drivers and I haven't seen any other improvements in 2d. You need master or intel-2008-q3 branch of mesa. Mesa 7.2 shipped without GEM because it hadn't made it into the kernel yet. (Also, obglxgearsisnotabenchmark) Thanks, it's working now (relatively fine I should say), but with some problems: dmesg says: X:2152 conflicting memory types d000-e000 write-combining-uncached-minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:2152 conflicting memory types d000-e000 write-combining-uncached-minus reserve_memtype failed 0xd000-0xe000, track write-combining, req write-combining X:2240 freeing invalid memtype d000-e000 Also launching wine completely freezes X. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkCKN8ACgkQDFMMPo7m60Yz6QCeM1Tucvyd3wP/tSVdxBRuYt++ i5UAniGCA1f75yX6YEYy3ztneiau5vcd =AqRC -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Supporting pretty window destory effects in metacity-clutter
On Thu, 2008-10-23 at 19:14 +0100, Robert Bragg wrote: There is another case though where the application is forcefully closed and does not control the order in which windows are destroyed. If an app is killed then control moves to the server: In the server: CloseDownClient() ends up calling FreeClientResources() which involves deleting all the windows of that client. Notably they also seem to be deleted in no particular order, and that causes the same problem described above. I'm not sure offhand of the legality of the patch you gave in terms of the letter of the protocol, so I won't comment on that for now. Have you tried adding the client's windows to the wm's save set? That way they'll be preserved at connection close and you can destroy them yourself at your leisure (if I remember save set semantics correctly). - ajax 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: [PATCH] Supporting pretty window destory effects in metacity-clutter
On Fri, 2008-10-24 at 16:19 -0400, Adam Jackson wrote: On Thu, 2008-10-23 at 19:14 +0100, Robert Bragg wrote: There is another case though where the application is forcefully closed and does not control the order in which windows are destroyed. If an app is killed then control moves to the server: In the server: CloseDownClient() ends up calling FreeClientResources() which involves deleting all the windows of that client. Notably they also seem to be deleted in no particular order, and that causes the same problem described above. I'm not sure offhand of the legality of the patch you gave in terms of the letter of the protocol, so I won't comment on that for now. Have you tried adding the client's windows to the wm's save set? That way they'll be preserved at connection close and you can destroy them yourself at your leisure (if I remember save set semantics correctly). I don't think that will work sadly; as I understand it WM's use save sets so that they can safely reparent other client windows onto WM owned frames, such that, if the WM dies anything in the saveset will not get destroyed along with the WM but instead get reparented and mapped back on the root window. I don't think it gives a way to let clients control window cleanup for other client windows. There's another similar sounding mechanism; the close mode, which can be DestroyAll, RetainPermanent or RetainTemporary, but I think a client can only control its own close mode. kind regards, - Robert ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
On Fri, Oct 24, 2008 at 01:59:15PM -0400, Jan Engelhardt wrote: I know very well that CAB is the kill switch, but it just occurred to me that it triggered by accident nevertheless. I was editing around in a graphical editor, where word-based movement is done with Ctrl. Certain commands require Shift and Alt to be held down too, and removing words is done traditionally with Backspace. Don't ask how exactly, but in this twirl it _just happened_ that I triggered CAB by accident. The only thing I could do at the moment is silently curse my employer for not using openSUSE. I do save very often, but still, I had to reload all the programs like xterms, xmms, and so on. Simple conclusion, I want this patch in Xorg. http://cgit.freedesktop.org/xorg/xserver/commit/?id=9d135ac10a7374c7ccda705f1eeb02cc53076c34 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
