Re: [Mesa3d-dev] DRI SDK and modularized drivers.
Nicolai Haehnle escribió: > because we want to > have the DRM in our codebase Why? -- __ | , , | | / \ | | ((__-^^-,-^^-__))Octavio Rossell Tabet | | `-_---' `---_-' octa...@gnu.org.ve | | `--|o` 'o|--' http://octavio.gnu.org.ve | | \ ` / irc.radiognu.org #gnu | | .: :. | | :o_o: Huella: FC69 551B ECB9 62B0 D992| |"-" BE57 B551 2497 C78B 870A| |__| <>___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolai Haehnle wrote: > On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote: >> So, identify the volatile interfaces, and the more stable interfaces, >> and then isolate the volatile ones, and then you come to only one >> conclusion. > > Except that the Mesa core <-> classic driver interface also wants to > change from time to time in non-trivial ways, and trying to force a > separation there on people who don't want an additional set of > compatibility issues to deal with is not exactly a friendly move. I've been busy trying to get a release out the door, so I haven't looked at these patches yet. I won't have a chance to look at the patches until at least late next week. I also wasn't at FOSDEM, so I don't have any of the background info. If these patches try to enforce a "stable" interface between core Mesa and the classic DRI drivers, we're not interested. At all. This has been discussed and rejected many, many times before. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkujw1sACgkQX1gOwKyEAw/iSgCaA37aTDav/amZkxuxq89d+hJm P1MAn0dy99VSRTivgUURnCR3klnH/PSt =DrqD -END PGP SIGNATURE- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
RE: [Mesa3d-dev] DRI SDK and modularized drivers.
Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call. I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach. If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ? -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Nicolai Haehnle Sent: Friday, March 19, 2010 1:26 PM To: Luc Verhaegen Cc: dri-de...@lists.sourceforge.net; mesa3d-...@lists.sourceforge.net; xorg@lists.freedesktop.org Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers. On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote: > So, identify the volatile interfaces, and the more stable interfaces, > and then isolate the volatile ones, and then you come to only one > conclusion. Except that the Mesa core <-> classic driver interface also wants to change from time to time in non-trivial ways, and trying to force a separation there on people who don't want an additional set of compatibility issues to deal with is not exactly a friendly move. It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas. In particular, the Mesa core <-> classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel installations trivial. The (only?) issues with that in X.org are that: 1) there is a cultural aversion due to the bad experience with the horrible pre-modularization setup, and 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. cu, Nicolai ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote: > So, identify the volatile interfaces, and the more stable interfaces, > and then isolate the volatile ones, and then you come to only one > conclusion. Except that the Mesa core <-> classic driver interface also wants to change from time to time in non-trivial ways, and trying to force a separation there on people who don't want an additional set of compatibility issues to deal with is not exactly a friendly move. It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas. In particular, the Mesa core <-> classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel installations trivial. The (only?) issues with that in X.org are that: 1) there is a cultural aversion due to the bad experience with the horrible pre-modularization setup, and 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. cu, Nicolai ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Missing symbol error when building X.org from git
On Fri, Mar 19, 2010 at 8:17 AM, Joel Feiner wrote: > On Fri, Mar 19, 2010 at 10:05 AM, Dan Nicholson wrote: >> >> On Thu, Mar 18, 2010 at 9:12 PM, Joel Feiner wrote: >> > On Thu, Mar 18, 2010 at 4:58 PM, Dan Nicholson >> > wrote: >> >> >> >> On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner >> >> wrote: >> >> > On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson >> >> > wrote: >> >> >> >> >> >> On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner >> >> >> wrote: >> >> >> > The error that comes up is this: >> >> >> > libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall >> >> >> > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes >> >> >> > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing >> >> >> > -Wbad-function-cast -Wformat=2 -Wold-style-definition >> >> >> > -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN >> >> >> > -DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1 >> >> >> > -I/usr/include/freetype2 -I../../include -I../../include >> >> >> > -I../../Xext >> >> >> > -I../../composite -I../../damageext -I../../xfixes -I../../Xi >> >> >> > -I../../mi >> >> >> > -I../../miext/shadow -I../../miext/damage -I../../render >> >> >> > -I../../randr >> >> >> > -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod >> >> >> > -I/home//xbuild/out/include/libdrm -I/usr/include/freetype2 >> >> >> > -O2 >> >> >> > -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic >> >> >> > -o >> >> >> > Xdmx >> >> >> > dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o >> >> >> > dmxfont.o >> >> >> > dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o >> >> >> > dmxpixmap.o >> >> >> > dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o >> >> >> > dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o >> >> >> > -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a >> >> >> > ../../mi/.libs/libmi.a >> >> >> > ../../render/.libs/librender.a ../../Xi/.libs/libXi.a >> >> >> > ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a >> >> >> > ../../miext/shadow/.libs/libshadow.a >> >> >> > ../../miext/damage/.libs/libdamage.a >> >> >> > ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a >> >> >> > ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a >> >> >> > /usr/lib64/libhal.so >> >> >> > /usr/lib64/libdbus-1.so ../../os/.libs/libos.a >> >> >> > /usr/lib64/libgcrypt.so >> >> >> > -L/usr/lib64 /usr/lib64/libgpg-error.so >> >> >> > ../../xfixes/.libs/libxfixes.a >> >> >> > glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a >> >> >> > /home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so >> >> >> > /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so >> >> >> > /home//xbuild/out/lib64/libXfixes.so >> >> >> > /home//xbuild/out/lib64/libXi.so >> >> >> > /home//xbuild/out/lib64/libXext.so >> >> >> > /home//xbuild/out/lib64/libX11.so >> >> >> > /home//xbuild/out/lib64/libxcb.so >> >> >> > /usr/lib64/libXdmcp.so -ldl >> >> >> > /home//xbuild/out/lib64/libXfont.so >> >> >> > /usr/lib64/libfreetype.so >> >> >> > /home//xbuild/out/lib64/libfontenc.so >> >> >> > -lz >> >> >> > /home//xbuild/out/lib64/libXau.so >> >> >> > /home//xbuild/out/lib64/libpixman-1.so >> >> >> > /home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath >> >> >> > -Wl,/home//xbuild/out/lib64 -Wl,-rpath >> >> >> > -Wl,/home//xbuild/out/lib64 >> >> >> > >> >> >> > /home//xbuild/out/lib64/libXi.so: undefined reference to >> >> >> > `XESetWireToEventCookie' >> >> >> > >> >> >> > /home//xbuild/out/lib64/libXi.so: undefined reference to >> >> >> > `XESetCopyEventCookie' >> >> >> > What appears to be happening, I think, is that it is getting >> >> >> > libraries >> >> >> > like >> >> >> > libXrender and so on from /usr/lib64 instead of my build >> >> >> > directory. >> >> >> > I'm >> >> >> > not >> >> >> > sure why libtool is doing this. I have my PKG_CONFIG_PATH set to >> >> >> > my >> >> >> > local >> >> >> > build package config path (/home//xbuild/out/lib64/pkgconfig) >> >> >> > and >> >> >> > LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part). >> >> >> > I >> >> >> > had >> >> >> > also >> >> >> > built the whole get up without using LD_LIBRARY_PATH. Same >> >> >> > results. >> >> >> > The >> >> >> > only two modules that have this problem are pixman and xserver. >> >> >> > Pixman >> >> >> > I >> >> >> > worked around by passing --disable-gtk to ./configure, since that >> >> >> > was >> >> >> > the >> >> >> > part of the build that was failing. For xserver, it appears to be >> >> >> > dmx >> >> >> > that's failing. >> >> >> >> >> >> If I had to guess, the /usr/lib64 is getting hardcoded into one of >> >> >> the >> >> >> .la libtool archives installed in /home. Can you do "grep /usr/lib64 >> >> >> /home//xbuild/out/lib64/*.la"? Maybe there's a problem with >> >> >> module >> >> >> ordering in xorg.modules. Not sure if that's what's causing the >>
Re: mouse leaves screen
Jan Hackel wrote: > I have a X setup to use two screens side by side: the first is my laptop's > panel (1440x900) the second is a LCD (1280x1024). I run xorg-server 1.6.5 on > a > Gentoo Linux with KDE on top. > > Everything is working perfectly except for one inconvenience. The mouse > pointer will leave the screen on the bottom of the 1440x900 panel. I suppose > it happens because the height of the screen is less then the height of the > LCD. Preventing that is a enhancement that's been requested by several people, but not implemented: https://bugs.freedesktop.org/show_bug.cgi?id=20334 As far as X is concerned, your desktop is a rectangle, even if part of that rectangle is not displayed on any monitor. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SILICONMOTION driver programmers please help!!!!
Thanks a lot for your help. Please find below Xorg.0.log after Xorg -config /root/xorg.conf -logverbose 7: (II) config/hal: initialized_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/casiopea.lukawski.net:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-RELEASE i386 Current Operating System: FreeBSD casiopea.lukawski.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Wed Mar 10 07:08:19 CET 2010 r...@casiopea.lukawski.net:/usr/obj/usr/src/sys/FIVA i386 Build Date: 06 March 2010 02:03:54PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 19 15:17:34 2010 (++) Using config file: "/root/xorg.conf" (==) ServerLayout "XFree86 Configured" (**) |-->Screen "FIVA Screen" (0) (**) | |-->Monitor "FIVA 8.4inch LCD" (**) | |-->Device "Silicon Motion Lynx" (**) |-->Input Device "FIVA Point" (**) |-->Input Device "FIVA Keyboard" (**) Option "DontZap" "off" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x6a0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:0:9:0) 126f:0712:126f:0712 Silicon Motion, Inc. SM712 LynxEM+ rev 160, Mem @ 0xfd00/16777216, BIOS @ 0x/65536 (II) System resource ranges: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] -1 0 0x - 0x (0x1) IX[B] [4] -1 0 0x - 0x00ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI clas
Re: Missing symbol error when building X.org from git
On Thu, Mar 18, 2010 at 9:12 PM, Joel Feiner wrote: > On Thu, Mar 18, 2010 at 4:58 PM, Dan Nicholson wrote: >> >> On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner wrote: >> > On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson >> > wrote: >> >> >> >> On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner >> >> wrote: >> >> > The error that comes up is this: >> >> > libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall >> >> > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes >> >> > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing >> >> > -Wbad-function-cast -Wformat=2 -Wold-style-definition >> >> > -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN >> >> > -DHAS_STICKY_DIR_BIT -I/home//xbuild/out/include/pixman-1 >> >> > -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext >> >> > -I../../composite -I../../damageext -I../../xfixes -I../../Xi >> >> > -I../../mi >> >> > -I../../miext/shadow -I../../miext/damage -I../../render >> >> > -I../../randr >> >> > -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod >> >> > -I/home//xbuild/out/include/libdrm -I/usr/include/freetype2 -O2 >> >> > -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic -o >> >> > Xdmx >> >> > dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o >> >> > dmxfont.o >> >> > dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o >> >> > dmxpixmap.o >> >> > dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o >> >> > dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o >> >> > -L/home//xbuild/out/lib64 ../../fb/.libs/libfb.a >> >> > ../../mi/.libs/libmi.a >> >> > ../../render/.libs/librender.a ../../Xi/.libs/libXi.a >> >> > ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a >> >> > ../../miext/shadow/.libs/libshadow.a >> >> > ../../miext/damage/.libs/libdamage.a >> >> > ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a >> >> > ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a >> >> > /usr/lib64/libhal.so >> >> > /usr/lib64/libdbus-1.so ../../os/.libs/libos.a >> >> > /usr/lib64/libgcrypt.so >> >> > -L/usr/lib64 /usr/lib64/libgpg-error.so >> >> > ../../xfixes/.libs/libxfixes.a >> >> > glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a >> >> > /home//xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so >> >> > /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so >> >> > /home//xbuild/out/lib64/libXfixes.so >> >> > /home//xbuild/out/lib64/libXi.so >> >> > /home//xbuild/out/lib64/libXext.so >> >> > /home//xbuild/out/lib64/libX11.so >> >> > /home//xbuild/out/lib64/libxcb.so >> >> > /usr/lib64/libXdmcp.so -ldl /home//xbuild/out/lib64/libXfont.so >> >> > /usr/lib64/libfreetype.so /home//xbuild/out/lib64/libfontenc.so >> >> > -lz >> >> > /home//xbuild/out/lib64/libXau.so >> >> > /home//xbuild/out/lib64/libpixman-1.so >> >> > /home//xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath >> >> > -Wl,/home//xbuild/out/lib64 -Wl,-rpath >> >> > -Wl,/home//xbuild/out/lib64 >> >> > >> >> > /home//xbuild/out/lib64/libXi.so: undefined reference to >> >> > `XESetWireToEventCookie' >> >> > >> >> > /home//xbuild/out/lib64/libXi.so: undefined reference to >> >> > `XESetCopyEventCookie' >> >> > What appears to be happening, I think, is that it is getting >> >> > libraries >> >> > like >> >> > libXrender and so on from /usr/lib64 instead of my build directory. >> >> > I'm >> >> > not >> >> > sure why libtool is doing this. I have my PKG_CONFIG_PATH set to my >> >> > local >> >> > build package config path (/home//xbuild/out/lib64/pkgconfig) and >> >> > LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part). I >> >> > had >> >> > also >> >> > built the whole get up without using LD_LIBRARY_PATH. Same results. >> >> > The >> >> > only two modules that have this problem are pixman and xserver. >> >> > Pixman >> >> > I >> >> > worked around by passing --disable-gtk to ./configure, since that was >> >> > the >> >> > part of the build that was failing. For xserver, it appears to be >> >> > dmx >> >> > that's failing. >> >> >> >> If I had to guess, the /usr/lib64 is getting hardcoded into one of the >> >> .la libtool archives installed in /home. Can you do "grep /usr/lib64 >> >> /home//xbuild/out/lib64/*.la"? Maybe there's a problem with module >> >> ordering in xorg.modules. Not sure if that's what's causing the >> >> reference errors, though. >> >> >> >> -- >> >> Dan >> > >> > I actually did grep for /usr/lib64 in my ~/xbuild (where the source and >> > output trees live) and removed all references in the libtool archives >> > (and >> > even in libtool itself!). It didn't make a difference. >> >> Next time can you record what those references were? That would help >> solve this problem. > > They are now attached. I stripped out some obvious irrelevant lines (like > /usr/lib64/dbus*). It's down to 254 lines, which hopefully shouldn't be too > mu
How configure dual head on different graphic cards?
I'm trying configure two monitors on my several desktop systems (Fedora 12 or Fedora 13 beta i686, kernels 2.6.31/2.6.32/2.6.33, Xorg server 1.7.5.901, XRandR 1.3, desktops have integrateg graphics (Intel G35 or Radeon Xpress 200G[RS480]), 1-4GB RAM, PCIe busses). Somewhere on net I found, X server version >= 1.7 can support multiple different graphics card (not only dual/triple link ones), then I tried configure systems with internal + one add-on card. Until now I'm unsuccessful. Fedora's tool "system-config-display" do not detect secondary video card, I experiment with some dynamic configuration (xrandr) or static with xorg.conf, but without success. Some experiments with adding dual-link MGA G550 card wasn't successful too, I wasn't able supress integrated graphic card. As I have no big experience with actual up-to-date X configuration, please, is there any cookbook/Howto how do this tasks? It would be best with some troubleshooting knowledge. What I found on net, was all about dual-link cards and RandR 1.2. Or, for some direct suggestion from this list, which information I should post here? Thanks in advance, Franta Hanzlík ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SILICONMOTION driver programmers please help!!!!
Piotr Lukawski writes: > Just tried: > (II) LoadModule: "siliconmotion" > (II) Loading /usr/local/lib/xorg/modules/drivers//siliconmotion_drv.so > (II) Module siliconmotion: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.7.3 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) SMI: driver (version 1.7.3) for Silicon Motion Lynx chipsets: Lynx, > LynxE, Lynx3D, LynxEM, LynxEM+, Lynx3DM, Cougar3DR, MSOC > (II) Primary Device is: PCI 0...@00:09:0 > (WW) Falling back to old probe method for siliconmotion > (--) Chipset LynxEM+ found > > The result exactly the same, white screen :-( > Any other ideas? Could you provide more verbose logs? E.g. the ones you get after running: $ Xorg -logverbose 7 pgpIXz1miPbug.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
mouse leaves screen
I have a X setup to use two screens side by side: the first is my laptop's panel (1440x900) the second is a LCD (1280x1024). I run xorg-server 1.6.5 on a Gentoo Linux with KDE on top. Everything is working perfectly except for one inconvenience. The mouse pointer will leave the screen on the bottom of the 1440x900 panel. I suppose it happens because the height of the screen is less then the height of the LCD. All window operations seem to work with the correct dimensions, e.g. maximizing a window will not make it larger than the panel actually is. Is there a way to fix this? Grüße Jan Hackel snip --- xorg.conf (parts): Section "Monitor" Identifier "LVDS" DisplaySize 333208 Option "ModelName" "MacBook Pro Display" Option "DPMS" "true" Option "RightOf" "LCD" EndSection Section "Monitor" Identifier "LCD" Option "ModelName" "1280x1024 LCD Display" Option "DPMS" "true" Option "LeftOf" "LVDS" EndSection Section "Device" Identifier "X1600 (OS)" Driver "radeon" Option "AccelMethod" "EXA" Option "monitor-PANEL" "LVDS" Option "monitor-LVDS " "LVDS" Option "monitor-DVI-0" "LCD" Option "monitor-DVI-I_1/digital" "LCD" Option "RROutputOrder" "LVDS" # Primary Display Option "DynamicClocks" "true" # some power management Screen 0 EndSection Section "Screen" Identifier "Dual-Screen" Device "X1600 (OS)" Monitor"LVDS" DefaultDepth 24 SubSection "Display" Virtual 2720 1024 Depth 24 Modes"1440x900" "1280x1024" EndSubSection EndSection ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
