Re: compiling 32bit libraries on x86-64 system
Dirk Hohndel writes: > I must be missing some 'configure' magic here... > > For some modules (like the X server) it's rather straight forward to > build 32bit on a 64bit system. Something like > > LDFLAGS=-L/opt/X11R7-32/lib ./configure --prefix=/opt/X11R7-32 > --enable-32-bit --build=x86-linux It's not usually relevant, but these days recommended practice is setting the variables *after* ./configure, e.g.: ./configure LDFLAGS=-L/opt/... \ --prefix=... --enable-32-bit --build=... > But for some other modules this fails (for example, libX11 doesn't know > the --enable-32-bit flag). Worse, there doesn't seem to be a clean way > to separate 32 and 64bit libraries and have apps pick up the right libs > when running a custom build... > > Any suggestions? At least w/ gcc, can you just add -m32 to your compiler command line? ./configure CFLAGS="-m32" LDFLAGS=-L/opt/... \ --prefix=... --enable-32-bit --build=... -tom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
compiling 32bit libraries on x86-64 system
I must be missing some 'configure' magic here... For some modules (like the X server) it's rather straight forward to build 32bit on a 64bit system. Something like LDFLAGS=-L/opt/X11R7-32/lib ./configure --prefix=/opt/X11R7-32 --enable-32-bit --build=x86-linux appears to do the trick. But for some other modules this fails (for example, libX11 doesn't know the --enable-32-bit flag). Worse, there doesn't seem to be a clean way to separate 32 and 64bit libraries and have apps pick up the right libs when running a custom build... Am I missing something? Is there a readme or a wiki entry somewhere? Any suggestions? (and in case you are wondering why I'm trying to do this... I have a commercial 32bit application that uses GLX; I want to run the very latest X server and mesa on my GM45 based laptop; so I need to be able to build my own server with its libraries in both 64bit (as I am running F10-x86-64) and 32bit (for the 32bit app)) Thanks /D ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
i945gma 2048x2048 limit, how to use DRI & XRandR?
Hello, is there possibility that this issue with limited virtual screen size (framebuffer size) will be solved soon? I just bought new monitor (1680x1050) as extension to my ultraportables (IBM X60s/1024x768) screen which is good for ssh, web but not for Eclipse and so on. I'm not able to use those two with side-by-side layout with DRI because 2704 > 2048. It's annoying. Currently I'm using top-down layout but my docking solution is side-by-side (have laptop stand and only one small desk :). Is there any way to set at least one display as DRI capable or so? I found some ML entries about possibility to solve this, but what's real status? Can I help somehow? Using Debian/GNU Linux 2.6.27/dri with 7.4 Xorg from experimental, DRI works fine with <=2048x2048 fb. Dualhead setup works in Windows XP SP3 with 3D acceleration on both monitors so it's possible I think. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Thank you for replies and I'm sorry, my english isn't good. -- Ondřej Baláž ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Accounts and membership?
'Twas brillig, and Marc Balmer at 01/01/09 22:19 did gyre and gimble: > When will > > http://bugs.freedesktop.org/show_bug.cgi?id=17271 > > be taken care of? This is seriously getting ridicoulous. > > X.Org looks like a shit show run by amateurs to me. > > If I as a member of X.Org can not get a freedesktop account, > well that is one thing. But if I don't even get *an answer* > to my request, that makes X.Org look like idiots. > > So please either act on my request (by answering) or cancel me > being an X.Org member. I do not want to be a member of a shit show > that does not even answer to requests for months. I don't want to speak out of turn but as a complete neutral just looking at the bug report, it's quite clear that it's just been overlooked. There was no reminder from yourself until today with the above email and a comment on the bug. A gentle reminder on your part before a tirade would have shown more professionalism IMO. Remember that Matthieu said: "I can confirm that he also has experience on cooperative work and social behaviour"... you should try to ensure that still holds true. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Accounts and membership?
When will http://bugs.freedesktop.org/show_bug.cgi?id=17271 be taken care of? This is seriously getting ridicoulous. X.Org looks like a shit show run by amateurs to me. If I as a member of X.Org can not get a freedesktop account, well that is one thing. But if I don't even get *an answer* to my request, that makes X.Org look like idiots. So please either act on my request (by answering) or cancel me being an X.Org member. I do not want to be a member of a shit show that does not even answer to requests for months. Marc Balmer -- Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code." ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building the whole X stack, results in no i915.ko
Thank you for taking the time to answer, Eric Anholt a écrit : > On Thu, 2009-01-01 at 18:57 +0100, Lucas Charles wrote: > >> Hello everyone, >> As I own a new laptop powered by a intel chipset (GM45 or something like >> that :p, comes with a centrino 2), I decided to build the whole X stack >> when I found this tutorial. >> http://www.x.org/wiki/Development/git >> But when I wanted to do the different insmod as described in the >> 'Running your new stack' section, I found out that the i915.ko was not >> build (no i915.ko in drm/linux-core), so my questions are. >> > > The kernel module comes from the linux kernel. > > I am a bit confused, I think I need some clarification as in the tutorial it's written : # insmod ///linux-core/i915.ko I understood that it was /root/drm/linux-core/i915.ko, as the drm.ko is build as is present at /root/drm/linux-core/drm.ko ? Again I thought i915.ko would have been build with make -C linux-core. The kernel source are found by the scripts that need it and as the drm module from (/root/drm...) can be loaded, I guess it is build against the right kernel (e.g 2.6.27), am I right ? I think I completely missed the point of your indication, and I don't to waste anybody's time, so may be you have a reference where I can see what I am doing wrong. Best Regards, Lucas Charles ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
can't VT switch with intel
Anybody else having this problem? With Linux 2.6.28 (x86-64), Intel 2.5.1, and xorg 1.5.99.3 I can't switch VT on GM965. If I chvt from X, I just see garbage (vertical green stripes, etc). I can switch back to X, though, and the machine doesn't crash or anything like that. -jwb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building the whole X stack, results in no i915.ko
On Thu, 2009-01-01 at 18:57 +0100, Lucas Charles wrote: > Hello everyone, > As I own a new laptop powered by a intel chipset (GM45 or something like > that :p, comes with a centrino 2), I decided to build the whole X stack > when I found this tutorial. > http://www.x.org/wiki/Development/git > But when I wanted to do the different insmod as described in the > 'Running your new stack' section, I found out that the i915.ko was not > build (no i915.ko in drm/linux-core), so my questions are. The kernel module comes from the linux kernel. -- Eric Anholt e...@anholt.net eric.anh...@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
Re: xserver: Branch 'master'
On Thu, Jan 01, 2009 at 02:26:33PM -0200, Paulo C?sar Pereira de Andrade wrote: > Thanks for the information. I was afraid it could not work > correctly with Solaris or BSD make, given the large amount of > problems to write a small awk script that works everywhere... > But the feature, as noted in "info make" is from SGI make (and > perhaps others), and the other alternative is from SunOS 4. Please use the correct approach of including the static dependencies by default and add a maintainer rule for regeneration them. Using conditional includes for this is entire pointless. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building the whole X stack, results in no i915.ko
Post the output from the "Building DRM" section. If you forgot to do that, you won't have a i915.ko. Also, make sure it can find your kernel. You might have to pass LINUXDIR=/usr/src/linux-blah-blah-blah when you invoke make. Lucas Charles wrote: > Hello everyone, > As I own a new laptop powered by a intel chipset (GM45 or something like > that :p, comes with a centrino 2), I decided to build the whole X stack > when I found this tutorial. > http://www.x.org/wiki/Development/git > But when I wanted to do the different insmod as described in the > 'Running your new stack' section, I found out that the i915.ko was not > build (no i915.ko in drm/linux-core), so my questions are. > Is it the right module for my hardware ? > If it is, then what am I missing here ? > Is it when I decided to build xserver like that: (don't know exactly > what I am doing here) > ./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts > --with-mesa-source --with-xkb-path=/usr/share/X11/xkb > I need the xkb flag as I use a swiss keyboard, builtin-fonts because it > seems to be recommended, and with-mesa-source because it was mentionned > that it can be of some use (hmm honestly there I'm lost ). > I actually run a 2.6.27 kernel, which doesn't support kms, is it an > issue,with the standard makefile in the git repos ? > > I'm pretty new when it comes to building linux stuff from source > (espacially such big projects like that), so if you want to flame me for > bugging you, feel free to tell me that I'am just too curious ;-) . > > Thanks for reading > Lucas Charles > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Problem building the whole X stack, results in no i915.ko
Hello everyone, As I own a new laptop powered by a intel chipset (GM45 or something like that :p, comes with a centrino 2), I decided to build the whole X stack when I found this tutorial. http://www.x.org/wiki/Development/git But when I wanted to do the different insmod as described in the 'Running your new stack' section, I found out that the i915.ko was not build (no i915.ko in drm/linux-core), so my questions are. Is it the right module for my hardware ? If it is, then what am I missing here ? Is it when I decided to build xserver like that: (don't know exactly what I am doing here) ./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts --with-mesa-source --with-xkb-path=/usr/share/X11/xkb I need the xkb flag as I use a swiss keyboard, builtin-fonts because it seems to be recommended, and with-mesa-source because it was mentionned that it can be of some use (hmm honestly there I'm lost ). I actually run a 2.6.27 kernel, which doesn't support kms, is it an issue,with the standard makefile in the git repos ? I'm pretty new when it comes to building linux stuff from source (espacially such big projects like that), so if you want to flame me for bugging you, feel free to tell me that I'am just too curious ;-) . Thanks for reading Lucas Charles ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Mouse and KVM Issue
I am having a problem with my Microsoft PS/2 optical wheel mouse when I switch between machines with a KVM switch. Specifically, my Mandriva machine no longer recognizes a mouse is attached (Windows does not have a problem with switching). Some research has come up with a suggestion that the mouse protocol be changed in xorg.conf to PS/2. However, it is currently ExplorerPS/2 and when I try to change it, it magically reverts so I don't know if that change will fix my problem or not. Perhaps someone can tell me either why the mouse protocol will not stay the way I set it or, better yet, why the mouse goes away after using the KVM switch. As an alternative, is there a USB utility I can use to monitor the device and reload the driver when it senses it is back? Thanks. _ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, 2009-01-01 at 14:26 -0200, Paulo César Pereira de Andrade wrote: > Matthieu Herrb wrote: > > Paulo Cesar Pereira de Andrade wrote: > >> hw/xfree86/loader/Makefile.am |6 -- > >> hw/xfree86/loader/sdksyms.sh | 13 + > >> 2 files changed, 17 insertions(+), 2 deletions(-) > >> > >> New commits: > >> commit 86dc660588a615baefb1799d78a501c95a931d77 > >> Author: Paulo Cesar Pereira de Andrade > >> Date: Tue Dec 23 18:07:54 2008 -0200 > >> > >> Improve sdksyms.c automatic generation (Fix #19245). > >> > >> Since it is already parsing cpp output, create a dependency file > >> in the same process. This will cause sdksyms.c to be regenerated > >> whenever a sdk header is modified. > >> This also uses the gmake 'sinclude' directive (don't fail if > >> included file doesn't exist). This should not cause any problems > >> given that gmake only constructs are used in several other > >> Makefiles. > >> > > > > Sorry no, so far I was able to use bmake (BSD make) for all X.Org > > modules. What other Makefiles are using GNU make constructs? > > Thanks for the information. I was afraid it could not work > correctly with Solaris or BSD make, given the large amount of > problems to write a small awk script that works everywhere... > But the feature, as noted in "info make" is from SGI make (and > perhaps others), and the other alternative is from SunOS 4. FWIW, FreeBSD make at least has support for sinclude. .sinclude "file" Like .include, but silently ignored if the file cannot be found and opened. robert. > Paulo > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Matthieu Herrb wrote: > Paulo Cesar Pereira de Andrade wrote: >> hw/xfree86/loader/Makefile.am |6 -- >> hw/xfree86/loader/sdksyms.sh | 13 + >> 2 files changed, 17 insertions(+), 2 deletions(-) >> >> New commits: >> commit 86dc660588a615baefb1799d78a501c95a931d77 >> Author: Paulo Cesar Pereira de Andrade >> Date: Tue Dec 23 18:07:54 2008 -0200 >> >> Improve sdksyms.c automatic generation (Fix #19245). >> >> Since it is already parsing cpp output, create a dependency file >> in the same process. This will cause sdksyms.c to be regenerated >> whenever a sdk header is modified. >> This also uses the gmake 'sinclude' directive (don't fail if >> included file doesn't exist). This should not cause any problems >> given that gmake only constructs are used in several other >> Makefiles. >> > > Sorry no, so far I was able to use bmake (BSD make) for all X.Org > modules. What other Makefiles are using GNU make constructs? Thanks for the information. I was afraid it could not work correctly with Solaris or BSD make, given the large amount of problems to write a small awk script that works everywhere... But the feature, as noted in "info make" is from SGI make (and perhaps others), and the other alternative is from SunOS 4. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] dix: Fix handling of do_not_propagate_mask window attribute
On Fri, 26 Dec 2008 07:34:39 +0100, Kim Woelders wrote: Hello, It looks like handling of the do_not_propagate_mask window attribute has been broken at some point. Attached patch should fix that. No comments? To be more specific, I think the breakage was caused by commit 32aa252e988be8cbfd4f7e373fb7b7736ef1f5f2: "dix: Process an input event as a single event, instead of two separate ones." I have attached a test case that should demonstrate the problem. The test program creates a 100x100 window with a 50x100 child window on the left side. The parent window selects (among other things) PointerMotionMask. The child window selects no events but sets the do_not_propagate_mask to PointerMotionMask. When the pointer is moved over the window the test should report motion events only when over the right half. However, with current git motion events are reported over the entire window. Things work as expected with Xorg 1.5 and with current git + suggested patch. /Kim test-do_not_propagate_mask.c Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Paulo Cesar Pereira de Andrade wrote: > hw/xfree86/loader/Makefile.am |6 -- > hw/xfree86/loader/sdksyms.sh | 13 + > 2 files changed, 17 insertions(+), 2 deletions(-) > > New commits: > commit 86dc660588a615baefb1799d78a501c95a931d77 > Author: Paulo Cesar Pereira de Andrade > Date: Tue Dec 23 18:07:54 2008 -0200 > > Improve sdksyms.c automatic generation (Fix #19245). > > Since it is already parsing cpp output, create a dependency file > in the same process. This will cause sdksyms.c to be regenerated > whenever a sdk header is modified. > This also uses the gmake 'sinclude' directive (don't fail if > included file doesn't exist). This should not cause any problems > given that gmake only constructs are used in several other Makefiles. > Sorry no, so far I was able to use bmake (BSD make) for all X.Org modules. What other Makefiles are using GNU make constructs? -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev keyboard problem in xorg 1.5.2 and evdev 2.0.99+
On Wed, Dec 31, 2008 at 10:23:45PM -0700, Scott Serr wrote: > Yes, it disappeared like magic when I run from from gdm instead of > startx. startx launching gnome seems to always have this weird effect, > until I fiddle with the VisualEffects. Did I mention I have to do this > each time I start gnome this way? I reverted back to Hardy from > Intrepid since multiseat seems more stable there... and Hardy even has > this problem, atleast on my hardware. > > This information might help someone try to squash the bug better. The bug has been fixed for 1.5 although patches are required on top of 1.5.3. 1.6 patches are in the queue for cherry-picking from master, and master is fixed. thanks for trying to help though. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [news] TWM -- Revised Edition
On Tue, Sep 30, 2008 at 07:20:25PM +0200, Eeri Kask wrote: > Having tweaked the TWM since last year to turn it into something > contemporary in look and handy in function, today as a landmark of > approaching zero items in my own kept TWM bugs-, todo- and wish-list may > I use the moment to present this humble effort which has kept me pretty > busy in the leisure time since then. Hi Eeri, It looks like you've got twm pretty much under control. If you want an account to commit directly to our twm git repository and make your own releases, please see http://www.freedesktop.org/wiki/AccountRequests. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multihead Displays
Jason Gauthier wrote: > All, > > > > I apologize if this is a misdirected request for assistance. I’ll > gladly send it to the appropriate place. > > I’m attempting to multihead an Intel video card and a USB VGA adapter. > You don't specify which version of the X server you're using. This may be useful since things are changing in this area... > > While I can get both “screens” to work with X, it’s a not a true > desktop, as they are both disconnected from each other. > > The mouse can move back and forth, but that is all. That's the traditional (legacy) way to handle multihead in X: each head gets its own connexion :0.0, :0.1 and so on. > When I attempt to enable ‘xinerama’ I get a seg fault. Currently this should indeed the way to go. If you get a segfault this is a bug and more information (Xorg.0.log for instanct) would be helpful to try to debug and fix it. > > From my reading, xrandr doesn’t support the USB VGA adapter. > the current versions of xrandr don't support multiple cards. This is an addition planned for the future. But also the SiS usb vga driver has currently no active maintainer, so even when this gets implemented, it will take some time before it becomes available on this driver. > So, I’m left wondering how to accomplish this task. Any insight is helpful! -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr: needs changes for dualhead + panning
Maarten Maathuis wrote:
> On 12/23/2008 12:14 PM, Eeri Kask wrote:
>>> Maarten Maathuis:
>>> On 12/19/2008 08:42 PM, Carl Karsten wrote:
>>>
> The placement logic is output driven, and doesn't take panning into
> account. So you end up with strange overlap. If dual head + panning
> was a goal you might consider fixing this. It doesn't seem trivial to
> do from a quick look. On the plus side it's just a xrandr change.
>
dual head + panning could mean
a the whole space pans when you get to the side of the virtual space,
b pan each physical display separately,
c a combination of a/b.
zoiks
Carl K
>>> (a) would need changes on the protocol side (imo)
>>>
>>> I was thinking of (b).
>>>
>>> Maarten.
>>>
>>
>>
>> Indeed, other ideas than being "output driven" could include "pointing
>> device driven" (or "screen centric", if there are :0.0, :0.1, etc
>> present). :-)
>>
>> [...snip...]
>>
> The problem is mostly one of how applications see your screen. One
> xinerama screen or two?
> b would have two (which is the current situation), a might have one.
This ambiguity emerges out of the apparently missing "big picture"
providing an idea how the Xinerama and Randr technologies are supposed
to fit together in the X11 architecture; unfortunately the common
documentation doesn't help in creating that picture too. :-)
Views appearing sometimes supporting the forecast Randr obsolating
Xinerama at a first sight look like a request to replace rational
numbers by integers: it is certainly justified, assuming this simplifies
overall complexity at no loss in model performance. The above forecast
sure comes true, but it is uncertain if beyond laptop computer users: in
a contrary, imaginary case of a, say some Tesla-rack-like apparatus
featuring numerous separate graphics units, as of today, reading the
randrproto.txt document it is not clear how Randr replacing Xinerama
could cope in providing a single m-by-n tiled visible rendering area out
of these --- the need for dynamically runtime-configurable, plugin
screens etc, many arguments valid for handheld devices simply do not
exist in these scenarios.
It is evident that Xinerama and Randr are not duplicated efforts.
Historically one could put e.g. several different video cards into ISA
slots and Xinerama coupled the physical framebuffers into a logical
one~[1]. In contrast, Randr-1.2 today apparently provides essentially
this: given one physical framebuffer, this is decomposed into various
virtual ones, each corresponding to a CRTC.
These are semantically clearly inverse operations. Anyway, a random
application probably doesn't care about the hardware ordering --
combined together or decomposed apart -- it has to deal with physical
TFT-panels as viewports of a noncontiguous rendering area presented to
the user, which carry many semantical aspects of usual X11-windows ...
they are mostly in the same sense configurable and the configuration
events are reported to the application by X11-events. Though, from that
point of view, an essential feature missing yet is mouse event
mechanism, Enter/Leave and everything the like (much the same if moving
the mouse from ":0.0" to ":0.1", or from window to window; mouse
location queries, etc).
Greetings,
Eeri Kask
[1] Unfortunately Xinerama-tiling apparently replaced the historical
X11-display decomposing into X11-screens (":0.0", ":0.1", etc) by a
single screen ":0.0", and was not layered beneath the X11-screens (e.g.
how to configure a 2x2-Xinerama-tiled X11-screen as ":0.0" besides a
1x1-one as ":0.1", etc?). Today, different rendering hardware becoming
common (TV, sterescopic/multiview imaging devices, game consoles,
handhelds, etc) creates the need to combine X11-screens, some
Xinerama-tiled and some not, some dynamically attached and some not,
some colorful and some greylevel, into a single X11-display.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
