xorg-server-1.8 MultiBufferDrawableResType
mbuf.c: In function 'MultibufferExtensionInit': mbuf.c:442: warning: old-style function definition mbuf.c:471: error: 'MultiBufferDrawableResType' undeclared (first use in this function) mbuf.c:471: error: (Each undeclared identifier is reported only once mbuf.c:471: error: for each function it appears in.) -- Klaus ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
keyboard autorepeat gone
Today I compiled and installed the current state of development X.org. (no cvs, all of xorg.freedesktop.org/releases/individual) The few bugs I noticed so far .. Nothing that has to do with lbx compiled, is Low Bandwidth X obsolete now? xorg-server-1.6.99.900 + xf86-video-ati-6.12.4 mbuf.c:45:39: error: X11/extensions/multibufst.h: No such file or directory (xextproto-7.1.1 was installed) The last version of xextproto which included multibufst.h was xextproto-7.0.5. I believe to remember some header files changed names, so this should be easy to fix. Not using --enable-multibuffer helped as a start. The X-server is up and running fine but keyboard autorepeat does not work any more. (xf86-input-keyboard-1.3.99.1 ?) Any hints ? Hope this helped. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: keyboard autorepeat gone + loader error extensions
Klaus Dittrich schrieb: Today I compiled and installed the current state of development X.org. (no cvs, all of xorg.freedesktop.org/releases/individual) The few bugs I noticed so far .. Nothing that has to do with lbx compiled, is Low Bandwidth X obsolete now? xorg-server-1.6.99.900 + xf86-video-ati-6.12.4 mbuf.c:45:39: error: X11/extensions/multibufst.h: No such file or directory (xextproto-7.1.1 was installed) The last version of xextproto which included multibufst.h was xextproto-7.0.5. I believe to remember some header files changed names, so this should be easy to fix. Not using --enable-multibuffer helped as a start. The X-server is up and running fine but keyboard autorepeat does not work any more. (xf86-input-keyboard-1.3.99.1 ?) Any hints ? Hope this helped. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg xset r rate 500 30 failed with Xlib: extension XFree86-Misc missing on display :0.0 This lets me have a look at Xorg.0.log. Here I noticed all libs in /usr/X11/lib/xorg/modules/extensions/ were not found. Example dlopen: /usr/X11/lib/xorg/modules//extensionslibextmod.so: cannot open shared object file: No such file or directory Seems a / gets lost in a string concatenation. Changing ModulePath in xorg.conf does not help Xorg.log .. ModulePath set to /usr/X11/lib/xorg/modules/,/usr/X11/lib/xorg/modules/extensions/ .. dlopen: /usr/X11/lib/xorg/modules//extensionslibextmod.so: cannot open shared object file: No such file or directory (EE) Failed to load /usr/X11/lib/xorg/modules//extensionslibextmod.so (II) UnloadModule: extmod (EE) Failed to load module extmod (loader failed, 7) -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xextproto 7.0.99.1
Peter Hutterer schrieb: Many headers included in xextproto were combined library, server and protocol headers. This release splits those headers up and moves the client-side library headers into the libXext module. Clients should not be affected by this change. Drivers that included headers from this module will need to be fixed. Adam Jackson (1): Remove most LBX headers. James Cloos (1): C sucks: define XEventClass in terms of unsigned int, not CARD32. Peter Hutterer (17): MITMisc: remove MITMisc.h library header, split into mitmistproto.h XEVI: remove XEVI.h library header, split into EVIproto.h XLbx: remove XLbx library headers, split into lbx.h, lbxproto.h XShm: remove XShm.h library header, split into shm.h, shmproto.h XTest: remove XTest.h, split into xtest.h and xtestproto.h Xag: remove Xag.h library header, split into Xagconst.h Xcup: remove XCup.h library header, split into cup.h Xdbe: remove Xdbe.h library header, split into dbe.h Remove Xext.h and Xge.h - pure library headers. dpms: remove dpms.h library header, split into dpmsconst.h remove extutil.h, pure library header multibuf: remove multibuf.h, split into multibufconst.h security: remove security.h, split into secur.h shape: remove shape.h, split into shapeconst.h sync: remove sync.h library header, split into syncconst.h xtestext1: split xtestext1.h header into xtestext1proto.h Bump to 7.0.99.1 git tag: xextproto-7.0.99.1 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.99.1.tar.bz2 MD5: 8439d47c486b7dbd85e4071d6c8408ca xextproto-7.0.99.1.tar.bz2 SHA1: 58a2bc95e548a8d79ce96e6dc866c28464dcf125 xextproto-7.0.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.99.1.tar.gz MD5: 9915827151b19817c879167e77cb43d2 xextproto-7.0.99.1.tar.gz SHA1: ac6de9eb42103e4cd60cbe6523c62b09c43f2551 xextproto-7.0.99.1.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg XTest.c:38:37: error: X11/extensions/xteststr.h: No such file or directory Here xteststr.h gets not installed by xextproto-7.0.99.1. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ctrl+alt+backspace stopped working with xorg-server 1.6.1.901
Audio Phile schrieb: Hello, I'm using Arch Linux and my xorg-server recently got upgraded to 1.6.1.901. At the same time, the ctrl+alt+backspace to restart gdm stopped working. I am aware that I need to have added the DontZap false option in my /etc/X11/xorg.conf to enable this key combo some times ago, but even with this modification in /etc/X11/xorg.conf, the ctrl+alt+backspace does nothing ever since the upgrade. I posted my /etc/X11/xorg.conf below if it helps trouble shoot. Advice is appreachiated. Section ServerFlags Option DontZap false EndSection Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/misc FontPath /usr/share/fonts/100dpi:unscaled FontPath /usr/share/fonts/75dpi:unscaled FontPath /usr/share/fonts/TTF FontPath /usr/share/fonts/Type1 EndSection Section Module #Load record # Load dri2 Load dbe Load extmod Load type1 Load freetype Load glx EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse OptionProtocol auto OptionDevice /dev/input/mice OptionZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Samsung ModelNameSyncMaster T220 Option DPI 96x96 EndSection Section Device Identifier Card0 Driver nvidia VendorName nVidia Corporation BoardName GeForce 8400 GS BusID PCI:1:0:0 EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 SubSection Display Viewport 0 0 Depth 1 EndSubSection SubSection Display Viewport 0 0 Depth 4 EndSubSection SubSection Display Viewport 0 0 Depth 8 EndSubSection SubSection Display Viewport 0 0 Depth 15 EndSubSection SubSection Display Viewport 0 0 Depth 16 EndSubSection SubSection Display Viewport 0 0 OptionAddARGBGLXVisuals True Depth 24 EndSubSection EndSection ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Verified it, you are right. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ctrl+alt+backspace stopped working with xorg-server 1.6.1.901
Paul B. Mahol schrieb: On 5/31/09, Audio Phile da_audioph...@yahoo.com wrote: Hello, I'm using Arch Linux and my xorg-server recently got upgraded to 1.6.1.901. At the same time, the ctrl+alt+backspace to restart gdm stopped working. I am aware that I need to have added the DontZap false option in my /etc/X11/xorg.conf to enable this key combo some times ago, but even with this modification in /etc/X11/xorg.conf, the ctrl+alt+backspace does nothing ever since the upgrade. I posted my /etc/X11/xorg.conf below if it helps trouble shoot. Advice is appreachiated. You have xkeyboard-config 1.6 installed? Yes. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel: 2.7.99.1 snapshot (now with 10% reduced fat!)
Carl Worth schrieb: This is a development snapshot very early in the process toward developing 2.8. There have been some big changes to the code, and we're anxious to get feedback on these changes as early as possible. Here is a summary of the biggest changes: * Driver now depends on X server 1.6 or later * Eliminate XAA and EXA support (in favor of UXA) * Eliminate DRI1 support * Fixes for running without DRI at all These code removals represent a deletion of a substantial amount of code, (and hopefully piles of bugs), as well as reduce the maintenance effort going forward as the number of combinatorial configurations for the driver are greatly reduced. This means that users are much more likely to be running code that has actually been tested, and it will be much easy for developers to replicate bugs that users experience. Many thanks to Eric Anholt for gutting so much code! And see Keith Packard's writeup describing the benefits of this code removal: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ One of the things that would be most useful in testing this release is to revisit any outstanding bugs that you have previously reported. If the buggy behavior is gone, (or the bug is no longer relevant---such as a bug that's specific to XAA only), please feel free to indicate so in bugzilla or even just close the bug. If you confirm that the bug is still present, please indicate so in the bug report. (I was going to ask that you select a 1.7.99 version, but it looks like bugzilla only has versions for products not compoenents, while we use a xorg product and a driver/intel component.) We definitely want to make any such confirmed bugs a priority, so it would be nice to have a consistent mechanism to search for these bugs. Suggestions are welcome on the best approach. Thanks in advance for any testing or feedback on this snapshot. -Carl Getting the snapshot git tag: 2.7.99.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.bz2 MD5: ec222b8e617f79c3dee03db71db053a2 xf86-video-intel-2.7.99.1.tar.bz2 SHA1: c8c88d341dd79c4561018c5a279c8f6e66f84089 xf86-video-intel-2.7.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.gz MD5: 797eaa5d8abdabd92bdc261ca1b53634 xf86-video-intel-2.7.99.1.tar.gz SHA1: 5ee985ed22e483ac470cceaa65866a871370b747 xf86-video-intel-2.7.99.1.tar.gz All commits since 2.7.0 --- [Note that many of these commits were already cherry-picked and present in 2.7.0] Alan Coopersmith (1): Fix UXA to build with Sun compilers (use __func__ instead of __FUNCTION__) Albert Damen (2): Non-GEM allocations incorrectly force TILE_NONE (bug 20797) Fix crash with XV with large virtual display Carl Worth (18): Revert the rest of the EXA_VERSION_MAJOR bump Use WAIT_FOR_SCAN_LINE instead of WAIT_FOR_VBLANK Remove support for 'auto'(-1) value of XV_SYNC_TO_VBLANK Fix new video sync-to-blank code for multi-head Don't clip video to CRTC in the case of textured video Add a RELEASING file documenting the release process README: Remove almost all time-sensitive information Add a new AUTHORS file Clarify that the default acceleration is UXA if KMS is available. Add a NEWS files with release-notes for 2.7.0 Add AUTHORS and NEWS to EXTRA_DIST NEWS: Add note about broken PAT code in some kernels RELEASING: Update instructions to reflect some minor process improvements AUTHORS: Add Robert Lowery to the authors file README: Fix typos in chipset list, and point to how_to_report_bug web page RELEASING: Note that --with-xserver-source is needed for make distcheck Increment version to 2.7.99.1 NEWS: Add notes for 2.7.99.1 snapshot Dan Nicholson (1): Fix dist of xvmc sources Eric Anholt (35): Fix XV with non-GEM kernels by allocating a larger fake bufmgr. Add PGETBL_CTL to the debug output. Add dumping of 915 and 945 fence registers. Add DCC register dumping. Move contributed m4 (dolt) to a subdirectory so we can include it with others. Add shave support, enabled by default. Remove some dead i830.h struct members. Rename EXA rendering functions to UXA, since we're keeping them post-EXA. Remove dead mono cursor load code. Remove unused i830_output_type_names Use a static inline to replace if (0) to an unused stub function. Staticize a bunch of functions and variables in the driver. Replace a bunch of #ifdef debug flushing/syncing with a single function. Remove dead monitor detect debugger. Remove dead xoffset/yoffset from pre-randr. Revert fix overflow warning on videoRam Don't try to do anything for I830Sync when VT switched. Fix
Re: [ANNOUNCE] xf86-video-intel 2.7.0
Jin, Gordon schrieb: Klaus Dittrich wrote on Friday, April 24, 2009 2:50 AM: After installing this driver a switch to a vt-terminal (ctrl-alt F2 for example) does not work. No vt-termial / login was available any more nor a return (ctrl-alt F7) to a graphical desktop. I had to use ssh from of another machine to recover of this situation. The last driver not showing this behavior is xf86-video-intel-2.6.99.902, any later (newer) version failed. After installing xf86-video-intel-2.6.99.902 and restarting X switching to vt-termials works without rebooting. Xserver was xorg-server-1.6.1, kernel 2.6.30-rc3 64bit. Are you using EXA or UXA? Could you check log to make sure DRI enabled? Gordon DRI was enabled, no accelaration choosen by xorg.conf, swrast got called. Meanwhile I got xf86-video-intel-2.7.0 and kernel 2.6.30-rc3 to work as expected regarding graphics, switching to a vt still works only half. ctrl-alt-F2 changes the background color of some parts of the screen but the graphical contents stayed, I could not see a black screen and a login prompt. But I was able to login blind and to recover to the graphics screen by ctrl-alt-F7. Another point: I use startx and later on stopping X by ctrl-alt-bs results in a monitor signaling me that there is no video-signal and no video-signal reappeared when I tried switching to a vt. So without the second machine and a running sshd I would have been forced to reebot. xorg.conf Section Device Identifier Intel-4-Series-Chipset-Integrated-Graphics-Controller-rev03 Driver intel BusID PCI:0:2:0 Option DRI true Option TilingNo Option AccelMethod UXA EndSection UXA, DRI2 works, glxinfo showed about 1500 fps, no tearing when moving windows with content, all very fast for my feeling. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci::00:02.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) intel(0): Output VGA1 using monitor section LG (II) intel(0): Output DVI1 has no monitor section (II) intel(0): Output DVI2 has no monitor section (II) intel(0): Output VGA1 connected (II) intel(0): Output DVI1 disconnected (II) intel(0): Output DVI2 connected (II) intel(0): Using user preference for initial modes (II) intel(0): Output VGA1 using initial mode 1280x1024 (II) intel(0): Output DVI2 using initial mode 1280x1024 (==) intel(0): video overlay key set to 0x101fe Only one monitor is connected via a dvi-cable. The log shows two, is that correct or may it be the vt appears at a not connected display? (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64 .0 kHz) (II) AIGLX: Suspending AIGLX clients for VT switch (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) AIGLX: Resuming AIGLX clients after VT switch (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x-0x: DRI memory manager (0 kB) (II) intel(0): 0x:end of aperture (II) intel(0): BO memory allocation layout: (II) intel(0): 0x:start of memory manager (II) intel(0): 0x0253-0x02a2: front buffer (5120 kB) (II) intel(0): 0x0252-0x02529fff: HW cursors (40 kB) (II) intel(0): 0x:end of memory manager (II) Mouse0: ps2EnableDataReporting: succeeded -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.0
Florian Mickler schrieb: On Sun, 26 Apr 2009 14:32:09 +0200 Klaus Dittrich kla...@arcor.de wrote: Jin, Gordon schrieb: Klaus Dittrich wrote on Friday, April 24, 2009 2:50 AM: After installing this driver a switch to a vt-terminal (ctrl-alt F2 for example) does not work. No vt-termial / login was available any more nor a return (ctrl-alt F7) to a graphical desktop. I had to use ssh from of another machine to recover of this situation. The last driver not showing this behavior is xf86-video-intel-2.6.99.902, any later (newer) version failed. After installing xf86-video-intel-2.6.99.902 and restarting X switching to vt-termials works without rebooting. Xserver was xorg-server-1.6.1, kernel 2.6.30-rc3 64bit. Are you using EXA or UXA? Could you check log to make sure DRI enabled? Gordon DRI was enabled, no accelaration choosen by xorg.conf, swrast got called. Meanwhile I got xf86-video-intel-2.7.0 and kernel 2.6.30-rc3 to work as expected regarding graphics, switching to a vt still works only half. ctrl-alt-F2 changes the background color of some parts of the screen but the graphical contents stayed, I could not see a black screen and a login prompt. But I was able to login blind and to recover to the graphics screen by ctrl-alt-F7. Another point: I use startx and later on stopping X by ctrl-alt-bs results in a monitor signaling me that there is no video-signal and no video-signal reappeared when I tried switching to a vt. So without the second machine and a running sshd I would have been forced to reebot. xorg.conf Section Device Identifier Intel-4-Series-Chipset-Integrated-Graphics-Controller-rev03 Driver intel BusID PCI:0:2:0 Option DRI true Option TilingNo Option AccelMethod UXA EndSection UXA, DRI2 works, glxinfo showed about 1500 fps, no tearing when moving windows with content, all very fast for my feeling. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci::00:02.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) intel(0): Output VGA1 using monitor section LG (II) intel(0): Output DVI1 has no monitor section (II) intel(0): Output DVI2 has no monitor section (II) intel(0): Output VGA1 connected (II) intel(0): Output DVI1 disconnected (II) intel(0): Output DVI2 connected (II) intel(0): Using user preference for initial modes (II) intel(0): Output VGA1 using initial mode 1280x1024 (II) intel(0): Output DVI2 using initial mode 1280x1024 (==) intel(0): video overlay key set to 0x101fe Only one monitor is connected via a dvi-cable. The log shows two, is that correct or may it be the vt appears at a not connected display? (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64 .0 kHz) (II) AIGLX: Suspending AIGLX clients for VT switch (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) AIGLX: Resuming AIGLX clients after VT switch (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x-0x: DRI memory manager (0 kB) (II) intel(0): 0x:end of aperture (II) intel(0): BO memory allocation layout: (II) intel(0): 0x:start of memory manager (II) intel(0): 0x0253-0x02a2: front buffer (5120 kB) (II) intel(0): 0x0252-0x02529fff: HW cursors (40 kB) (II) intel(0): 0x:end of memory manager (II) Mouse0: ps2EnableDataReporting: succeeded Assuming you are using kernel-mode-setting: Do you have CONFIG_FB=y in your kernel .config? Without FB-Console, there is nothing to switch to, as kernel-mode-setting dosn't use text-mode anymore . Sincerely, Flo Good point, I did not know that. FB was on. Looking at the config variables I detected I had had set FRAMEBUFFER_CONSOLE_DETECT_PRIMARY. After switching it off I could switch from graphical desktop to a VT, I could switch between VT's but now not back to the graphics desktop by ctrl-alt-F7. Black screen. The only graphics device available is the G45 chip. Here my settings regarding FB. CONFIG_FB=y CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_VESA=y CONFIG_FB_INTEL=m CONFIG_FB_INTEL_DEBUG=y CONFIG_FB_INTEL_I2C=y -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org
Re: [ANNOUNCE] xf86-video-intel 2.7.0
Carl Worth schrieb: We are pleased to announce a major 2.7.0 release of xf86-video-intel (after three previous 2.6.99.90x release candidates). Compared to the 2.6 series, 2.7.0 has a large number of bug fixes, (see the list below), but also a few significant features, such as: SDVO-TV support, available on ADD2 card (bug#9992) and D945GCLF2 board (bug#17776). Basic SDVO-LVDS support XV video display without tearing [Though this isn't working for all users yet, see https://bugs.freedesktop.org/show_bug.cgi?id=21076 ] Various fixes for UXA, DRI2, and Kernel modesetting. We encourage users to use kernel modesetting and UXA acceleration with this release, which should give the best performance and robustness. When KMS is available, UXA is the default acceleration used by the driver, (EXA is the default otherwise). -Carl Where to get the release git tag: 2.7.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.0.tar.bz2 MD5: 5832172ac69b9a066a202e1578a5d3c8 xf86-video-intel-2.7.0.tar.bz2 SHA1: 6d55b11ccf92ddc0763329f6e503e1a55b9beacc xf86-video-intel-2.7.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.0.tar.gz MD5: 5f1336fa79ecf93989d45f0fc2ebbe59 xf86-video-intel-2.7.0.tar.gz SHA1: 754c3684a635b5178fe642075aff4ab2c903cee8 xf86-video-intel-2.7.0.tar.gz A significant known issue - Some Linux kernel versions (such as 2.6.29) are known to have broken PAT code that causes recent versions of this driver to fail, (which can manifest as the X server simply not starting). This can be verified by adding the nopat option to the kernel command-line and seeing the failure go away. We hope that newer kernels in the 2.6.29.x as well as 2.6.30 and above will have working PAT code. Summary of changes since the last release candidate (2.6.99.903) Carl Worth (10): Add a RELEASING file documenting the release process README: Remove almost all time-sensitive information Add a new AUTHORS file Clarify that the default acceleration is UXA if KMS is available. Add a NEWS files with release-notes for 2.7.0 Add AUTHORS and NEWS to EXTRA_DIST Update version to 2.7.0 NEWS: Add note about broken PAT code in some kernels RELEASING: Update instructions to reflect some minor process improvements README: Fix typos in chipset list, and point to how_to_report_bug web page Li Peng (1): Turn on front buffer tiling in KMS. Ma Ling (3): set broadcast RGB mode for HDMI and TMDS from SDVOX output set broadcast RGB mode for integrated HDMI output. update manpage for BROADCAST_RGB property Some of the most notable bugs fixed in 2.7.0 [GM45 965GM] bad htotal causes panel startup failure https://bugs.freedesktop.org/show_bug.cgi?id=17292 [xrandr TV] need TV output property control https://bugs.freedesktop.org/show_bug.cgi?id=12763 [TV] xrandr --set TV_FORMAT gets BadMatch error https://bugs.freedesktop.org/show_bug.cgi?id=16566 [945 tiling] Low performance due to no A17 workaround https://bugs.freedesktop.org/show_bug.cgi?id=16835 [TV]Flicker when launching applications in the 2.4-branch https://bugs.freedesktop.org/show_bug.cgi?id=17405 [945GM FBC] FBC causes underruns flicker https://bugs.freedesktop.org/show_bug.cgi?id=18651 [xv] Textured video suffers from tearing https://bugs.freedesktop.org/show_bug.cgi?id=19635 [G45] Random hangs with UXA https://bugs.freedesktop.org/show_bug.cgi?id=19734 [945GM] Any 3D app is slow in resolution higher than 800x600 with UXA+DRI2, due to tiling https://bugs.freedesktop.org/show_bug.cgi?id=19738 [i915 UXA,EXA] rotation messes display with tiling on https://bugs.freedesktop.org/show_bug.cgi?id=20265 [G45] DRI2/UXA gives solid white instead of transparency https://bugs.freedesktop.org/show_bug.cgi?id=20321 LVDS output not detected https://bugs.freedesktop.org/show_bug.cgi?id=20517 xf86-video-intel-2.6.3: Xv crashes X server https://bugs.freedesktop.org/show_bug.cgi?id=20525 [G965 non-GEM] systray in KDE 4 completely broken https://bugs.freedesktop.org/show_bug.cgi?id=20527 [SDVO-TV]the desktop is teared in four sections on the screen https://bugs.freedesktop.org/show_bug.cgi?id=20550 Intel video driver 2.6.3 crashes with XVideo https://bugs.freedesktop.org/show_bug.cgi?id=20563 [855GM] Xv crash with non-KMS
Re: [ANNOUNCE] xf86-video-radeonhd 1.2.5 Release
Matthias Hopf schrieb: Announcing the 1.2.5 Release of the xf86-video-radeonhd driver. RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets. The development is driven by Novell and AMD at the time of writing, together with a community of open source developers around this driver. AMD provides free documentation for the chipsets. Note the wiki on http://wiki.x.org/wiki/radeonhd Version 1.2.5 improvements: - Added 2D acceleration for R6xx and R7xx. - Added XVideo support for R6xx and R7xx. - Added support for RS880 and RV790. - Added RandR 1.3 mandatory properties. - Refactoring of MC code. - Enable DRI support by default on R5xx and RS6xx. - LUT (color lookup table) fixes. - Tons of quirk table entries and bug fixes. - Fix register accesses for processors that reorder memory writes. http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.5.tar.gz MD5: 0d024ace7aac324f79a9f516aaba68a0 xf86-video-radeonhd-1.2.5.tar.gz SHA1: 5bc97e7b9ed24669466c6bdebcf7062cd790c8f3 xf86-video-radeonhd-1.2.5.tar.gz http://xorg.freedesktop.org/releases/individual/driver/xf86-video-radeonhd-1.2.5.tar.bz2 MD5: 10669b08101cb6d69894cc44b47e5094 xf86-video-radeonhd-1.2.5.tar.bz2 SHA1: 64fc0eb5209adba5479396bafe53b50ded6c0940 xf86-video-radeonhd-1.2.5.tar.bz2 Matthias ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Just tried it out .. .. (II) RADEONHD(0): Calling DAC_LoadDetection (II) RADEONHD(0): DAC_LoadDetection Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling SetPixelClock (II) RADEONHD(0): SetPixelClock Successful (II) RADEONHD(0): Calling SetPixelClock (II) RADEONHD(0): SetPixelClock Successful (II) RADEONHD(0): Query for Restore Registers: failed Chip is a RV610. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Nix wrote: On 1 Dec 2008, David Miller verbalised: A default that, btw, anti-socially totally ignores what people put into their xorg.conf file unless they add yet another knob. That's worse than a default change. What's worse yet is that hal is the single most unstable daemon I have *ever* run on any system I administer. My logs show that for more than half the time over the last two years it has refused to start: it coredumped on startup for a long time, for reasons that changed two or three times as I tracked the development HAL in hopes of it getting fixed, then started working, then some change in 2.6.27 made it freeze on startup: this now seems to be fixed in the stable tree, but, still, robust software this is not. I didn't care enough to track any of these problems down myself because on my fixed-hardware desktop HAL is basically a waste of memory: the hardware doesn't change and I know what I've got. I checked enough to make sure there was a bug reported, then moved on. So I was... somewhat annoyed to discover that when upgrading to xserver 1.5.3 I had to add 'AllowEmptyInput false', particularly given that the option name gives you no clue whatsoever as to why on earth this would make the keyboard reappear, and even the git logs give no rationale. I still have no idea why anyone would consider this behaviour desirable, particularly if you're loading kbd but are not loading evdev. IMHO, if the daemon isn't running at all, AllowEmptyInput should be unnecessary, and kbd/mouse should be consulted if loaded, *whether or not* the server was compiled with HAL support. Anything else is just too prone to failure. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I actually run Xserver-1.5.2 and for my needs it works very well. A try of Xserver-1.5.3 without HAL ended up with a totally unusable system. No screen, no keyboard, no ability to switch back to a text console. Last resort was the reset-button. Same Xserver-1.5.3, this time with HAL and d-bus. Surprise, X11 came up, the keyboard worked, but after a view minutes the system became sluggish. A view into /var/log/messages showed lots of block errors of my system disk and a short time later the system became totally unusable. Again the reset button. The disk is and was 100% ok! Any hints how to prevent HAL from damaging scsi/sata io are welcome. Having had these experiences I think X should not only not rely on HAL, it should never rely on HAL, meaning HAL should be an option. And in its current state, this option should be marked as highly experimental. I would suggest an additional mode of HALD in which it can be started in an non-daemon mode with an filename as argument. In this file HAL should then write what X11 input/output devices it believes to have discovered, best in a notation directly usable for insertion in xorg.conf, and then exit. This way HAL can be developed further without being annoying to users with fixed desktops and/or small systems and xorg.conf stays usable for a reliable configuration. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
