Re: AllowEmptyInput and HAL (SOLVED!!!)
Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). - xkbcomp, when called by the server, claims that xkbcomp errors are not fatal to the server. And only some of its messages appear in the X log file. I feel that this particular error should be considered fatal. And ideally, the consequence of an unrecognised keysym should not be the Any Key effect that I got. (Is the person responsible for xkbcomp reading this?). Thanks to those of you who helped with suggestions. Regards, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL (SOLVED!!!)
Phil Endecott wrote: Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). From the way you've described it, it sounds like you've uncovered a bug in an old version of libx11. If this is the case, then why does Debian need stronger versioned dependencies between the server and this lib? That's not a versioning issue after all, that's just a normal bug. The X server doesn't actually require the newer library version. - David Nusinow ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeon] Dual-Head, second display stays black
Am Tue, 28 Apr 2009 20:55:24 +0200 schrieb Andreas Juch x...@juch.cc: I tried to disable the working display and only use the blank one, but that doesn't turn on the blank monitor on, but uses the resolution of the blank monitor on the working monitor. When I swap the DVI cables, the other display works. The DVI-1 connector as the radeon-driver calls it doesn't work at all. It's initialized at Xorg startup (monitor LED turns from orange to green and the monitor displays No signal found), but stays blank. Really no idea about that? It would really be great if I could use both monitors. Best regards, Andreas Juch ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeon] Dual-Head, second display stays black
On Fri, May 8, 2009 at 2:43 PM, Andreas Juch x...@juch.cc wrote: Am Tue, 28 Apr 2009 20:55:24 +0200 schrieb Andreas Juch x...@juch.cc: I tried to disable the working display and only use the blank one, but that doesn't turn on the blank monitor on, but uses the resolution of the blank monitor on the working monitor. When I swap the DVI cables, the other display works. The DVI-1 connector as the radeon-driver calls it doesn't work at all. It's initialized at Xorg startup (monitor LED turns from orange to green and the monitor displays No signal found), but stays blank. Really no idea about that? It would really be great if I could use both monitors. Can you try with xf86-video-ati or from git master or the 6.12-branch stable branch? Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Fwd: intel driver: xorg does not give an error, but I do not see anything]
Dirk De Becker wrote: ... I am running a Gentoo system with X.Org server version 1.5.3 and xf86-video-intel version 2.6.3-r1. ... If I startx, I do not get any errors (anymore), but I do not see anything on my screen. I tried connecting a VGA display, a DVI display and even an LVDS display. ... Hi Dirk, Here are some ideas to try. 1) Confirm X server is still running. [r...@rockover ~]# ps -ef | fgrep Xorg root 14552 14551 0 Apr08 tty1 02:11:17 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-lS2QB0/database -nolisten tcp vt1 Display name is :0 File storing authorization key is /var/run/gdm/auth-for-gdm-lS2QB0/database Virtual terminal number 1 (vt1) (You Xorg log reports virtual terminal 7). 2) Ask the X Server anything. (Get the XAUTHORITY environment variable and display name from output from the previous step). [r...@rockover ~]# XAUTHORITY=/var/run/gdm/auth-for-gdm-lS2QB0/database xdpyinfo -display :0 | less name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10503000 X.Org version: 1.5.3 ... 3) On the console keyboard switch to the correct Linux virtual console with [Ctrl]-[Atl]-[F7] for your virtual terminal 7. Try F1 to F8 too, just in case. 4) Try temporally removing the configuration file /etc/X11/xorg.conf, starting the X Server again and repeating the previous steps. XOrg X Servers have an in built configuration which should work. 5) Try starting X specifying the client command to run: startx xterm References: man startx man xdpyinfo man xauth Hope this helps, Mike ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeon] Dual-Head, second display stays black
Am Fri, 8 May 2009 14:59:41 -0400 schrieb Alex Deucher alexdeuc...@gmail.com: On Fri, May 8, 2009 at 2:43 PM, Andreas Juch x...@juch.cc wrote: Am Tue, 28 Apr 2009 20:55:24 +0200 schrieb Andreas Juch x...@juch.cc: I tried to disable the working display and only use the blank one, but that doesn't turn on the blank monitor on, but uses the resolution of the blank monitor on the working monitor. When I swap the DVI cables, the other display works. The DVI-1 connector as the radeon-driver calls it doesn't work at all. It's initialized at Xorg startup (monitor LED turns from orange to green and the monitor displays No signal found), but stays blank. Really no idea about that? It would really be great if I could use both monitors. Can you try with xf86-video-ati or from git master or the 6.12-branch stable branch? I'm currently running the current git master. Andreas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: R6xx/R7xx 3D programming guide
Most excellent news! Thanks hugely to all of you at AMD who have contributed to this release. Bart In message a728f9f90905071636j7ba6bc4cj958c4c1727c84...@mail.gmail.com you wrote: AMD is pleased to announce the release of a 3D programming guide for Radeon 6xx/7xx chips. The previously released shader ISAs and register reference guides are available from the links below. The guide will be available in the usual places: http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf and http://ati.amd.com/developer/open_gpu_documentation.html If you have any development related questions please ask at gpudriverdevsupp...@amd.com Enjoy! Alex Deucher AMD GPG alexander.deuc...@amd.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL (SOLVED!!!)
On Fri, May 8, 2009 at 10:46 AM, Phil Endecott spam_from_x...@chezphil.org wrote: Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? It's because xkbcomp links with libX11.so, not the server. However, if you built xkbcomp and Xlib from jhbuild, it should pick up the new Xlib during the xkbcomp build. And libtool usually adds a rpath if it detects one of the libraries is outside of the standard linker path. You'd have to inspect what jhbuild is doing if that's not the case. What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). - xkbcomp, when called by the server, claims that xkbcomp errors are not fatal to the server. And only some of its messages appear in the X log file. I feel that this particular error should be considered fatal. And ideally, the consequence of an unrecognised keysym should not be the Any Key effect that I got. (Is the person responsible for xkbcomp reading this?). No one is really responsible for xkbcomp currently. The entire interaction with xkbcomp by the server is a complete eye sore. I've been working to make this go away, but it took a lot of surgery and hasn't been reviewed yet. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Edit xcursor
2009/5/7 David Harel harel...@gmail.com: Greetings, I am trying to change slightly a cursor theme (just change the base color) I find myself completely puzzled. I can't even view X cursor images. Please help. maybe check out the gursormaker gui frontend. http://gursormaker.sourceforge.net/ The underlying xcursorgen command line tool is likely in one of your distro/os's packages. In debian, x11-apps ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xorg-server 1.6.1.901
This is the the first 1.6.2 pre-release. Please nominate additional patches at http://wiki.x.org/wiki/Server16Branch Ander Conselvan de Oliveira (1): xfree86: Remove device from inputInfo.devices if ActivateDevice failed. Eamon Walsh (3): security: Revert behavior of extension access for compatibility. security: Fix a crash caused by wrong ordering of format arguments. security: Grant untrusted windows remove access on all windows. Ian Romanick (1): DRI2: Send the version the code actually supports Jesse Barnes (1): Don't prepare outputs crtcs if set_mode_major is present Julien Cristau (3): Add XI 1.5 event and requests to protocol.txt Add RandR 1.3 requests to protocol.txt Bug#21324: Add quirk for Iiyama Vision Master 450 Keith Packard (1): xserver 1.6.1.901 Michel Dänzer (2): EXA: Handle separate alpha maps properly in Composite fallback, take two. EXA: Guard empty pending region warning by DEBUG_MIGRATE. Peter Hutterer (1): dix: ignore non-pointer events in XineramaCheckMotion (#20557) Pierre Ossman (2): Xi: don't send XKB mapping notifications when XKB is disabled dix: fix calculation of number of fake KeyRelease events Tormod Volden (1): xfree86: edid quirk for Philips LCD LP154W01-TLAJ git tag: xorg-server-1.6.1.901 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.6.1.901.tar.bz2 MD5: e6cba1f07006143daa95ce3f11d999b2 xorg-server-1.6.1.901.tar.bz2 SHA1: 0818a63225e9b2262d33099eb6630d15c07f04b6 xorg-server-1.6.1.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.6.1.901.tar.gz MD5: 8288d33fd184ec27abd770d7bebf1000 xorg-server-1.6.1.901.tar.gz SHA1: 868de272ce3dd3fe96a01b5e9f68a33725ca4b3e xorg-server-1.6.1.901.tar.gz -- keith.pack...@intel.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
