Re: libpciaccess
Hi WH Yes, i was missing -lpciaccesss parameter in the configure option though lib path was there. When i did pkg-config --cflags --libs libpciaccess i find out that missing part. Now xorg has been installed, but startx is not working, i will post it separately. Many thanks for you suggestion/time Dwdy On 10/22/11, walter harms wha...@bfs.de wrote: undefined reference to means there is an object file or library missing in the final stage of linking. re, wh Am 22.10.2011 16:13, schrieb Dwijadas Dey: Hi list Able to solve the problem ( http://lists.freedesktop.org/archives/xorg/2011-October/053700.html )related to drmsetserverinfo , the problem was in xorg compilation where i set the location of LIBDRM_CFLAGS and LIBS to an old version of libdrm (2.0.4), correcting these LIBDRM_CFLAGS and LIBDRM_LIBS location solves the problem. Now i am trying to recompile xorg with libpciaccess but at the last stage of make command I got the errors which are given below. * ./.libs/libxorg.a(xf86Helper.o): In function `xf86MatchPciInstances': xf86Helper.c:(.text+0x3583): undefined reference to `pci_slot_match_iterator_create' xf86Helper.c:(.text+0x3597): undefined reference to `pci_device_next' xf86Helper.c:(.text+0x35ab): undefined reference to `pci_iterator_destroy' xf86Helper.c:(.text+0x35ce): undefined reference to `pci_slot_match_iterator_create' xf86Helper.c:(.text+0x3805): undefined reference to `pci_device_next' xf86Helper.c:(.text+0x381d): undefined reference to `pci_iterator_destroy' ./.libs/libxorg.a(xf86Init.o): In function `probe_devices_from_device_sections': xf86Init.c:(.text+0x693): undefined reference to `pci_id_match_iterator_create' xf86Init.c:(.text+0x74c): undefined reference to `pci_device_next' xf86Init.c:(.text+0x764): undefined reference to `pci_iterator_destroy' ./.libs/libxorg.a(xf86Init.o): In function `add_matching_devices_to_configure_list': xf86Init.c:(.text+0xaae): undefined reference to `pci_id_match_iterator_create' xf86Init.c:(.text+0xc64): undefined reference to `pci_device_next' xf86Init.c:(.text+0xc7c): undefined reference to `pci_iterator_destroy' ./.libs/libxorg.a(xf86Configure.o): In function `bus_pci_newdev_configure': xf86Configure.c:(.text+0x169): undefined reference to `pci_device_get_vendor_name' xf86Configure.c:(.text+0x177): undefined reference to `pci_device_get_device_name' ./.libs/libxorg.a(xf86pciBus.o): In function `xf86PciProbe': xf86pciBus.c:(.text+0xae): undefined reference to `pci_slot_match_iterator_create' xf86pciBus.c:(.text+0x147): undefined reference to `pci_device_probe' xf86pciBus.c:(.text+0x15f): undefined reference to `pci_device_next' xf86pciBus.c:(.text+0x1cd): undefined reference to `pci_device_cfg_read_u16' xf86pciBus.c:(.text+0x29d): undefined reference to `pci_device_get_vendor_name' xf86pciBus.c:(.text+0x2ab): undefined reference to `pci_device_get_device_name' ./.libs/libxorg.a(xf86AutoConfig.o): In function `listPossibleVideoDrivers': xf86AutoConfig.c:(.text+0xf66): undefined reference to `pci_slot_match_iterator_create' xf86AutoConfig.c:(.text+0xf85): undefined reference to `pci_device_next' xf86AutoConfig.c:(.text+0xf99): undefined reference to `pci_iterator_destroy' ./.libs/libxorg.a(linuxPci.o): In function `get_parent_bridge': linuxPci.c:(.text+0x410): undefined reference to `pci_id_match_iterator_create' linuxPci.c:(.text+0x43e): undefined reference to `pci_device_get_bridge_info' linuxPci.c:(.text+0x464): undefined reference to `pci_device_next' linuxPci.c:(.text+0x478): undefined reference to `pci_iterator_destroy' ./.libs/libxorg.a(Pci.o): In function `xf86scanpci': ** I checked pciaccess.h where each of these definitions are there and it is included in the include path. I want to know from the list, is it a bug related to libpciaccess(0.10.9) ? Thanks Dwdy ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: wha...@bfs.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Mon, 24 Oct 2011, Peter Hutterer wrote: On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Hi Peter, Thanks, that put me on the right track. I just had to create /etc/hal/fdi/policy/90-intellipen-pro.fdi with the contents ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device !-- Intellipen Pro -- match key=usb_device.vendor_id int=0x188c match key=usb_device.product_id int=0x221 merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo and /etc/modprobe.d/intellipen.conf with options usbhid quirks=0x188c:0x0221:0x0040 and the device works perfectly. Where should I submit this information so that it gets incorporated to future updates so that others can just plug it in and have it work automatically? Thanks, Tamas ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] libpciaccess: close mtrr fd on pci_cleanup
While possibly safe in practice, this doesn't look like the correct fix. It is possible that this will result in a close(0) if HAVE_MTRR is defined and mtrr_fd was just never set. HAVE_MTRR is defined if asm/mtrr.h exists. mtrr_fd is set if HAVE_MTRR is defined and linux_sysfs is used. Probably a trivial example of this would be to sudo touch /usr/include/asm/mtrr.h on FreeBSD. On Oct 21, 2011, at 11:49, Nithin Nayak Sujir wrote: Since the fd is not closed, calling pci_system_init and pci_system_cleanup more than 1024 times results in too many files open error. Signed-off-by: Nithin Nayak Sujir nsu...@broadcom.com --- src/common_init.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/common_init.c b/src/common_init.c index 5e91c27..d7ade3f 100644 --- a/src/common_init.c +++ b/src/common_init.c @@ -31,7 +31,9 @@ #include stdlib.h #include errno.h +#include unistd.h +#include config.h #include pciaccess.h #include pciaccess_private.h @@ -122,6 +124,10 @@ pci_system_cleanup( void ) (*pci_sys-methods-destroy)(); } +#ifdef HAVE_MTRR +if (pci_sys-mtrr_fd != -1) + close(pci_sys-mtrr_fd); +#endif free( pci_sys ); pci_sys = NULL; } -- 1.7.1 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jerem...@freedesktop.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
xf86-video-intel-2.14.0 compilation error
Hi I have compiled and installed xorg-server-1.7.99.2 and now i am trying to compile xf86-video-intel-2.14.0 on centos 5.7 [kernel 2.6.39] using the following configure command [root@localhost xf86-video-intel-2.14.0]# ./configure DRM_CFLAGS=-I/opt/libdrm/include -I/opt/libdrm/include/libdrm DRM_LIBS=-L/opt/libdrm -ldrm DRI_CFLAGS=-I/usr/local/mesa-7.10.3/include DRI_LIBS=-L/usr/lib/dri PCIACCESS_CFLAGS=-I/usr/local/pciaccess/include PCIACCESS_LIBS=-L/usr/local/pciaccess/lib -lpciaccess --prefix=/usr/local/xf86-video-intel/ XORG_CFLAGS=-I/opt/xorg/include/xorg -I/usr/local/pciaccess/include -I/usr/local/pixman/include/pixman-1 XORG_LIBS=-L/opt/xorg/lib -L/usr/local/pciaccess/lib -L/usr/local/pixman/lib -lpixman-1 -lpciaccess but compilation of very 1st file gives me an error like * Making all in uxa make[2]: Entering directory `/root/Downloads/xf86-video-intel-2.14.0/uxa' CC uxa.lo In file included from /opt/xorg/include/xorg/dix.h:55, from /opt/xorg/include/xorg/scrnintstr.h:58, from /opt/xorg/include/xorg/xf86str.h:39, from /opt/xorg/include/xorg/xf86.h:46, from uxa-priv.h:37, from uxa.c:37: /opt/xorg/include/xorg/geext.h:40: error: expected ‘)’ before ‘*’ token /opt/xorg/include/xorg/geext.h:41: warning: no semicolon at end of struct or union /opt/xorg/include/xorg/geext.h:77: error: expected ‘)’ before ‘*’ token /opt/xorg/include/xorg/geext.h:79: error: expected ‘)’ before ‘*’ token In file included from uxa.c:37: uxa-priv.h:273: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Bool’ make[2]: *** [uxa.lo] Error 1 make[2]: Leaving directory `/root/Downloads/xf86-video-intel-2.14.0/uxa' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/Downloads/xf86-video-intel-2.14.0' make: *** [all] Error 2 ** I think this error is not related to any non inclusion of .h file or undefined variable, I want to know from the list whether i have to change any parameters in makefile or in compiler options ? Dwdy ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] libpciaccess: close mtrr fd on pci_cleanup
The module which opens the fd should be the same module that closes it. Letting that cross between the common/specific boundary seems problematic. I'd prefer to see a new hook added for implementation-specific cleanup, and the close() live in linux_sysfs.c itself. That will allow for better abstraction down the road as other implementations might want to do something similar. On Oct 24, 2011, at 10:18, Nithin Sujir wrote: On 10/24/2011 09:51 AM, Jeremy Huddleston wrote: While possibly safe in practice, this doesn't look like the correct fix. It is possible that this will result in a close(0) if HAVE_MTRR is defined and mtrr_fd was just never set. HAVE_MTRR is defined ifasm/mtrr.h exists. mtrr_fd is set if HAVE_MTRR is defined and linux_sysfs is used. Probably a trivial example of this would be to sudo touch /usr/include/asm/mtrr.h on FreeBSD. That is a valid point. I don't have a freebsd system to test it but based on code review I agree that what you say will happen. Would you suggest adding an #ifdef linux around the close or since the pci_sys structure is allocated with a calloc either directly or indirectly, I can change the condition to check for 0. Thanks, Nithin. On Oct 21, 2011, at 11:49, Nithin Nayak Sujir wrote: Since the fd is not closed, calling pci_system_init and pci_system_cleanup more than 1024 times results in too many files open error. Signed-off-by: Nithin Nayak Sujirnsu...@broadcom.com --- src/common_init.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/common_init.c b/src/common_init.c index 5e91c27..d7ade3f 100644 --- a/src/common_init.c +++ b/src/common_init.c @@ -31,7 +31,9 @@ #includestdlib.h #includeerrno.h +#includeunistd.h +#include config.h #include pciaccess.h #include pciaccess_private.h @@ -122,6 +124,10 @@ pci_system_cleanup( void ) (*pci_sys-methods-destroy)(); } +#ifdef HAVE_MTRR +if (pci_sys-mtrr_fd != -1) + close(pci_sys-mtrr_fd); +#endif free( pci_sys ); pci_sys = NULL; } -- 1.7.1 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jerem...@freedesktop.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Monitor doesn't display anything. EDID trouble ?
Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [21.829] (II) RADEON(0): Monitor name: HP ZR30w [21.829] (II) RADEON(0): Serial No: CN4048041Z [21.829] (II) RADEON(0): EDID (in hex): [21.829] (II) RADEON(0):000022f06e2801010101 [21.829] (II) RADEON(0):3014010380402878ea8d85ad4f35b125 [21.829] (II) RADEON(0):0e50540001010101010101010101 [21.829] (II) RADEON(0):010101010101e26800a0a0402e603020 [21.829] (II) RADEON(0):36008190211abc1b00a050201730 [21.829] (II) RADEON(0):302036008190211a00fc0048 [21.829] (II) RADEON(0):50205a523330770a2020202000ff [21.829] (II) RADEON(0):00434e343034383034315a0a20200066 [21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? Thanks a lot, Xav dmesg | grep drm [0.998537] [drm] Initialized drm 1.1.0 20060810 [1.009248] [drm] radeon kernel modesetting enabled. [1.009276] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [1.009877] [drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8 0x1682:0x2994). [1.009914] [drm] register mmio base: 0xFE7C [1.009915] [drm] register mmio size: 131072 [1.010062] [drm] Detected VRAM RAM=1024M, BAR=256M [1.010064] [drm] RAM width 128bits DDR [1.010128] [drm] radeon: 1024M of VRAM memory ready [1.010130] [drm] radeon: 512M of GTT memory ready. [1.010139] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.010140] [drm] Driver supports precise vblank timestamp query. [1.010189] [drm] radeon: irq initialized. [1.010192] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.010720] [drm] Loading JUNIPER Microcode [1.034007] [drm] ring test succeeded in 1 usecs [1.034086] [drm] radeon: ib pool ready. [1.034146] [drm] ib test succeeded in 0 usecs [1.034517] [drm] Radeon Display Connectors [1.034518] [drm] Connector 0: [1.034519] [drm] DisplayPort [1.034520] [drm] HPD4 [1.034521] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [1.034523] [drm] Encoders: [1.034524] [drm] DFP1: INTERNAL_UNIPHY2 [1.034525] [drm] Connector 1: [1.034526] [drm] DVI-I [1.034527] [drm] HPD1 [1.034528] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [1.034529] [drm] Encoders: [1.034530] [drm] DFP2: INTERNAL_UNIPHY1 [1.034531] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [1.034533] [drm] Connector 2: [1.034533] [drm] DVI-I [1.034534] [drm] HPD6 [1.034536] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [1.034537] [drm] Encoders: [1.034538] [drm] DFP3: INTERNAL_UNIPHY [1.034539] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [1.512032] [drm] Radeon display connector DP-1: No monitor connected or invalid EDID [1.563505] [drm] Radeon display connector DVI-I-1: Found valid EDID [1.573120] [drm] Radeon display connector DVI-I-2: No monitor connected or invalid EDID [1.573135] [drm] Internal thermal controller with fan control [1.573174] [drm] radeon: power management initialized [1.665202] [drm] fb mappable at 0xD0141000 [1.665203] [drm] vram apper at 0xD000 [1.665204] [drm] size 16384000 [1.665205] [drm] fb depth is 24 [1.665206] [drm]pitch is 10240 [1.665288] fbcon: radeondrmfb (fb0) is primary device [2.124952] fb0: radeondrmfb frame buffer device [2.124954] drm: registered panic notifier [2.124962] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 on minor 0 Xorg.0.log: [20.636] X.Org X Server 1.11.1.901 (1.11.2 RC 1) Release Date: 2011-10-14 [20.636] X Protocol Version 11, Revision 0 [20.636] Build Operating System: Linux 3.1.0-rc4-amd64 x86_64 Debian [20.636] Current Operating System: Linux bip 3.1.0-rc7-amd64 #1 SMP Mon Sep 26 13:09:27 UTC 2011 x86_64 [20.636] Kernel command line:
Re: Monitor doesn't display anything. EDID trouble ?
On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [ 21.829] (II) RADEON(0): Monitor name: HP ZR30w [ 21.829] (II) RADEON(0): Serial No: CN4048041Z [ 21.829] (II) RADEON(0): EDID (in hex): [ 21.829] (II) RADEON(0): 000022f06e2801010101 [ 21.829] (II) RADEON(0): 3014010380402878ea8d85ad4f35b125 [ 21.829] (II) RADEON(0): 0e50540001010101010101010101 [ 21.829] (II) RADEON(0): 010101010101e26800a0a0402e603020 [ 21.829] (II) RADEON(0): 36008190211abc1b00a050201730 [ 21.829] (II) RADEON(0): 302036008190211a00fc0048 [ 21.829] (II) RADEON(0): 50205a523330770a2020202000ff [ 21.829] (II) RADEON(0): 00434e343034383034315a0a20200066 [ 21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [ 21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [ 21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [ 21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? The EDID looks ok to me. Do any other modes work? Try 1280x800. Try the other DVI port. If the neither port lights up the monitor (especially if the bios produces no display), it's probably a bad monitor. Alex Thanks a lot, Xav dmesg | grep drm [ 0.998537] [drm] Initialized drm 1.1.0 20060810 [ 1.009248] [drm] radeon kernel modesetting enabled. [ 1.009276] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 1.009877] [drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8 0x1682:0x2994). [ 1.009914] [drm] register mmio base: 0xFE7C [ 1.009915] [drm] register mmio size: 131072 [ 1.010062] [drm] Detected VRAM RAM=1024M, BAR=256M [ 1.010064] [drm] RAM width 128bits DDR [ 1.010128] [drm] radeon: 1024M of VRAM memory ready [ 1.010130] [drm] radeon: 512M of GTT memory ready. [ 1.010139] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.010140] [drm] Driver supports precise vblank timestamp query. [ 1.010189] [drm] radeon: irq initialized. [ 1.010192] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 1.010720] [drm] Loading JUNIPER Microcode [ 1.034007] [drm] ring test succeeded in 1 usecs [ 1.034086] [drm] radeon: ib pool ready. [ 1.034146] [drm] ib test succeeded in 0 usecs [ 1.034517] [drm] Radeon Display Connectors [ 1.034518] [drm] Connector 0: [ 1.034519] [drm] DisplayPort [ 1.034520] [drm] HPD4 [ 1.034521] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 1.034523] [drm] Encoders: [ 1.034524] [drm] DFP1: INTERNAL_UNIPHY2 [ 1.034525] [drm] Connector 1: [ 1.034526] [drm] DVI-I [ 1.034527] [drm] HPD1 [ 1.034528] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 1.034529] [drm] Encoders: [ 1.034530] [drm] DFP2: INTERNAL_UNIPHY1 [ 1.034531] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [ 1.034533] [drm] Connector 2: [ 1.034533] [drm] DVI-I [ 1.034534] [drm] HPD6 [ 1.034536] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 1.034537] [drm] Encoders: [ 1.034538] [drm] DFP3: INTERNAL_UNIPHY [ 1.034539] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 1.512032] [drm] Radeon display connector DP-1: No monitor connected or invalid EDID [ 1.563505] [drm] Radeon display connector DVI-I-1: Found valid EDID [ 1.573120] [drm] Radeon display connector DVI-I-2: No monitor connected or invalid EDID [ 1.573135] [drm] Internal thermal controller with fan control [ 1.573174] [drm] radeon: power management initialized [ 1.665202] [drm] fb mappable at 0xD0141000 [ 1.665203] [drm] vram apper at 0xD000 [ 1.665204] [drm] size 16384000 [ 1.665205] [drm] fb depth is 24 [ 1.665206] [drm] pitch is 10240 [ 1.665288] fbcon: radeondrmfb (fb0) is primary device [ 2.124952] fb0: radeondrmfb frame buffer device [ 2.124954] drm: registered panic notifier [ 2.124962] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 on minor 0
Re: Monitor doesn't display anything. EDID trouble ?
On Mon, Oct 24, 2011 at 4:49 PM, Xavier Bestel xavier.bes...@free.fr wrote: Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [ 21.829] (II) RADEON(0): Monitor name: HP ZR30w [ 21.829] (II) RADEON(0): Serial No: CN4048041Z [ 21.829] (II) RADEON(0): EDID (in hex): [ 21.829] (II) RADEON(0): 000022f06e2801010101 [ 21.829] (II) RADEON(0): 3014010380402878ea8d85ad4f35b125 [ 21.829] (II) RADEON(0): 0e50540001010101010101010101 [ 21.829] (II) RADEON(0): 010101010101e26800a0a0402e603020 [ 21.829] (II) RADEON(0): 36008190211abc1b00a050201730 [ 21.829] (II) RADEON(0): 302036008190211a00fc0048 [ 21.829] (II) RADEON(0): 50205a523330770a2020202000ff [ 21.829] (II) RADEON(0): 00434e343034383034315a0a20200066 [ 21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [ 21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [ 21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [ 21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? The EDID looks ok to me. Do any other modes work? Try 1280x800. Try the other DVI port. If the neither port lights up the monitor (especially if the bios produces no display), it's probably a bad monitor. OK, thanks to you I've found the problems: 1) this monitor is apparently unable to display anything but 1280x800 or 2560x1600, so no BIOS nor GRUB for me. You should still get a BIOS image. The vbios takes the preferred mode from the monitor's EDID and uses the scaler to fake the legacy modes. It's probably trying to use 2560x1600 mode which requires a dual link cable. Alex 2) my cable is single-link, so Xorg's default guess doesn't work. After hooking a second monitor, and choosing 1280x800 for the big one, everything's working (sort-of). I'll hunt for a dual-link or displayport cable, whichever is cheapest. Can Xorg/radeon detect that the DVI cable is single-link ? Thanks, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Monitor doesn't display anything. EDID trouble ?
Le lundi 24 octobre 2011 à 16:53 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 4:49 PM, Xavier Bestel xavier.bes...@free.fr wrote: Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [21.829] (II) RADEON(0): Monitor name: HP ZR30w [21.829] (II) RADEON(0): Serial No: CN4048041Z [21.829] (II) RADEON(0): EDID (in hex): [21.829] (II) RADEON(0):000022f06e2801010101 [21.829] (II) RADEON(0):3014010380402878ea8d85ad4f35b125 [21.829] (II) RADEON(0):0e50540001010101010101010101 [21.829] (II) RADEON(0):010101010101e26800a0a0402e603020 [21.829] (II) RADEON(0):36008190211abc1b00a050201730 [21.829] (II) RADEON(0):302036008190211a00fc0048 [21.829] (II) RADEON(0):50205a523330770a2020202000ff [21.829] (II) RADEON(0):00434e343034383034315a0a20200066 [21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? The EDID looks ok to me. Do any other modes work? Try 1280x800. Try the other DVI port. If the neither port lights up the monitor (especially if the bios produces no display), it's probably a bad monitor. OK, thanks to you I've found the problems: 1) this monitor is apparently unable to display anything but 1280x800 or 2560x1600, so no BIOS nor GRUB for me. You should still get a BIOS image. The vbios takes the preferred mode from the monitor's EDID and uses the scaler to fake the legacy modes. It's probably trying to use 2560x1600 mode which requires a dual link cable. OK, I'll see that with the good cable. Thanks Alex, Xav ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Monitor doesn't display anything. EDID trouble ?
On Mon, Oct 24, 2011 at 5:03 PM, Xavier Bestel xavier.bes...@free.fr wrote: Le lundi 24 octobre 2011 à 15:16 -0400, Alex Deucher a écrit : On Mon, Oct 24, 2011 at 3:01 PM, Xavier Bestel xavier.bes...@free.fr wrote: Hi, I know it may be off-topic, but the experience is there. I've just bought a used 30 monitor (HP ZR30w), and it doesn't display anything, even at BIOS time. The backlight is on, but I see nothing except a faint flickering at mode change times. Screen blanking works (the backlight switches off). I'm using a Radeon HD 5700 via DVI, debian/sid with kernel 3.1.0-rc7, Xorg 2:1.11.1.901-2 and radeon 1:6.14.2-2. After googling a bit, some people talk about a possible EDID problem (apparently it's possible to have the EDID somehow erased from the EEPROM ?). But Xorg.0.log does seem indicate that there's an EDID: [ 21.829] (II) RADEON(0): Monitor name: HP ZR30w [ 21.829] (II) RADEON(0): Serial No: CN4048041Z [ 21.829] (II) RADEON(0): EDID (in hex): [ 21.829] (II) RADEON(0): 000022f06e2801010101 [ 21.829] (II) RADEON(0): 3014010380402878ea8d85ad4f35b125 [ 21.829] (II) RADEON(0): 0e50540001010101010101010101 [ 21.829] (II) RADEON(0): 010101010101e26800a0a0402e603020 [ 21.829] (II) RADEON(0): 36008190211abc1b00a050201730 [ 21.829] (II) RADEON(0): 302036008190211a00fc0048 [ 21.829] (II) RADEON(0): 50205a523330770a2020202000ff [ 21.829] (II) RADEON(0): 00434e343034383034315a0a20200066 [ 21.829] (II) RADEON(0): Printing probed modes for output DVI-0 [ 21.829] (II) RADEON(0): Modeline 2560x1600x60.0 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync (98.7 kHz) [ 21.829] (II) RADEON(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync (49.3 kHz) ... and then: [ 21.854] (II) RADEON(0): Output DVI-0 using initial mode 2560x1600 Does anyone have an idea how I could pinpoint the problem ? The EDID looks ok to me. Do any other modes work? Try 1280x800. Try the other DVI port. If the neither port lights up the monitor (especially if the bios produces no display), it's probably a bad monitor. OK, thanks to you I've found the problem 1) this monitor is apparently unable to display anything but 1280x800 or 2560x1600, so no BIOS nor GRUB for me. 2) my cable is single-link, so Xorg's default guess doesn't work. After hooking a second monitor, and choosing 1280x800 for the big one, everything's working (sort-of). I'll hunt for a dual-link or displayport cable, whichever is cheapest. Can Xorg detect if the cable is single-link ? No. Alex ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Mon, Oct 24, 2011 at 01:59:50PM +0200, Tamas Papp wrote: On Mon, 24 Oct 2011, Peter Hutterer wrote: On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Hi Peter, Thanks, that put me on the right track. I just had to create /etc/hal/fdi/policy/90-intellipen-pro.fdi with the contents ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device !-- Intellipen Pro -- match key=usb_device.vendor_id int=0x188c match key=usb_device.product_id int=0x221 merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo and /etc/modprobe.d/intellipen.conf with options usbhid quirks=0x188c:0x0221:0x0040 and the device works perfectly. Where should I submit this information so that it gets incorporated to future updates so that others can just plug it in and have it work automatically? kernel bugzilla. I'd be easy enough to knock up a kernel patch that adds the quirk for this particular device, so if you can find the time to do that you're most likely to see the change happen. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xf86-video-intel-2.14.0 compilation error
On Mon, 2011-10-24 at 22:23 +0530, Dwijadas Dey wrote: Hi I have compiled and installed xorg-server-1.7.99.2 and now i am trying to compile xf86-video-intel-2.14.0 on centos 5.7 [kernel 2.6.39] using the following configure command Most of time what you have in system should be good enough. So why you want update centos 5.7 ? and what versions of x and intel-drv have 5.7? but if you want upgrade and do it right, you have to pack xorg-server-1.7.99.2 as rpm and replace the original that you have in system, you may grab a xorg-server.src.rpm and recompile for your system with rpmbuild --rebuild . compile xf86-video-intel-2.14.0 with /usr/local/x, is not a good idea. and why 1.7.99.2 , this is a release candidate ? Dwdy ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: ser...@serjux.com -- Sérgio M. B. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] libpciaccess: close mtrr fd on pci_cleanup
On 10/24/2011 09:51 AM, Jeremy Huddleston wrote: While possibly safe in practice, this doesn't look like the correct fix. It is possible that this will result in a close(0) if HAVE_MTRR is defined and mtrr_fd was just never set. HAVE_MTRR is defined ifasm/mtrr.h exists. mtrr_fd is set if HAVE_MTRR is defined and linux_sysfs is used. Probably a trivial example of this would be to sudo touch /usr/include/asm/mtrr.h on FreeBSD. That is a valid point. I don't have a freebsd system to test it but based on code review I agree that what you say will happen. Would you suggest adding an #ifdef linux around the close or since the pci_sys structure is allocated with a calloc either directly or indirectly, I can change the condition to check for 0. Thanks, Nithin. On Oct 21, 2011, at 11:49, Nithin Nayak Sujir wrote: Since the fd is not closed, calling pci_system_init and pci_system_cleanup more than 1024 times results in too many files open error. Signed-off-by: Nithin Nayak Sujirnsu...@broadcom.com --- src/common_init.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/common_init.c b/src/common_init.c index 5e91c27..d7ade3f 100644 --- a/src/common_init.c +++ b/src/common_init.c @@ -31,7 +31,9 @@ #includestdlib.h #includeerrno.h +#includeunistd.h +#include config.h #include pciaccess.h #include pciaccess_private.h @@ -122,6 +124,10 @@ pci_system_cleanup( void ) (*pci_sys-methods-destroy)(); } +#ifdef HAVE_MTRR +if (pci_sys-mtrr_fd != -1) + close(pci_sys-mtrr_fd); +#endif free( pci_sys ); pci_sys = NULL; } -- 1.7.1 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jerem...@freedesktop.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] libpciaccess: close mtrr fd on pci_cleanup
On 10/24/2011 10:49 AM, Jeremy Huddleston wrote: The module which opens the fd should be the same module that closes it. Letting that cross between the common/specific boundary seems problematic. I'd prefer to see a new hook added for implementation-specific cleanup, and the close() live in linux_sysfs.c itself. That will allow for better abstraction down the road as other implementations might want to do something similar. Sounds good. I'll send another patch shortly. Thanks, Nithin. On Oct 24, 2011, at 10:18, Nithin Sujir wrote: On 10/24/2011 09:51 AM, Jeremy Huddleston wrote: While possibly safe in practice, this doesn't look like the correct fix. It is possible that this will result in a close(0) if HAVE_MTRR is defined and mtrr_fd was just never set. HAVE_MTRR is defined ifasm/mtrr.h exists. mtrr_fd is set if HAVE_MTRR is defined and linux_sysfs is used. Probably a trivial example of this would be to sudo touch /usr/include/asm/mtrr.h on FreeBSD. That is a valid point. I don't have a freebsd system to test it but based on code review I agree that what you say will happen. Would you suggest adding an #ifdef linux around the close or since the pci_sys structure is allocated with a calloc either directly or indirectly, I can change the condition to check for 0. Thanks, Nithin. On Oct 21, 2011, at 11:49, Nithin Nayak Sujir wrote: Since the fd is not closed, calling pci_system_init and pci_system_cleanup more than 1024 times results in too many files open error. Signed-off-by: Nithin Nayak Sujirnsu...@broadcom.com --- src/common_init.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/common_init.c b/src/common_init.c index 5e91c27..d7ade3f 100644 --- a/src/common_init.c +++ b/src/common_init.c @@ -31,7 +31,9 @@ #includestdlib.h #includeerrno.h +#includeunistd.h +#include config.h #include pciaccess.h #include pciaccess_private.h @@ -122,6 +124,10 @@ pci_system_cleanup( void ) (*pci_sys-methods-destroy)(); } +#ifdef HAVE_MTRR +if (pci_sys-mtrr_fd != -1) + close(pci_sys-mtrr_fd); +#endif free( pci_sys ); pci_sys = NULL; } -- 1.7.1 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jerem...@freedesktop.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[v2 PATCH] libpciaccess: close mtrr fd on pci_cleanup
Since the fd is not closed, calling pci_system_init and
pci_system_cleanup more than 1024 times results in too many files open
error.
v2: Modified the patch to use the destroy hook function instead of
calling close in the common code based on Jeremy Huddleston's comments. It
seemed appropriate to use the destroy hook since other implementations are
doing clean ups here.
Signed-off-by: Nithin Nayak Sujir nsu...@broadcom.com
---
src/linux_sysfs.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
index d5ba66a..09e7138 100644
--- a/src/linux_sysfs.c
+++ b/src/linux_sysfs.c
@@ -889,8 +889,18 @@ pci_device_linux_sysfs_unmap_legacy(struct pci_device
*dev, void *addr, pciaddr_
return munmap(addr, size);
}
+
+static void
+pci_system_linux_destroy(void)
+{
+#ifdef HAVE_MTRR
+ if (pci_sys-mtrr_fd 0)
+ close(pci_sys-mtrr_fd);
+#endif
+}
+
static const struct pci_system_methods linux_sysfs_methods = {
-.destroy = NULL,
+.destroy = pci_system_linux_destroy,
.destroy_device = NULL,
.read_rom = pci_device_linux_sysfs_read_rom,
.probe = pci_device_linux_sysfs_probe,
--
1.7.1
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
