libX11-6.2.1 and pkg-config 0.23
In libX11-6.2.1:
The configure piece below is wrong, (or pkg-config is buggy) because
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
I'm using pkg-config --version 0.23
#
# Find keysymdef.h
#
KEYSYMDEF=
for flag in $XPROTO_CFLAGS; do
echo checking arg $flag
case $KEYSYMDEF in
)
case $flag in
-I*)
dir=`echo $flag | sed 's/^-I//'`
file=$dir/X11/keysymdef.h
echo looking for $file
if test -f $file; then
KEYSYMDEF=$file
fi
;;
esac
;;
esac
done
case $KEYSYMDEF in
)
{ { echo $as_me:$LINENO: error: \Cannot find keysymdef.h\ 5
echo $as_me: error: \Cannot find keysymdef.h\ 2;}
{ (exit 1); exit 1; }; }
;;
esac
The following is /usr/lib/pkgconfig/xproto.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
includex11dir=${prefix}/include/X11
Name: Xproto
Description: Xproto headers
Version: 7.0.13
Cflags: -I${includedir}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, among others creating a massive incompatability headache. A prime principle of the X.org project should be to retain backwards compatability so that older applications may still run. Stop destroying backwards compatability and get around to fixing the memory leaks for god sake. X.org also seems to be intent on locking itself out of the embedded/cell market by removing support for low depth displays. I am throughly dismayed and disgusted with X.org. Are you trying to start a flamewar ? If so, save yourself the trouble. Best regards, Maciej Grela ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
Pedro Izecksohn wrote:
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
Same here, on my local system (gentoo + X11 overlay). In my git tree it
gives a good-looking -I arg.
Though I never had problems building anything. Weird. You may try using
specialized package definitions like kbproto, though that failed too on
my local.
A diff returns only obvious stuff (see below), so I'd say its a
pkg-config related issue.
James, any idea?
diff /usr/lib/pkgconfig/xproto.pc ../../build/lib/pkgconfig/xproto.pc
1c1
prefix=/usr
---
prefix=/usr/src/xorg/build
3c3
libdir=${exec_prefix}/lib
---
libdir=/usr/src/xorg/build/lib
9c9
Version: 7.0.13
---
Version: 7.0.14
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
2009/2/19 Maciej Grela maciej.gr...@gmail.com: 2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. From his previous posts[1], it looks like he's talking about ProSavage DDR on Freebsd. I attempted to try to help by getting him to run pmap, but it seems freebsd doesn't have pmap. [1] http://lists.freedesktop.org/archives/xorg/2008-December/041494.html JohnFlux ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, 19 Feb 2009 09:18:39 + John Tapsell johnf...@gmail.com wrote: 2009/2/19 Maciej Grela maciej.gr...@gmail.com: 2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. From his previous posts[1], it looks like he's talking about ProSavage DDR on Freebsd. I attempted to try to help by getting him to run pmap, but it seems freebsd doesn't have pmap. I have no idea if it's the same thing you are referring to, but there is pmap port in sysutils/pmap on FreeBSD. It does not have a -d option, but 'pmap pidofxorg' gives me: 2780: /usr/local/bin/X Address Kbytes RSS SharedPriv Mode Mapped File 0804800014841308 -1308 r-x /usr/local/bin/Xorg 081BB000 24 24 - 24 rw- /usr/local/bin/Xorg 081C1000 148 148 - 148 rw- [ anon ] 081E6000 104 4 - 104 rwx [ anon ] 281BB000 148 104 148 - r-x /libexec/ld-elf.so.1 281E 8 8 - 8 rw- /libexec/ld-elf.so.1 snip Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Wed, 18 Feb 2009 18:22:21 -0800 (PST) milnser43...@yahoo.com milnser43...@yahoo.com wrote: There are very serious and severe memory leaks under X.org with the savage driver You forgot to attach the fixes At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, You forgot to volunteer to maintain them - not that I find you believable. The idea that anyone uses PEX is rather implausible. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Feb 18, 09 14:40:34 +, John Tapsell wrote: So it is a validation tool, but not a benchmark. A benchmark - by definition - gives you performance figures that can be compared with other systems, which gives you a reasonable notion of which of the systems is better. Right. If one system gets 100fps and another gets 1,000fps, then you compare the two systems and say that one is better than the other. Which is not necessarily true with glxgears. And that is exactly all I'm saying. Anyway, apparently you don't want to understand that everybody actually developing on 3D here is sick of hearing glxgears performance numbers. Sorry for the rant Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Feb 18, 09 12:58:49 -0500, Jim Gettys wrote: On Wed, 2009-02-18 at 10:49 -0700, McDonald, Michael-p7438c wrote: Dumb question: Do LCD/Plasma/OLED/... Actually have vertical retrace? Does the vblank interval approach 0? LCD: yes Plasma: yes OLED: ? (still mostly vaporware, and I'm sure compatibility means it would have this characteristic at the moment, even if the technology doesn't). You will always have the vertical retrace of the signal lane (read: TMDS, LVDS, or VGA). Unless you have a massively parallel RAM readout and connection to the display ;-) CU Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
Simon Thum wrote: Pedro Izecksohn wrote: pkg-config --cflags xproto prints a line-feed only and keysymdef.h exists in my system and it is in the right place. Same here, on my local system (gentoo + X11 overlay). In my git tree it gives a good-looking -I arg. Sorry for the noise. I haven't found the issue, but a majority of .pc's in my system doesn't output cflags. So it's something configuration- or pkc-config related. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Help please, with compile drm
Thank you all for your comments! On Tue, Feb 17, 2009 at 10:39 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 16, 2009 at 10:22 PM, tac jeuse@gmail.com wrote: ps. I was running into this when I type make install from the source: Making install in libdrm make: Fatal error in reader: Makefile, line 658: Unexpected end of line seen Current working directory /export/work/xorg/drm/libdrm *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo install-recursive | sed s/-recursive//`; \ list='libdrm shared-core tests'; for subdir in $list; do \ echo Making $target in $subdir; \ if test $subdir = .; then \ dot_seen=yes; \ local_target=$target-am; \ else \ local_target=$target; \ fi; \ (cd $subdir make $local_target) \ || eval $failcom; \ done; \ if test $dot_seen = no; then \ make $target-am || exit 1; \ fi; test -z $fail make: Fatal error: Command failed for target `install-recursive' That's just regular automake rules, which are pretty widely tested. It could be a GNU make issue, but I doubt it. Maybe if you could should the whole log from make it could help. -- Dan I know few about make, so any insight point would be welcomed : ) When I using the standard make with the solaris distro, I get something like the Makefile went wrong.(see below) Using gmake *makes* more sense, but seems it doesn't find some necessary libs or .h files? So maybe really because Solaris doesn't support drm yet? In any way, point me out please when I go wrong. Thanks Tac p.s. Trying the same on Ubuntu 8.04 should be all right :( using make # make Making all in libdrm make: Fatal error in reader: Makefile, line 658: Unexpected end of line seen Current working directory /export/work/xorg/drm/libdrm *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='libdrm shared-core tests'; for subdir in $list; do \ echo Making $target in $subdir; \ if test $subdir = .; then \ dot_seen=yes; \ local_target=$target-am; \ else \ local_target=$target; \ fi; \ (cd $subdir make $local_target) \ || eval $failcom; \ done; \ if test $dot_seen = no; then \ make $target-am || exit 1; \ fi; test -z $fail make: Fatal error: Command failed for target `all-recursive' While around Makefile 658, it is: .PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \ all all-am check check-am clean clean-generic \ clean-libdrm_laLTLIBRARIES clean-libtool ctags ctags-recursive \ distclean distclean-compile distclean-generic distclean-hdr \ distclean-libtool distclean-tags distdir dvi dvi-am html \ html-am info info-am install install-am install-data \ install-data-am install-dvi install-dvi-am install-exec \ install-exec-am install-html install-html-am install-info \ install-info-am install-libdrm_laLTLIBRARIES \ install-libdrmincludeHEADERS install-man install-pdf \ install-pdf-am install-ps install-ps-am install-strip \ installcheck installcheck-am installdirs installdirs-am \ maintainer-clean maintainer-clean-generic mostlyclean \ mostlyclean-compile mostlyclean-generic mostlyclean-libtool \ pdf pdf-am ps ps-am tags tags-recursive uninstall uninstall-am \ uninstall-libdrm_laLTLIBRARIES uninstall-libdrmincludeHEADERS using gmake # gmake Making all in libdrm gmake[1]: Entering directory `/export/work/xorg/drm/libdrm' gmake all-recursive gmake[2]: Entering directory `/export/work/xorg/drm/libdrm' Making all in . gmake[3]: Entering directory `/export/work/xorg/drm/libdrm' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../shared-core -g -O2 -MT xf86drm.lo -MD -MP -MF .deps/xf86drm.Tpo -c -o xf86drm.lo xf86drm.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I../shared-core -g -O2 -MT xf86drm.lo -MD -MP -MF .deps/xf86drm.Tpo -c xf86drm.c -fPIC -DPIC -o .libs/xf86drm.o xf86drm.c: In function `drmGetVersion': xf86drm.c:717: error: syntax error before struct xf86drm.c: At top level: xf86drm.c:722: error: syntax error before if xf86drm.c:731: warning: parameter names (without types) in function declaration xf86drm.c:731: error: conflicting types for 'drmFreeKernelVersion' xf86drm.c:656: error: previous definition of 'drmFreeKernelVersion' was here xf86drm.c:731: warning: data definition has no type or storage class xf86drm.c:732: error: syntax error before return xf86drm.c:740: error: invalid type argument of `unary *' xf86drm.c:740: warning: initialization makes integer from pointer without a cast xf86drm.c:740:
Re: libX11-6.2.1 and pkg-config 0.23
On Thursday 19 February 2009 12:09:30 Simon Thum wrote: Sorry for the noise. I haven't found the issue, but a majority of .pc's in my system doesn't output cflags. So it's something configuration- or pkc-config related. In theory a lot of them shouldn't need to, because they're installed in a subdirectory of /usr/include, and you're intended to include libfoo/blah.h ... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
Bill Crawford wrote: In theory a lot of them shouldn't need to, because they're installed in a subdirectory of /usr/include, and you're intended to include libfoo/blah.h ... I guessed that also, but couldn' get it nailed down. Anyway, it looks more like the OP's script is broken. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, 19 Feb 2009, John Tapsell wrote: 2009/2/19 Maciej Grela maciej.gr...@gmail.com: 2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. From his previous posts[1], it looks like he's talking about ProSavage DDR on Freebsd. I attempted to try to help by getting him to run pmap, but it seems freebsd doesn't have pmap. [1] http://lists.freedesktop.org/archives/xorg/2008-December/041494.html I have a ProSavage (MSI motherboard) on FreeBSD 7.1-stable with xorg-7.4. Seems to work fine, although I haven't watched memory usage. Testing available if needed, although OP's rant isn't very motivating. -Warren Block * Rapid City, South Dakota USA ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
On Thu, 2009-02-19 at 13:03 +0100, Matthias Hopf wrote: On Feb 18, 09 12:58:49 -0500, Jim Gettys wrote: On Wed, 2009-02-18 at 10:49 -0700, McDonald, Michael-p7438c wrote: Dumb question: Do LCD/Plasma/OLED/... Actually have vertical retrace? Does the vblank interval approach 0? LCD: yes Plasma: yes OLED: ? (still mostly vaporware, and I'm sure compatibility means it would have this characteristic at the moment, even if the technology doesn't). You will always have the vertical retrace of the signal lane (read: TMDS, LVDS, or VGA). Unless you have a massively parallel RAM readout and connection to the display ;-) The reason I waffled is that there are good reasons to have the image stored out in the display (power in particular; the fewer pixels that change, the less you flap high capacitance lines. Driving those lines right now has become a significant part of overall system power usage). And future interfaces (DisplayPort, IIRC) to displays are capable of updating pixels independently (usually a specified rectangle).So if memory is right by the pixels the concept of vertical retrace may become moot, conceivably, someday. I agree this hasn't happened (yet). - Jim -- Jim Gettys j...@freedesktop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very slow performance of glxgears (68 fps)
Twas brillig at 09:44:35 19.02.2009 UTC-05 when j...@freedesktop.org did gyre and gimble: JG So if memory is right by the pixels the concept of vertical retrace JG may become moot, conceivably, someday. It is already, for e-ink displays. -- pgplvbV1kRRYF.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
--- On Thu, 2/19/09, Alan Cox a...@lxorguk.ukuu.org.uk wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Subject: Re: Severe memory leaks make X.org unuseable To: milnser43...@yahoo.com Cc: xorg@lists.freedesktop.org Date: Thursday, February 19, 2009, 5:47 AM On Wed, 18 Feb 2009 18:22:21 -0800 (PST) milnser43...@yahoo.com milnser43...@yahoo.com wrote: There are very serious and severe memory leaks under X.org with the savage driver You forgot to attach the fixes I have looked at the source code for X.org and the savage driver. I cannot really quite understand it at all. Is there a guide to describe and document the X.org internals in detail? At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, You forgot to volunteer to maintain them - not that I find you believable. The idea that anyone uses PEX is rather implausible. The number of apps which PEX, MIT_SUNDRY, and Ximage is probably a rather small number but certainly there have been apps written to use it. As for Xfree86-misc, I have heard that some modern screensavers use it to provide some feature that makes the screensaver work in a better manner and there has been concern over the disruption in useability this will cause. xscreensaver uses this extension. So yes removing it is a really bad idea. I dont think that backwards compatability code should be removed just because we dont dont think anyone uses it anymore, or because we can. As far as I am aware these extensions were not causing any problems and I cannot see the justification to remove them. One of the prime missions of the X.org project should be to maintain backwards compatability with the X11 protocol and with extensions for applications which need them. We cannot make assumptions that there are not applications that uses these extensions which have been there for years. ___ 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
Re: very slow performance of glxgears (68 fps)
On Thu, 2009-02-19 at 20:46 +0600, Mikhail Gusarov wrote: Twas brillig at 09:44:35 19.02.2009 UTC-05 when j...@freedesktop.org did gyre and gimble: JG So if memory is right by the pixels the concept of vertical retrace JG may become moot, conceivably, someday. It is already, for e-ink displays. Actually, not quite from one point of view; IIRC, the e-ink displays quality (in grayscale) goes down a bit if you stop updating them. (I could have this memory wrong). What is more, the frame rate of e-ink is pretty low (though will show some serious improvements over the next year or two, from what I've seen in their lab). In any case, I think the point is correct, but moot: we have to worry about VR for the time being... - Jim -- Jim Gettys j...@freedesktop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xorg-macros.m4.in minor fix for incorrect warning message
On Wed, Feb 18, 2009 at 2:52 PM, Dan danstowell+x...@gmail.com wrote: Hi - One of the warnings in xorg-macros.m4.in is wrong, it prints out the wrong version when it says requires version x.x. Patch pasted below against http://cgit.freedesktop.org/xorg/util/macros/tree/xorg-macros.m4.in - not a proper git patch sorry, but hope OK and sensible Yeah, I noticed that a couple weeks ago. Applied in 72d82ed965f9cfbc310897ec17d2dc10bddcef4e . Please do try to send in properly formatted patches if you can. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, 2009-02-19 at 06:50 -0800, milnser43...@yahoo.com wrote: The number of apps which PEX, MIT_SUNDRY, and Ximage is probably a rather small number but certainly there have been apps written to use it. As for Xfree86-misc, I have heard that some modern screensavers use it to provide some feature that makes the screensaver work in a better manner and there has been concern over the disruption in useability this will cause. xscreensaver uses this extension. So yes removing it is a really bad idea. I dont think that backwards compatability code should be removed just because we dont dont think anyone uses it anymore, or because we can. As far as I am aware these extensions were not causing any problems and I cannot see the justification to remove them. One of the prime missions of the X.org project should be to maintain backwards compatability with the X11 protocol and with extensions for applications which need them. We cannot make assumptions that there are not applications that uses these extensions which have been there for years. Are you volunteering to maintain them? The largest user base of X doesn't appear to be having compatibility issues with their removal (now Linux), and without data of what their removal may be affecting and/or a volunteer to maintain them, it seems our effort should go elsewhere. So please, concrete examples of what breaks, and help in maintenance, are the solution here. Best Regards, - Jim -- Jim Gettys j...@freedesktop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
Alan Cox wrote: On Wed, 18 Feb 2009 18:22:21 -0800 (PST) At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, You forgot to volunteer to maintain them - not that I find you believable. The idea that anyone uses PEX is rather implausible. Even with Solaris's deep commitment to backwards compatibility, we dropped PEX in Solaris 7 in 1998. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
--- On Thu, 2/19/09, Jim Gettys j...@freedesktop.org wrote: From: Jim Gettys j...@freedesktop.org Subject: Re: Severe memory leaks make X.org unuseable To: milnser43...@yahoo.com Cc: xorg@lists.freedesktop.org Date: Thursday, February 19, 2009, 9:58 AM On Thu, 2009-02-19 at 06:50 -0800, milnser43...@yahoo.com wrote: The number of apps which PEX, MIT_SUNDRY, and Ximage is probably a rather small number but certainly there have been apps written to use it. As for Xfree86-misc, I have heard that some modern screensavers use it to provide some feature that makes the screensaver work in a better manner and there has been concern over the disruption in useability this will cause. xscreensaver uses this extension. So yes removing it is a really bad idea. I dont think that backwards compatability code should be removed just because we dont dont think anyone uses it anymore, or because we can. As far as I am aware these extensions were not causing any problems and I cannot see the justification to remove them. One of the prime missions of the X.org project should be to maintain backwards compatability with the X11 protocol and with extensions for applications which need them. We cannot make assumptions that there are not applications that uses these extensions which have been there for years. Are you volunteering to maintain them? The largest user base of X doesn't appear to be having compatibility issues with their removal (now Linux), and without data of what their removal may be affecting and/or a volunteer to maintain them, it seems our effort should go elsewhere. So please, concrete examples of what breaks, and help in maintenance, are the solution here. Best Regards, - Jim -- Jim Gettys j...@freedesktop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I do apologise for the tone of my previous letters. I may be willing to volunteer to maintain the older extensions. I have been reading through the X.org source but I still a novice on X.org internals and how everything works. I would certainly like to contribute more to the project and become more of an X internals expert. I do respect and admire your contributions and work on the X system and again please disregard the tone of my previous letter. On the upside, memory leak aside, I have seen an improvement in compatability with Savage. I used to have severe problems with it only working with a 640x480 resolution on xfree86 but now its pretty much autoconfiguring so less hassle than with XFree86. I have been using this Savage adapter since xfree86 days in 2002 and indeed things are much improved under X.org in general. The DRI work is also good and the work to add the composite, render and so on is commendable and has improved the state of the X desktop. I would certainly like to help improve the features and capability of the X system to make it the most advanced and backward compatable window system in the world. Best Wishes, David Jackson ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, Feb 19, 2009 at 06:50:38AM -0800, milnser43...@yahoo.com wrote: I dont think that backwards compatability code should be removed just because we dont dont think anyone uses it anymore, or because we can. As far as I am aware these extensions were not causing any problems and I cannot see the justification to remove them. That's a fairly easy statement to make when you don't know what those extensions do. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, 2009-02-19 at 09:18 +, John Tapsell wrote: 2009/2/19 Maciej Grela maciej.gr...@gmail.com: 2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. From his previous posts[1], it looks like he's talking about ProSavage DDR on Freebsd. I attempted to try to help by getting him to run pmap, but it seems freebsd doesn't have pmap. What is pmap exactly? Maybe I can help. robert. [1] http://lists.freedesktop.org/archives/xorg/2008-December/041494.html JohnFlux ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Robert C. Noland III rnol...@2hip.net 2 Hip Networks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Ximage's byte_order field
Am I allowed to change the value of the XImage byte_order field? And if I do, will subsequent XPutImage() calls do the right thing? Does the value of byte_order default to the client's byte order? I have a memory based frame buffer from another app that I'd like to use XCreateImage() and XPutImage() to display in a repeating display loop. Unfortunately, the source frame buffer is in big endian and I'm running on a little endian machine. Thanks, Mike McDonald GDC4S/FCS/PVM/SDC ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
On Thu, 2009-02-19 at 06:18 -0800, milnser43...@yahoo.com wrote: Earlier on freebsd 7.0 pmap back in Nov. was not available and would not compile right. But now it seems to have compiled on 7.1 and is working ok. It reports memory allocations but does not report line numbers. I am going to paste a dump of what it provides of the X.org process here. I have also looked into valgrind and dtrace but I cannot get those to work at all. We only have kernel support for dtrace right now, userland support isn't there yet. robert. --- On Thu, 2/19/09, Adam K Kirchhoff ad...@voicenet.com wrote: From: Adam K Kirchhoff ad...@voicenet.com Subject: Re: Severe memory leaks make X.org unuseable To: John Tapsell johnf...@gmail.com Cc: XORG xorg@lists.freedesktop.org Date: Thursday, February 19, 2009, 4:33 AM On Thu, 19 Feb 2009 09:18:39 + John Tapsell johnf...@gmail.com wrote: 2009/2/19 Maciej Grela maciej.gr...@gmail.com: 2009/2/19 milnser43...@yahoo.com milnser43...@yahoo.com: There are very serious and severe memory leaks under X.org with the savage driver. I am on FreeBSD. This is a very serious problem as it consumes all system memory adn causes other applications to crash. It is totally unuseable and intolerable and is simply shoddy and sloppy programming. I know for a fact XFree86 did not leak memory like this, XFree86 started at about 25 MB and stayed there. What is going on here? Every since the X.org project was started the quality of X distribution has plummeted drastically. Post some details (hardware ? xorg version ? driver version ? logs ?) because there isn't enough information in your post to even start investigating the issue. From his previous posts[1], it looks like he's talking about ProSavage DDR on Freebsd. I attempted to try to help by getting him to run pmap, but it seems freebsd doesn't have pmap. I have no idea if it's the same thing you are referring to, but there is pmap port in sysutils/pmap on FreeBSD. It does not have a -d option, but 'pmap pidofxorg' gives me: 2780: /usr/local/bin/X Address Kbytes RSS SharedPriv Mode Mapped File 0804800014841308 -1308 r-x /usr/local/bin/Xorg 081BB000 24 24 - 24 rw- /usr/local/bin/Xorg 081C1000 148 148 - 148 rw- [ anon ] 081E6000 104 4 - 104 rwx [ anon ] 281BB000 148 104 148 - r-x /libexec/ld-elf.so.1 281E 8 8 - 8 rw- /libexec/ld-elf.so.1 snip Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 -- Robert C. Noland III rnol...@2hip.net 2 Hip Networks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
On Thu, Feb 19, 2009 at 12:21 AM, Pedro Izecksohn
pedro.izecks...@gmail.com wrote:
In libX11-6.2.1:
The configure piece below is wrong, (or pkg-config is buggy) because
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
I'm using pkg-config --version 0.23
#
# Find keysymdef.h
#
KEYSYMDEF=
for flag in $XPROTO_CFLAGS; do
echo checking arg $flag
case $KEYSYMDEF in
)
case $flag in
-I*)
dir=`echo $flag | sed 's/^-I//'`
file=$dir/X11/keysymdef.h
echo looking for $file
if test -f $file; then
KEYSYMDEF=$file
fi
;;
esac
;;
esac
done
case $KEYSYMDEF in
)
{ { echo $as_me:$LINENO: error: \Cannot find keysymdef.h\ 5
echo $as_me: error: \Cannot find keysymdef.h\ 2;}
{ (exit 1); exit 1; }; }
;;
esac
Yeah, this seems wrong. What it should do is:
includex11dir=`$PKG_CONFIG --variable=includex11dir xproto`
KEYSYMDEF=$includex11dir/keysymdef.h
test -f $KEYSYMDEF || AC_MSG_ERROR([Cannot find keysymdef.h in
$includex11dir])
Or something like that.
--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: openSUSE 11.1 and Intel graphics chip
A few day ago I posted this problem. I am totally stuck and cannot get the xserver working. Can anyone help me on this issue or at least point me to a resource that will be of assistance. Sincerely, Dave - Original Message From: Dave diaco...@yahoo.com To: xorg@lists.freedesktop.org Sent: Saturday, February 14, 2009 8:33:03 AM Subject: openSUSE 11.1 and Intel graphics chip I recently installed openSUSE 11.1 on a Dell Latitude X200 laptop. This laptop uses the 82830 (i830M) Intel graphics chip. Prior to installing SuSE I verified that this graphics chip is supported with numerous individuals having installed earlier versions of Linux on this laptop. No xserver problems had been reported in these posts. I have been unable to start the xserver on this laptop. I have been working with numerous people on the openSUSE mailing list to try and resolve this issue. The general consensus is that the intel_drv.so appears to be broken in this distribution with several other people having difficulties with this driver on other systems. We finally gave up and it was suggested that I move on to the hardware gurus at this site. Is there a problem with this driver in this xorg release? If so how can I get it working? I am willing to try any suggestions to make this happen. I have attached the Xorg.0.log file which ends in a fatal server error - lockup. Thanks, Dave X.Org X Server 1.5.2 Release Date: 10 October 2008 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux Discovery 2.6.27.7-9-pae #1 SMP 2008-12-04 18:10:04 +0100 i686 Build Date: 03 December 2008 09:21:06AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Wed Feb 11 11:20:00 2009 (++) Using config file: /tmp/sax2-9144/xorg.conf (==) ServerLayout Layout[all] (**) |--Screen Screen[0] (0) (**) | |--Monitor Monitor[0] (**) | |--Device Device[0] (**) |--Input Device Keyboard[0] (**) |--Input Device Mouse[1] (**) |--Input Device Mouse[3] (**) Option ZapWarning on (**) Option AllowMouseOpenFail on (**) Option AIGLX on (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/local does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/PEX does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/latin2/misc does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/latin2/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/latin2/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/latin2/Type1 does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/latin7/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/baekmuk does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/japanese does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/kwintv does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/uni does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/CID does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/ucs/misc does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/ucs/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/ucs/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/hellas/misc does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/hellas/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/hellas/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/hellas/Type1 does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/misc/sgi does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/xtest does not exist. Entry deleted from font path. (==) Including the default font path /usr/share/fonts/misc:unscaled,/usr/share/fonts/TTF/,/usr/share/fonts/OTF,/usr/share/fonts/Type1/,/usr/share/fonts/100dpi:unscaled,/usr/share/fonts/75dpi:unscaled. (**) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/Type1, /usr/share/fonts/URW, /usr/share/fonts/Speedo, /usr/share/fonts/cyrillic, /usr/share/fonts/truetype, /opt/kde3/share/fonts, /usr/share/fonts/misc:unscaled, /usr/share/fonts/TTF/,
Re: libX11-6.2.1 and pkg-config 0.23
Who will fix it up there? Who has git write permission?
How none saw this before me? The original developers did not try configure?
This bugs affects thousands advanced users.
On 2/19/09, Dan Nicholson dbn.li...@gmail.com wrote:
On Thu, Feb 19, 2009 at 12:21 AM, Pedro Izecksohn
pedro.izecks...@gmail.com wrote:
In libX11-6.2.1:
The configure piece below is wrong, (or pkg-config is buggy) because
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
I'm using pkg-config --version 0.23
#
# Find keysymdef.h
#
KEYSYMDEF=
for flag in $XPROTO_CFLAGS; do
echo checking arg $flag
case $KEYSYMDEF in
)
case $flag in
-I*)
dir=`echo $flag | sed 's/^-I//'`
file=$dir/X11/keysymdef.h
echo looking for $file
if test -f $file; then
KEYSYMDEF=$file
fi
;;
esac
;;
esac
done
case $KEYSYMDEF in
)
{ { echo $as_me:$LINENO: error: \Cannot find keysymdef.h\ 5
echo $as_me: error: \Cannot find keysymdef.h\ 2;}
{ (exit 1); exit 1; }; }
;;
esac
Yeah, this seems wrong. What it should do is:
includex11dir=`$PKG_CONFIG --variable=includex11dir xproto`
KEYSYMDEF=$includex11dir/keysymdef.h
test -f $KEYSYMDEF || AC_MSG_ERROR([Cannot find keysymdef.h in
$includex11dir])
Or something like that.
--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
On Thu, Feb 19, 2009 at 10:45 AM, Pedro Izecksohn pedro.izecks...@gmail.com wrote: Who will fix it up there? Who has git write permission? How none saw this before me? The original developers did not try configure? Oh, I just looked in git and it's already been fixed for a while. It should be in libX11-1.1.5. Where did libX11-6.2.1 come from? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
It came from http://xlibs.freedesktop.org/release/ BTW: What is the logic behind xlibs version numbers? On 2/19/09, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Feb 19, 2009 at 10:45 AM, Pedro Izecksohn pedro.izecks...@gmail.com wrote: Who will fix it up there? Who has git write permission? How none saw this before me? The original developers did not try configure? Oh, I just looked in git and it's already been fixed for a while. It should be in libX11-1.1.5. Where did libX11-6.2.1 come from? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
On Thu, Feb 19, 2009 at 10:58 AM, Pedro Izecksohn pedro.izecks...@gmail.com wrote: It came from http://xlibs.freedesktop.org/release/ BTW: What is the logic behind xlibs version numbers? Right, the old xlibs releases. You want the newer xorg releases. You can find them all here: http://xorg.freedesktop.org/releases/ Look under the individual directory to find a specific version. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: openSUSE 11.1 and Intel graphics chip
Maybe try the http://lists.freedesktop.org/mailman/listinfo/intel-gfx list? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[intel 845G/GL] Status of xorg, xf86-video-intel, etc on 845
I've been trying to run the latest xorg components on an i845 for a while now, and I haven't found a good set of component versions + configurations that works well. Here's info on the most recent release + current git versions of stuff. If there's anywhere else I should put this (e.g. individual problems to bugzilla) just say so. For future reference, I run gentoo, and all packages are from either gentoo or the gentoo x11 overlay, except for the kernel, which is either from kernel.org or one of the drm-intel kernels. All the Xorg.0.logs from this are available at http://dolphinling.net/xorglogs/ I would be very happy to help out with any testing/etc for making these work, subject to availability (which is more or less entirely random). Thanks! Components used: xorg-server-1.5.99.903 mesa-7.3 xf86-video-intel-2.6.1 and current git libdrm-2.4.4 with x-v-i-2.6.1 and libdrm current git with x-v-i git kernel-2.6.28-drm-intel from intellinuxgraphics.org and 2.6.29-rc5 Results: 2.6.28-drm-intel: xf86-video-intel-2.6.1: noaccel: works, vt switch problem* + puts monitor in unusable state exa: server does not start (bug 19336) uxa: server starts, missing some fonts, some areas of screen just grey, can't log in noconf: exa xf86-video-intel-git: noaccel: works, vt switch problem* + puts monitor in unusable state (no memory leak) exa: fonts too small on login screen, wrong resolution, some areas not painting, no cursor, vt switch problem, glxgears 5 fps uxa: memory leak*, (there is a cursor) 2.6.29-rc5: xf86-video-intel-2.6.1: noaccel: login screen displays, buttons broken, can't log in, no cursor exa: fonts too small/missing/too large/corrupted; wrong resolution, no cursor, things not drawing sometimes, can log in uxa: same as 2.6.28-drm-intel (maybe even pixel-for-pixel) noconf: fonts too small/missing/corrupted, textarea black, can't log in xf86-video-intel-git: noaccel: no cursor, glxgears broken, memory leak*, vt switch problem* exa: fonts too small, no cursor, wrong resolution, some areas do not paint, glxgears 10fps, memory leak very slow?* vt switch problem* uxa: same as noaccel * memory leak: memory is used used up very fast, especially with firefox. Can make computer unusable in 10 seconds if I'm trying, if I try to keep it working I can use it for maybe a few minutes. free reports almost all the memory as cached. Sometimes, top reported X as using 1G of virtual memory (only virtual); other times it did not. Starts swapping when memory full, but nothing ever crashed from OOM. * vt switch problem: when attempted to switch vts, the screen did not update, but the switch worked. I could log in and make mplayer play music blindly. In the nicer incarnation, a few pixels would change but mostly whatever was displayed would stay. In the worse incarnation, the screen would go black and my monitor's power light would start blinking orange, and the only way to get things to display would be to turn the monitor off, switch back to X, then turn the monitor on again. If turned back on while on a non-X vt it would just keep blinking orange. -- dolphinling http://dolphinling.net/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
Pedro Izecksohn wrote: It came from http://xlibs.freedesktop.org/release/ BTW: What is the logic behind xlibs version numbers? xlibs hasn't been used in many years - it was a brief experiment, long ago abandoned.The libraries that are currently maintained and relased are at: http://xorg.freedesktop.org/releases/individual/lib/ Most of them got version numbers starting at 1.0 when X11R7 split them into individual releases instead of just being released as part of the X11R6 monolithic release. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Intel Graphics question
Hello, I am a coreboot (http://www.coreboot.org) developer working mostly Intel chipsets. Currently I am working an set-top-box with an Intel chipset. I am looking into implementing LVDS and TV-OUT support for various Intel GMCH's for set-top-boxes and possibly laptops starting right from the firmware. I kind of understand how it works but not exactly sure in which order it needs to happen. Could anyone please help me understand or confirm if this is right: 1. All GMCH graphics settings are available through 512k graphics mmio space 2. Current graphics settings are read from graphics mmio space 2. i2c communications is setup through GMCH graphics mmio space 3. LVDS and/or TV-OUT chip is programmed via i2c according to graphic settings read from graphics mmio space 4. DVO port that the LVDS and/or TV-OUT chip is connected to is turned on Did I miss anything else? Thanks in advance to any help you can give me. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
milnser43...@yahoo.com wrote: At the same time important backwards compatability upon which many of our applications depend, have been removed including PEX, Ximage, MIT-SUNDRY, XFree86-Misc, among others creating a massive incompatability headache. A prime principle of the X.org project should be to retain backwards compatability so that older applications may still run. Stop destroying backwards compatability and get around to fixing the memory leaks for god sake. X.org also seems to be intent on locking itself out of the embedded/cell market by removing support for low depth displays. I am throughly dismayed and disgusted with X.org. If this backwards compatibility is causing you such a massive headache, why has it taken you 7 years to complain to us that XFree86 removed PEX XIE support in their 4.2.0 release in 2002, several years before the current X.Org organization was formed and our development tree was forked from their 4.4rc2 release? http://www.xfree86.org/4.2.0/RELNOTES2.html#5 -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Severe memory leaks make X.org unuseable
The resource usage has not changed much after it has been running. Though you are right, I think you are saying that the two 131 mb allocations are not actually real ram usage, but instead are just mappings of the video hardware address space. So basically that is not space consumed in RAM. This seems to be indicated by top command free read while X server is not running and while is: Mem: 221M Active, 33M Inact, 97M Wired, 10M Cache, 56M Buf, 96M Free Swap: 195M Total, 150M Used, 44M Free, 77% Inuse, 80K In Mem: 234M Active, 26M Inact, 111M Wired, 9000K Cache, 56M Buf, 77M Free Swap: 195M Total, 148M Used, 46M Free, 76% Inuse I am sorry about the trouble that this misunderstanding has caused. I am just glad to know that the Xserver is really taking up only 30 mb of ram or so. --- On Thu, 2/19/09, Adam Jackson a...@nwnk.net wrote: From: Adam Jackson a...@nwnk.net Subject: Re: Severe memory leaks make X.org unuseable To: milnser43...@yahoo.com Cc: xorg@lists.freedesktop.org Date: Thursday, February 19, 2009, 6:36 PM On Thu, 2009-02-19 at 07:58 -0800, milnser43...@yahoo.com wrote: 2898 131072 0 - 131072 rwx /dev/mem [...] 30A51000 131072 4 - 131072 rwx /dev/mem [...] Total Kb 277656940862607908 You have what I assume is the card's video memory mapped twice. This is a) not real memory usage, and b) well over 99% of your server's address space. The remaining 15M is positively svelte by comparison. It's likely that this is a freshly launched X server? You probably want to look at resource and memory usage once it's been running a while. - ajax ___ 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
Re: Questions on How Xorg handle ACPI
2009/2/18 Matthew Garrett mj...@srcf.ucam.org On Wed, Feb 18, 2009 at 10:41:31AM +0800, sheldon wrote: I'm trying to find how Xorg handles ACPI (s3 and s4). It seems that Xorg handles S3/S4( suspend and resume) is just the same as it process VT switching, for both the flow is WaitFofSomething( )- WakeUpHandle( ) - xf86Wakeup( ) - xf86VTswitch( ) . Xorg doesn't handle S3/S4. Question 1. Is any different between Xorg handle S3/S4 and VT Switching? No - suspend/resume will typically be implemented by VT switching (see pm-utils or the kernel's own VT switching in kernel/power/main.c) BUT, xf86HandlePMEvents( ) is never called (I'm using Ubuntu8.10, Xorg 1.5.2 *C- a debug version ,compiled by myself). In my system S3/S4 is OK in both console and X. Question 2. I don't know why, Is Xorg don't need to read ACPI Events ? or using some other methods There are no ACPI events that Xorg can usefully respond to directly. They're all passed to userspace which will take appropriate actions. -- Matthew Garrett | mj...@srcf.ucam.org So, vbetool saves and restores the video card state, and the Xorg don't even know a S3/S4 happen? Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Questions on How Xorg handle ACPI
On Fri, Feb 20, 2009 at 09:34:38AM +0800, Sheldon Zhao wrote: So, vbetool saves and restores the video card state, and the Xorg don't even know a S3/S4 happen? Either vbetool or the kernel graphics drivers. X only sees a VT switch. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] 64-bit issues in libx11
It seems xcb/x11 have some bugs related to sizeof(long), in concrete
using 32 bit variables for dpy-request et al in AMD64.
This patch fixes some crashes for me.
diff -ur libx11-1.1.99.2/src/xcb_io.c libx11-1.1.99.2-a/src/xcb_io.c
--- libx11-1.1.99.2/src/xcb_io.c2008-11-04 20:52:54.0 +0100
+++ libx11-1.1.99.2-a/src/xcb_io.c 2009-02-20 02:58:02.0 +0100
@@ -214,7 +214,7 @@
}
else if(req xcb_poll_for_reply(dpy-xcb-connection,
req-sequence, reply, error))
{
- unsigned int sequence = req-sequence;
+ uint64_t sequence = req-sequence;
if(!reply)
{
dpy-xcb-pending_requests = req-next;
@@ -300,7 +300,7 @@
* we need to remember to check later. */
if(dpy-xcb-event_owner != XlibOwnsEventQueue || dpy-async_handlers)
{
- unsigned int sequence;
+ uint64_t sequence;
for(sequence = dpy-xcb-last_flushed; sequence dpy-request;
++sequence)
{
PendingRequest *req = malloc(sizeof(PendingRequest));
I've used uint64_t instead unsigned long as it seems preferred through the
codebase.
Note that both req-sequence and dpy-request are defined as unsigned long.
Regards,
Emilio
pgp6knhbc4LLg.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel Graphics question
On 2009.02.20 07:43:21 +0800, Joseph Smith wrote: Hello, I am a coreboot (http://www.coreboot.org) developer working mostly Intel chipsets. Currently I am working an set-top-box with an Intel chipset. I am looking into implementing LVDS and TV-OUT support for various Intel GMCH's for set-top-boxes and possibly laptops starting right from the firmware. I kind of understand how it works but not exactly sure in which order it needs to happen. Could anyone please help me understand or confirm if this is right: 1. All GMCH graphics settings are available through 512k graphics mmio space 2. Current graphics settings are read from graphics mmio space 2. i2c communications is setup through GMCH graphics mmio space 3. LVDS and/or TV-OUT chip is programmed via i2c according to graphic settings read from graphics mmio space 4. DVO port that the LVDS and/or TV-OUT chip is connected to is turned on Did I miss anything else? Thanks in advance to any help you can give me. MMIO space is where all the modesetting stuffs happen. You can look up xf86-video-intel source for information to setup outputs. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [intel 845G/GL] Status of xorg, xf86-video-intel, etc on 845
dolphinling wrote: All the Xorg.0.logs from this are available at http://dolphinling.net/xorglogs/ Oops, I meant to put my xorg.confs and kernel .configs there too. They're there now. -- dolphinling http://dolphinling.net/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel Graphics question
On Fri, 20 Feb 2009 10:19:49 +0800, Zhenyu Wang zhenyu.z.w...@intel.com wrote: On 2009.02.20 07:43:21 +0800, Joseph Smith wrote: Hello, I am a coreboot (http://www.coreboot.org) developer working mostly Intel chipsets. Currently I am working an set-top-box with an Intel chipset. I am looking into implementing LVDS and TV-OUT support for various Intel GMCH's for set-top-boxes and possibly laptops starting right from the firmware. I kind of understand how it works but not exactly sure in which order it needs to happen. Could anyone please help me understand or confirm if this is right: 1. All GMCH graphics settings are available through 512k graphics mmio space 2. Current graphics settings are read from graphics mmio space 2. i2c communications is setup through GMCH graphics mmio space 3. LVDS and/or TV-OUT chip is programmed via i2c according to graphic settings read from graphics mmio space 4. DVO port that the LVDS and/or TV-OUT chip is connected to is turned on Did I miss anything else? Thanks in advance to any help you can give me. MMIO space is where all the modesetting stuffs happen. You can look up xf86-video-intel source for information to setup outputs. Thanks for the help Zhenyu :-) I have been looking at the source along with other sources like i810tvout-0.9.1, nvtv, and the Intel 815 Chipset: Graphics Controller Programmers Reference Manual. Although this is for a newer chipset than the 815, but that is the only public doc I could find. They all seem to turn on the DVO port at different points, does that matter? Can/should the DVO port be turned on before LVDS and/or TV-OUT chip is programmed or after? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
next release of xineramaproto
Given that last years changes to xineramaproto appear to impact a number of applications (on my system anyway), could anyone tell me when the next release of xineramaproto will occur? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel Graphics question
On Thu, 19 Feb 2009 22:11:37 -0500, Joseph Smith j...@settoplinux.org wrote: On Fri, 20 Feb 2009 10:19:49 +0800, Zhenyu Wang zhenyu.z.w...@intel.com wrote: On 2009.02.20 07:43:21 +0800, Joseph Smith wrote: Hello, I am a coreboot (http://www.coreboot.org) developer working mostly Intel chipsets. Currently I am working an set-top-box with an Intel chipset. I am looking into implementing LVDS and TV-OUT support for various Intel GMCH's for set-top-boxes and possibly laptops starting right from the firmware. I kind of understand how it works but not exactly sure in which order it needs to happen. Could anyone please help me understand or confirm if this is right: 1. All GMCH graphics settings are available through 512k graphics mmio space 2. Current graphics settings are read from graphics mmio space 2. i2c communications is setup through GMCH graphics mmio space 3. LVDS and/or TV-OUT chip is programmed via i2c according to graphic settings read from graphics mmio space 4. DVO port that the LVDS and/or TV-OUT chip is connected to is turned on Did I miss anything else? Thanks in advance to any help you can give me. MMIO space is where all the modesetting stuffs happen. You can look up xf86-video-intel source for information to setup outputs. Thanks for the help Zhenyu :-) I have been looking at the source along with other sources like i810tvout-0.9.1, nvtv, and the Intel 815 Chipset: Graphics Controller Programmers Reference Manual. Although this is for a newer chipset than the 815, but that is the only public doc I could find. They all seem to turn on the DVO port at different points, does that matter? Can/should the DVO port be turned on before LVDS and/or TV-OUT chip is programmed or after? AH, I found this from the Intel 965 Express Chipset Family and Intel G35 Express Chipset Graphics Controller PRM Setting the Mode In general, the TV-Out logic should be programmed before it is enabled. The following steps should be followed. 1. disable the pipe if it is running. 2. set display PLL to the required clock frequency (from the table) 3. make sure that DPO programming is acceptable according to the rules outlined below, change them (and the planes) if needed 4. enable the pipe 5.program all TV-Out registers, then enable TV-Out Exiting the mode is the reverse of these steps. There are no special restrictions on planes used with TV-Out. It is okay to use double wide pixel mode if needed due to low core frequency. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Desktop is not using full screen space
Hi, Need help with the following problem: Desktop is not using full available screen space. The system was working fine in Debian Etch. Then it was upgraded to Debian Lenny. Hardware remains the same, no changes were made. After the upgrade to Lenny, the picture doesn't use the whole available screen space but leaves unused areas about 3-5 cm from the left, right, top and bottom monitor edges. It looks something like this: +1--+ | | | | |+---2-+| || || || || || || |+-+| | | | | +---+ Where 1 is the monitor and 2 is the picture. # aptitude show xorg Package: xorg State: installed Version: 1:7.3+18 Any ideas? Thanks P.S. The output of /usr/share/bug/xserver-xorg/script 31 follows: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2009-02-19 23:49 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1718484 2009-01-08 22:11 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:06.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 2334 2009-02-20 01:22 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true EndSection Section Device Identifier Configured Video Device EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor SubSection Display Depth 1 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1600x1200 1280x1024 1024x768 800x600 640x480 EndSubSection EndSection Xorg X server log files on system: -rw-r- 1 root root 51100 2009-02-20 01:34 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-10) Current Operating System: Linux srv07 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 Build Date: 09 January 2009 02:57:16AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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 Feb 20 01:34:42 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the
