Re: Good afternoon
hi Samuel, i have never heard about virtual gl and it seems that this is more a problem of VirtualGL. i used google to found the mail below may be it can help you. http://www.mail-archive.com/virtualgl-users@lists.sourceforge.net/msg00023.html re, wh Am 09.12.2011 08:48, schrieb Samuel Boateng: > Hello, > I just installed VirtualGL-2.2.90 on my machine which runs on > Centos5.7. After installation I had to test to see if everything was > successful but unfortunately I encountered this error: Xlib: Extension > GLX missing on display 0:0, Error: Couldn't get an RGB Double Buffered > visual. > > I have not found a way out as at now. Could your team please give me > some support? Urgently needed. > > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: x crash and auto log me out
Hi Di Zhang, thx for the report but please be more verbose with your bugreport and give the developer a chance to recreate the circumstances where the bug shows up. E.g. What version of xserver are you running ? (F16=Fedora 16 Beta ?) What graphiccard you are using ? When exactly does it happen ? (e.g. at start, or after login, ...) Are interactions needed ? (like starting a certain program, ... ) hope that helps, wh Am 01.11.2011 02:17, schrieb Di Zhang: > Hello everyone: > > X crash and automatic log me out always happen in my F16 beta, can you give > me some help to solve this problem, because this problem makes me lose a > lot of > work. Below is the error log in the Xorg.o.log.old file: > > 518 [ 37.346] (II) intel(0): Printing DDC gathered Modelines: > 519 [ 37.346] (II) intel(0): Modeline "1600x900"x0.0 110.00 1600 1664 1706 > 2010 900 903 906 912 -hsync -vsync (54.7 kHz) > 520 [ 37.346] (II) intel(0): Modeline "1600x900"x0.0 73.33 1600 1664 1706 > 2010 900 903 906 912 -hsync -vsync (36.5 kHz) > 521 [ 155.044] > 522 Backtrace: > 523 [ 155.044] 0: /usr/bin/Xorg (xorg_backtrace+0x2f) [0x462d8f] > 524 [ 155.045] 1: /usr/bin/Xorg (0x40+0x67b56) [0x467b56] > 525 [ 155.045] 2: /lib64/libpthread.so.0 (0x7f9102d05000+0xf4f0) > [0x7f9102d144f0] > 526 [ 155.045] 3: /usr/lib64/xorg/modules/extensions/librecord.so > (0x7f9101555000+0x26c3) [0x7f91015576c3] > 527 [ 155.045] 4: /usr/bin/Xorg (_CallCallbacks+0x3c) [0x43820c] > 528 [ 155.045] 5: /usr/bin/Xorg (WriteToClient+0x1f5) [0x466315] > 529 [ 155.045] 6: /usr/lib64/xorg/modules/extensions/libdri2.so > (ProcDRI2WaitMSCReply+0x4f) [0x7f9100f3beef] > 530 [ 155.045] 7: /usr/lib64/xorg/modules/extensions/libdri2.so > (DRI2WaitMSCComplete+0x52) [0x7f9100f3a6d2] > 531 [ 155.045] 8: /usr/lib64/xorg/modules/drivers/intel_drv.so > (0x7f9100ce7000+0x25ae4) [0x7f9100d0cae4] > 532 [ 155.045] 9: /usr/lib64/libdrm.so.2 (drmHandleEvent+0xa3) > [0x7f9101145523] > 533 [ 155.045] 10: /usr/bin/Xorg (WakeupHandler+0x6b) [0x4379db] > 534 [ 155.045] 11: /usr/bin/Xorg (WaitForSomething+0x1a9) [0x460289] > 535 [ 155.045] 12: /usr/bin/Xorg (0x40+0x3379a) [0x43379a] > 536 [ 155.045] 13: /usr/bin/Xorg (0x40+0x22dc5) [0x422dc5] > 537 [ 155.045] 14: /lib64/libc.so.6 (__libc_start_main+0xed) > [0x7f91024e569d] > 538 [ 155.045] 15: /usr/bin/Xorg (0x40+0x230b1) [0x4230b1] > 539 [ 155.045] Segmentation fault at address 0x7f90fe161010 > 540 [ 155.045] > 541 Fatal server error: > 542 [ 155.045] Caught signal 11 (Segmentation fault). Server aborting > 543 [ 155.045] > 544 [ 155.045] > 545 Please consult the Fedora Project support > 546 at http://wiki.x.org > 547 for help. > 548 [ 155.045] Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > 549 [ 155.045] > 550 [ 155.051] (II) evdev: Power Button: Close > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: libpciaccess
"undefined reference to" means there is an object file or library missing in the final stage of linking. re, wh Am 22.10.2011 16:13, schrieb Dwijadas Dey: > Hi >list >Able to solve the problem ( > http://lists.freedesktop.org/archives/xorg/2011-October/053700.html > )related to drmsetserverinfo , the problem was in xorg compilation > where i set the location of LIBDRM_CFLAGS and LIBS to an old version > of libdrm (2.0.4), correcting these LIBDRM_CFLAGS and LIBDRM_LIBS > location solves the problem. > > Now i am trying to recompile xorg with libpciaccess but at the last > stage of make command I got the errors which are given below. > > > * > > ./.libs/libxorg.a(xf86Helper.o): In function `xf86MatchPciInstances': > xf86Helper.c:(.text+0x3583): undefined reference to > `pci_slot_match_iterator_create' > xf86Helper.c:(.text+0x3597): undefined reference to `pci_device_next' > xf86Helper.c:(.text+0x35ab): undefined reference to `pci_iterator_destroy' > xf86Helper.c:(.text+0x35ce): undefined reference to > `pci_slot_match_iterator_create' > xf86Helper.c:(.text+0x3805): undefined reference to `pci_device_next' > xf86Helper.c:(.text+0x381d): undefined reference to `pci_iterator_destroy' > ./.libs/libxorg.a(xf86Init.o): In function > `probe_devices_from_device_sections': > xf86Init.c:(.text+0x693): undefined reference to > `pci_id_match_iterator_create' > xf86Init.c:(.text+0x74c): undefined reference to `pci_device_next' > xf86Init.c:(.text+0x764): undefined reference to `pci_iterator_destroy' > ./.libs/libxorg.a(xf86Init.o): In function > `add_matching_devices_to_configure_list': > xf86Init.c:(.text+0xaae): undefined reference to > `pci_id_match_iterator_create' > xf86Init.c:(.text+0xc64): undefined reference to `pci_device_next' > xf86Init.c:(.text+0xc7c): undefined reference to `pci_iterator_destroy' > ./.libs/libxorg.a(xf86Configure.o): In function `bus_pci_newdev_configure': > xf86Configure.c:(.text+0x169): undefined reference to > `pci_device_get_vendor_name' > xf86Configure.c:(.text+0x177): undefined reference to > `pci_device_get_device_name' > ./.libs/libxorg.a(xf86pciBus.o): In function `xf86PciProbe': > xf86pciBus.c:(.text+0xae): undefined reference to > `pci_slot_match_iterator_create' > xf86pciBus.c:(.text+0x147): undefined reference to `pci_device_probe' > xf86pciBus.c:(.text+0x15f): undefined reference to `pci_device_next' > xf86pciBus.c:(.text+0x1cd): undefined reference to `pci_device_cfg_read_u16' > xf86pciBus.c:(.text+0x29d): undefined reference to > `pci_device_get_vendor_name' > xf86pciBus.c:(.text+0x2ab): undefined reference to > `pci_device_get_device_name' > ./.libs/libxorg.a(xf86AutoConfig.o): In function `listPossibleVideoDrivers': > xf86AutoConfig.c:(.text+0xf66): undefined reference to > `pci_slot_match_iterator_create' > xf86AutoConfig.c:(.text+0xf85): undefined reference to `pci_device_next' > xf86AutoConfig.c:(.text+0xf99): undefined reference to `pci_iterator_destroy' > ./.libs/libxorg.a(linuxPci.o): In function `get_parent_bridge': > linuxPci.c:(.text+0x410): undefined reference to > `pci_id_match_iterator_create' > linuxPci.c:(.text+0x43e): undefined reference to `pci_device_get_bridge_info' > linuxPci.c:(.text+0x464): undefined reference to `pci_device_next' > linuxPci.c:(.text+0x478): undefined reference to `pci_iterator_destroy' > ./.libs/libxorg.a(Pci.o): In function `xf86scanpci': > > > ** > > I checked pciaccess.h where each of these definitions are there and it > is included in the include path. > > I want to know from the list, is it a bug related to libpciaccess(0.10.9) ? > > Thanks > Dwdy > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: libxrandr code examples
Did you look at the randr programm source ? re, wh Am 19.10.2011 16:28, schrieb Dirk De Becker: > Hi all, > > I hope this is the right list for this question. I am looking for a good > tutorial on how to use libxrandr from another program. > What I want to do, is for example enabling/disabling certain interfaces > (LVDS/DVI) from a C++ program. > I do not seem to be able to find any good tutorials for this online > (maybe I am not using the good search criteria). > > Anyone who can help me in this? > > Thanks a lot in advance, > > Dirk > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XPutImage stops returning to caller
Am 15.10.2011 06:30, schrieb Phil Hart: > My application calls XPutImage. The target window displays as expected. > However, after some thousands of successful calls, the next call to > XPutImage does not return. A stack trace mentions a mutex. > > The calling parameters do not change, nor indeed the pixels being passed > in. The number of calls seems fairly stable on any given computer, but > changes with between computers. > > Any ideas what might be happening? (For what it is worth, the > application worked flawlessly for millions of calls using a 32-bit > version of Ubuntu.) > > Any help with getting my application to link to libX11-6-dbg would also > be appreciated. (OS: Ubuntu 10.04.3, IDE: Code::Blocks 8.04) > x11perf also supports XPutImage (see man page). Perhaps you can try to replicate that effect. re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Emc vs modern lcd monitors
Am 16.08.2011 16:29, schrieb James Cloos: > Gene, > > If the display gets in the way of the realtime code, you may want to > separate the two. > > It may not be in vogue these days, but running X11 over tcp still works. > Just for your informations in several companies X11 is used for displaying. I used it the most time over tcp, see all the remote extension for X11. The problem are M$ user that have no idea about networking they tend to resort to several rather strange solutions. > An inexpensive laptop, a small fusion or atom box, a plug box will all > make reasonable graphics nodes. Hint: There is a small trap, you need to conf you XDM (or what you use) on the host to allow remote access. now you start on your notebook X -query if everything works fine you will see the XDM from the host. re, wh > If you boot the realtime box into text mode the display shouldn't get in > the way. And you can always switch the monitor and keyboard over should > there be any problems booting. > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Solved] Re: How to set default window size for xconsole app ?
Am 12.08.2011 08:35, schrieb Aaron Lewis: > On 2011年08月12日 14:27, Glynn Clements wrote: >> >> Aaron Lewis wrote: >>> Hi , >> >>> i wanted to setup default window size for xconsole program , >>> although i'm on openbox , but still wanted to use Xdefaults file , >>> but how ? >> >> XConsole.width: 640 >> XConsole.height: 480 >> > > This works , thanks for the response > Also another solution from another mail , > > xconsole.geometry: 1280x350+0+400 > did someome mention: xconsole -xrm "XConsole.width: 640" or xrdb -merge "file with xconsole resources" just for completeness. re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to set Background Image on X
Am 03.08.2011 13:20, schrieb vishnu jagadish: > Hi All, > > We successfully ported Angstrom on Devkit8000 with Kernel > Linux-2.6.37-rc2-ge53beac. After booting up we have a white background in > X-screen. I want to set a background image for the X-screen. Is it > possible?? > > I tried with feh ( a fast and light Imlib2-based image viewer). I compiled > and put feh-1.14.2 and imlib2-1.4.4. feh is having background setting > option. But when running feh it throwing error as shown below. Please help > me resolve this issue. Thanks in Advance. > > *# feh --bg-scale photos/photo0056.jpg > * > *feh WARNING: photos/photo0056.jpg - No Imlib2 loader for that file format > feh ERROR: Couldn't load image in order to set bg* > * did you try xsetroot or xpmroot or xv ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] libXrandr 1.3.2
hi, just a minor request: is it possible to have xrandr the same version number as libxrandr ? It is a bit confusing to have xrandr 1.3.5 but libxrandr 1.3.2. re, wh Am 30.06.2011 06:56, schrieb Alan Coopersmith: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > libXrandr is the libX11-based library for the X Resize, Rotate and > Reflection (RandR and don't ask where the third R went) extension. > > This minor maintenance release mainly makes the man pages less sucky. > The build configuration was also made to suck a little less too. > > Alan Coopersmith (1): > libXrandr 1.3.2 > > Cyril Brulebois (9): > Xrandr.man: Remove trailing spaces. > Xrandr.man: Fix grammar. > Xrandr.man: Build full sentences, possibly easier to read. > Xrandr.man: Try to make some sense. > Xrandr.man: Fix typo. > Xrandr.man: Build full sentences for easier reading. > Xrandr.man: Fix missing closing parenthesis. > Xrandr.man: Fix parenthesis escaping. > Xrandr.man: Document how to request notifications. > > Gaetan Nadon (4): > config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 > config: remove unrequired AC_CONFIG_AUX_DIR > config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS > config: comment, minor upgrade, quote and layout configure.ac > > git tag: libXrandr-1.3.2 > > http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.3.2.tar.bz2 > MD5: 92473da2fccf5fac665be4fa4f2037fa > SHA1: 0c844a4c5237f96794f0c18a5af16dc5ab7a36ec > > http://xorg.freedesktop.org/archive/individual/lib/libXrandr-1.3.2.tar.gz > MD5: edacf83655be2e48348b626c0dc454f3 > SHA1: 74d90555bf0772e25a5228c8dbad9d43fdd35b4f > > > - -- > -Alan Coopersmith-alan.coopersm...@oracle.com >Oracle Solaris Platform Engineering: X Window System > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (SunOS) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4MAhoACgkQovueCB8tEw4pfwCfcHTGD0iDp/LKPKi1SH4cssYM > Kh0An123J/kpVIKFxyE2eIL/SsvWMU0E > =96M/ > -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 > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Desktop managers that work in multiseat mode
Am 17.06.2011 08:31, schrieb Zoltan Szecsei: > On 2011/06/15 18:07, walter harms wrote: >> are you aware of this artikel ? >> http://www.x.org/wiki/Development/Documentation/Multiseat > > No - but I am now :-) > > Thank you, > Zoltan when you still have problems it would be nice to get some feedback :) re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Desktop managers that work in multiseat mode
are you aware of this artikel ? http://www.x.org/wiki/Development/Documentation/Multiseat Am 15.06.2011 11:41, schrieb Zoltan Szecsei: > multiseat mode ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Qery on Xlib project idea on summer of code page
Am 14.06.2011 18:52, schrieb nijil yes: > Hi, > I am interested in working on the idea mentioned on summer of code page on > replacing CMS code inside libX11 with libXcm.I would be glad to get a few > more > details on the work involved and such things.If there is anyone already > assigned > for the project as a mentor or if anyone is interested in mentoring that one > please reply.I have asked in the irc channel on this but dint receive any > replies.Also if there is anyone who has already/is working on this, I would > be > glad if you could help me out to get started.If you could mention the irc > nick I > will ping you back in the channel. > > cheers, > Nijil. > Hello Nijil, the old code in libX11 is a bit fragil. nicely Kai-Uwe Behrmann provided an libXcm some time ago. IMHO you need to evaluate: * can libXcm map Xcms calls ? * is Xcms.txt compartibel ? * testsetup for Xcm for detail on libXcm you should contact Kai-Uwe Behrmann re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Qery on Xlib project idea on summer of code page
Am 14.06.2011 18:52, schrieb nijil yes: > Hi, > I am interested in working on the idea mentioned on summer of code page on > replacing CMS code inside libX11 with libXcm.I would be glad to get a few > more > details on the work involved and such things.If there is anyone already > assigned > for the project as a mentor or if anyone is interested in mentoring that one > please reply.I have asked in the irc channel on this but dint receive any > replies.Also if there is anyone who has already/is working on this, I would > be > glad if you could help me out to get started.If you could mention the irc > nick I > will ping you back in the channel. > > cheers, > Nijil. > Hello Nijil, the old code in libX11 is a bit fragil. nicely Kai-Uwe Behrmann provided an libXcm some time ago. IMHO you need to evaluate: * can libXcm map Xcms calls ? * is Xcms.txt compartibel ? * testsetup for Xcm for detail on libXcm you should contact Kai-Uwe Behrmann re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: arious x apps (xterm, xfontsel) don't start due to missing fonts
does "xterm -fn fixed" work ? re, wh Am 24.03.2011 22:19, schrieb Shiva Persaud: > Hi folks, > > I'm having what appears to be a common problem but not of the solutions I've > found on various forums and threads have worked for me. > > I noticed this issue after I configured my system to use the en_US.utf8 > locale but it's possible that this issue existed before that change. Note > that in debugging I've gone back to using having POSIX as my locale and the > problem persists. > > I noticed then when I did a ctrl-right click xterm windows would close. I > started an xterm from an xterm and ctrl-right clicked on the new xterm and > saw the following error message: > > > ~(245)$ xterm > Warning: Cannot convert string > "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type FontStruct > Warning: Unable to load any usable ISO8859 font > Warning: Unable to load any usable ISO8859 font > Error: Aborting: no font found > > > I see the following with trying to launch xfontsel: > > > $ xfontsel > Warning: Unable to load any usable ISO8859 font > Warning: Missing charsets in String to FontSet conversion > Warning: Unable to load any usable fontset > Error: Aborting: no font found > > > xclock starts but it prints the following: > > > $ xclock > Warning: Unable to load any usable ISO8859 font > ^C > $ > > > I've found, and tried, the following suggestions with no luck: > > 1. Ensured that media-fonts/font-misc-misc is installed. > 2. Ensured that the FontPath is set is /etc/X11/xorg.conf. > > Other details like which versions of various X components I have installed > and "xset q fp" output can be found in a distro bug opened: > http://bugs.gentoo.org/show_bug.cgi?id=359679. Please note that in Googling > around I've found that users on other distros have experienced this issue. > I've attached "strace editres" output @ > http://bugs.gentoo.org/attachment.cgi?id=266879. > > Any suggestions on how to address this would be much appreciated. > > Thanks! > > > > > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xlib and rotated text?
Am 17.03.2011 20:30, schrieb Peter Harris: > On 2011-03-17 13:52, Chris wrote: >> I've had a look at freetype, but it seems like overkill for what I >> need and also a dependency I'm not sure I can "afford" (and it seems >> that then I also need fontconfig). So this is a last resort for me. > > You want to use ciaro/pango/fontconfig/freetype for this, rather than > re-inventing the wheel. > >> So, can I do it in Xlib without writing the complete matric algebra >> by myself (if so, where can I find an example/manual/tutorial), > > If you really really want to use as few libraries as possible, you could > draw your text onto a pixmap, then rotate it to your window using > XRenderSetPictureTransform and XRenderComposite. > > http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt#n705 > > http://cgit.freedesktop.org/xorg/lib/libXrender/tree/include/X11/extensions/Xrender.h#n267 > are there any man pages available ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Performance issues with XDefineCursor and XtAddTimeOut
Am 04.03.2011 14:52, schrieb Guy Léonis: > Hello, > > I went through all FAQ and Archives without being able to find anything about > my performances issues. > I apologize in case I did my searches the wrong way. > If you need more information on my side, I will do my best to provide you > with the requested files and logs. > Issue 2 (info): > === > In the frame of the same application, there are 2 threads. The first thread, > which is totally free of X calls, manages a PCMCIA MIL-1553-STD bus card and > stores uploaded data. The second thread, which gather all X calls, displays > uploaded data. The X thread polls the data buffer every millisecond thanks to > XtAddTimeOut(1,...). > On the old A31P, this was perfect (no performance issue, CPU use of 0.1% or > so). To be honest, the TO callback was actually activated only every 10 > milliseconds. > On the T61p with RHEL or FC14, this is not nice. This time, the TO callback > is activated every millisecond but the X thread consume 100% of the CPU time > provided by one core. > I have used XtAddTimeOut(10,...) instead, and the CPU load goes down to ~4% > without visible impact at user level. This is a fine work around for our > application. > In any cases (i.e. any CPU load), this is not a true problem, the X thread > being fully responsive to user actions, display updates and (fixed) cursor > moves. By the way, 100%, 4% or even a lower CPU load doesn't impact the > cursor issue (see Issue 1). > I have attached a minimum code example to evidence the issue (usage: xtoperfo > #loop interval), together with files created by gprof under FC14 showing that > each call to XtAddTimeOut generates about 150 loops within XtMainLoop > (shorter interval means more loops!). See attached fc14.xtoperfo*log files as > examples (1 loops with both 1 and 10 ms intervals). > It should be possible to suppress much of this overhead (e.g. see RHEL 3.0 > implementation) and then to avoid having a 100% CPU load. > > hi, did some tests with your programm on my desktop an it seems to work as expected. I made my own version and i get compareable results (code attached). How do you monitor cpuload ? the linux kernel has changed in the last versions (e.g. tickless) and this will result in different measures. that you see 100% cpu utilisation may simply down to better measurements. When i run my test several times i used /usr/bin/time to measure execution time and that behaves as expected. re, wh xtoperfo2 Description: Binary data ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Longstanding bug in ... XtAppMainLoop?
Hello,
when starting a Xt-Application you should use XtOpenApplication() or
XtAppInitialize()
they will call XOpenDisplay().
I read the paper but i am not sure is the programm without display of any use ?
or is
it a sample that simply shows the limitation of the model ?
I am not deeply in Xt and have no real clue what that change will bring an
benefitz
since the programms i know will terminate if the display will not exists.
re,
wh
Am 24.02.2011 16:42, schrieb Jordan Hayes:
>> when do application do not have a display ?
>
> Xt is also a powerful general purpose environment for event-driven
> programming. Input events, timers, now signals ... all handled pretty
> well. Originally the big drawback was that XtAppMainLoop would *never*
> return, but this ExitFlag stuff appears to be an attempt to allow it. I
> also think it should return when there's no chance of ever getting
> another event: if there's no display, no input sources are defined, no
> signals are being watched, and no timers are set. Someday I'll see if I
> can come up with a patch for that, but in the mean time changing the
> main loop would be a good thing.
>
> Here's some code that shows the problem:
>
> #include
>
> static void _Tick(XtPointer baton, XtIntervalId* id) {
>static int count = 0;
>
>printf("%d beep!\n", ++count);
>
>XtAppContext app = (XtAppContext)baton;
>if (3 == count)
>XtAppSetExitFlag(app);
>else
>XtAppAddTimeOut(app, 3000, _Tick, app);
> }
>
> int main(int argc, char** argv) {
>XtToolkitInitialize();
>XtAppContext app = XtCreateApplicationContext();
>XtAppAddTimeOut(app, 3000, _Tick, app);
>
> #ifdefSHOWBUG
>XtAppMainLoop(app);
> #else
>for (;;) {
>XtAppProcessEvent(app, XtIMAll);
>if (XtAppGetExitFlag(app))
>break;
>}
> #endif
>
>return 0;
> }
>
> I wrote this paper nearly 20 years ago about it :-)
>
> http://bitway.com/jordan/papers/USENIX/AppDev.html
>
> /jordan
> ___
> xorg@lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: wha...@bfs.de
>
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Longstanding bug in ... XtAppMainLoop?
this sounds reasonable,
but when do application do not have a display ?
re,
wh
Am 24.02.2011 00:09, schrieb Jordan Hayes:
> The manual page for XtAppMainLoop says that it's just a simple loop that
> calls
>
> XEvent event;
> XtAppNextEvent(app, &event);
> XtDispatchEvent(&event);
>
> ... until XtAppGetExitFlag() returns true.
>
> And looking at the code in libXt-1.0.9/src/Event.c seems to show that to
> be the case.
>
> But: XtAppNextEvent() doesn't return until there's an actual XEvent to
> be handled; it handles Xt-internal events (inputs, timers, signals)
> itself, but doesn't return (because of course, those aren't XEvents).
> Which means that the exit flag doesn't get a chance to break the loop
> until/unless there's an actual XEvent.
>
> If you're not using a Display at all in your app, you lose: timers or
> input sources can't signal the main loop to exit using this mechanism.
>
> A workaround -- and what I would suggest XtAppMainLoop be fixed to do
> instead -- is code that looks more like this:
>
>for (;;) {
>XtAppProcessEvent(app, XtIMAll);
>if (XtAppGetExitFlag(app))
>break;
>}
>
> XtAppProcessEvent() returns when *any* event has been dispatched, not
> just ones that involve a Display. For the source tree, it would look
> something like this:
>
> void XtAppMainLoop(XtAppContext app) {
>LOCK_APP(app);
>do {
>XtAppProcessEvent(app, XtIMAll);
>} while (! app->exit_flag);
>UNLOCK_APP(app);
> }
>
> I guess I'm the only one who uses Xt this way?
>
> Thanks,
>
> /jordan
> ___
> xorg@lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: wha...@bfs.de
>
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: [PATCH] Replace malloc with calloc to initialize the buffers[] as NULL in do_get_buffers function
Am 10.02.2011 22:27, schrieb Kristian Høgsberg:
> From: Justin Dou
>
> The calling for allocate_or_reuse_buffer may fail due to some reason, e.g.
> out of memory.
> If the buffers[] were not initialized to be NULL, the following err_out may
> try to access an illegal memory, which will cause X crash afterward.
>
> Reviewed-by: Kristian Høgsberg
> Signed-off-by: Justin Dou
> ---
> hw/xfree86/dri2/dri2.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
> index 34f735f..5d31e77 100644
> --- a/hw/xfree86/dri2/dri2.c
> +++ b/hw/xfree86/dri2/dri2.c
> @@ -403,7 +403,7 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height,
> && (pDraw->height == pPriv->height)
> && (pPriv->serialNumber == DRI2DrawableSerial(pDraw));
>
> -buffers = malloc((count + 1) * sizeof(buffers[0]));
> +buffers = calloc((count + 1), sizeof(buffers[0]));
>
> for (i = 0; i < count; i++) {
> const unsigned attachment = *(attachments++);
may be i am pessimistic but what happen when you run OOM ?
according to the note above i expected something like:
if ( buffers == NULL ) exit(1);
(or what ever you do in OOM conditions)
re,
wh
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: XGContextFromGC manual page
the linux man-page project has a man-page called. It may be helpful to add such a page here also. re, wh Am 17.01.2011 16:55, schrieb Krzysztof Żelechowski: > XGContextFromGC is not described in its manual page. It is described only in > the libX11 book. > > Please fix, > Chris > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: HTML colouring in xedit
Am 12.01.2011 09:26, schrieb Alan Coopersmith: > On 01/11/11 11:19 AM, Krzysztof Żelechowski wrote: >> The manual page for *xedit* does not say how to switch syntax colouring off >> and the display for *HTML* is awful. The font used for /code/ is smaller >> than the font used for /text/ , to the point of being unreadable, and using >> a variable-spaced font does not help either. A partial workaround is to >> switch the editor to *SGML* mode. >> >> Please fix, > > The previous maintainer for xedit is no longer involved in X.Org, > and we were not aware anyone other than him actually used xedit. > > Please find a new editor or help find a new maintainer if you want > to see it fixed. > a simple grep ":font" *lsp shows various fonts involved. It should be easy to reduce the number of required fonts and profide fonts that come with the std. font package. re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: simple X window program not compile, plz help
Hi Eric,
you should take a look at the "Motif_Programming_Manual_6a".
make you self familar with the names like "toolkit","widget" etc, and try to
understand
what that means. IMHO most problems occur because ppl do not understand what it
actualy
means.
Do not forget to install all the required -dev packages. When you can not find
a "*.h" file
normaly you are missing one.
BTW: Going with Xt has some advantages because they do not change every year,
they do not
need a special browser, and most bugs are fixed since they are in use for
years.
that is what some people (and companies) are looking for.
re,
wh
eric lin schrieb:
> dear Alan or any x window user/programers:
>
> it compile success by your last suggestion
> but when I run it,
> Segmentation fault (anyone can tell me why?)(that book's code actually is
> already illegal on my system's x window grammer, plus
> I have hard time to figure it out what that book's
> authors's explanation. But I won't abondon it in short time.)
> that book is really pretty unorganized, especially code in ununiform. But
> that is so far I can get most approach to X on linux, which is I borrow from
> Los Angeles's central city library at downtown. I also see another book,
> "Motif", in that library also doing graphic on Unix, written by c++. I
> search a little bit on google's motif part, i find a simple c code and I copy
> it and try to compile it on my system, but it not work
> ---
> r...@eric-laptop:/home/eric# gcc try3.c -lXaw -lXt -lX11 -lXm
> try3.c:2:20: error: Xm/Xm.h: No such file or directory
> try3.c:3:22: error: Xm/PushB.h: No such file or directory
> try3.c:8: error: expected ‘)’ before ‘*’ token
> try3.c: In function ‘main’:
> try3.c:13: error: ‘Widget’ undeclared (first use in this function)
> try3.c:13: error: (Each undeclared identifier is reported only once
> try3.c:13: error: for each function it appears in.)
> try3.c:13: error: expected ‘;’ before ‘top_wid’
> try3.c:14: error: ‘XtAppContext’ undeclared (first use in this function)
> try3.c:14: error: expected ‘;’ before ‘app’
> try3.c:16: error: ‘top_wid’ undeclared (first use in this function)
> try3.c:16: error: ‘app’ undeclared (first use in this function)
> try3.c:16: error: ‘NULL’ undeclared (first use in this function)
> try3.c:19: error: ‘button’ undeclared (first use in this function)
> try3.c:25: error: ‘XmNactivateCallback’ undeclared (first use in this
> function)
> try3.c:25: error: ‘pushed_fn’ undeclared (first use in this function)
> try3.c: At top level:
> try3.c:32: error: expected ‘)’ before ‘w’
> r...@eric-laptop:/home/eric# cat try3.c
>
> #include
> #include
>
> /* Prototype Callback function */
>
> void pushed_fn(Widget , XtPointer ,
>XmPushButtonCallbackStruct *);
>
>
> main(int argc, char **argv)
>
> { Widget top_wid, button;
> XtAppContext app;
>
> top_wid = XtVaAppInitialize(&app, "Push", NULL, 0,
> &argc, argv, NULL, NULL);
>
> button = XmCreatePushButton(top_wid, "Push_me", NULL, 0);
>
> /* tell Xt to manage button */
> XtManageChild(button);
>
> /* attach fn to widget */
> XtAddCallback(button, XmNactivateCallback, pushed_fn, NULL);
>
> XtRealizeWidget(top_wid); /* display widget hierarchy */
> XtAppMainLoop(app); /* enter processing loop */
>
> }
>
> void pushed_fn(Widget w, XtPointer client_data,
>XmPushButtonCallbackStruct *cbs)
> {
> printf("Don't Push Me!!\n");
> }
>
> -
> so if anyone know how to make it compile, I will be highly appreciate and I
> am glad to borrow that Motif book from my citi library again.
> plz help
> and
> thx your time and effort and patience, Eric, fs...@luxmail.com
>
> ///
> -
>
> --- alan.coopersm...@oracle.com wrote:
>
> From: Alan Coopersmith
> To: fs...@luxmail.com
> CC: xorg@lists.freedesktop.org
> Subject: Re: simple X window program not compile, plz help
> Date: Sun, 31 Oct 2010 20:24:36 -0700
>
> eric lin wrote:
>> Dear X window advanced programers:
>>
>> on my ubuntu/linux, I tried a simple x window program by c
>> as following:
>>
>> ---
>>
>> #include
>> #include
>> #include /* for creation routines */
>> #include /* for resource names */
>> #include /* to define the formWidgetClass */
>>
>> int main()
>> {
>>XtAppContext appContext;
>>Widget toplevel, form;
>>
>>toplevel = XtVaAppInitialize( &appContext,
>> "2D-Editor", /* Application class name */
>> NULL, 0, /* option list (not used)
>> &argc, argv, /* command line parameters */
[PATCH libXt] fix NULL check
_XtGetPerWidgetInput may return NULL
avoid possible NULL references
Signed-off-by: walter harms
---
src/Keyboard.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/Keyboard.c b/src/Keyboard.c
index 9c8065b..ef27399 100644
--- a/src/Keyboard.c
+++ b/src/Keyboard.c
@@ -727,18 +727,21 @@ static void QueryEventMask(
*/
Widget ancestor = (Widget)client_data;
XtPerWidgetInput pwi = _XtGetPerWidgetInput(ancestor, FALSE);
-Widget target = pwi->queryEventDescendant;
-/* use of 'target' is non-standard hackery; allows focus to non-widget */
-if (pwi && (pwi->focusKid == target)) {
+if (pwi) {
+ Widget target = pwi->queryEventDescendant;
+
+ /* use of 'target' is non-standard hackery; allows focus to non-widget */
+ if ( pwi->focusKid == target ) {
AddFocusHandler(ancestor, target, pwi,
_XtGetPerWidgetInput(GetShell(ancestor), TRUE),
_XtGetPerDisplayInput(XtDisplay(ancestor)),
(EventMask)0);
+ }
+ XtRemoveEventHandler(widget, XtAllEvents, True,
+ QueryEventMask, client_data);
+ pwi->map_handler_added = FALSE;
}
-XtRemoveEventHandler(widget, XtAllEvents, True,
-QueryEventMask, client_data);
-pwi->map_handler_added = FALSE;
}
--
1.6.0.2
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[PATCH libXt] Fix possible NULL access
Fix possible NULL access
Signed-off-by: walter harms
---
src/Resources.c |3 +++
src/TMparse.c | 18 ++
src/TMstate.c | 11 +++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/src/Resources.c b/src/Resources.c
index 1cb37d4..9230169 100644
--- a/src/Resources.c
+++ b/src/Resources.c
@@ -967,8 +967,11 @@ static XtCacheRef *GetResources(
if (cache_ptr && *cache_ptr)
cache_ptr++;
} else {
+ // value.addr can be NULL see: !already_copied
+ if (value.addr)
*((XtTranslations *)&widget->core.tm.current_state) =
*((XtTranslations *)value.addr);
+
}
}
}
diff --git a/src/TMparse.c b/src/TMparse.c
index 5fddb82..5930187 100644
--- a/src/TMparse.c
+++ b/src/TMparse.c
@@ -1288,10 +1288,15 @@ static void RepeatDownPlus(
*event = timerEventRec;
}
-
+/*
+ if reps==0 -> lastDownEvent == NULL
+*/
event->next = lastDownEvent;
*eventP = event;
-*actionsP = &lastDownEvent->actions;
+if (lastDownEvent)
+ *actionsP = &lastDownEvent->actions;
+else
+ *actionsP = NULL ;
}
static void RepeatUp(
@@ -1395,10 +1400,15 @@ static void RepeatUpPlus(
*event = *downEvent;
}
-
+/*
+ if reps==0 -> lastUpEvent == NULL
+*/
event->next = lastUpEvent;
*eventP = event;
-*actionsP = &lastUpEvent->actions;
+if (lastUpEvent)
+ *actionsP = &lastUpEvent->actions;
+else
+ *actionsP = NULL ;
}
static void RepeatOther(
diff --git a/src/TMstate.c b/src/TMstate.c
index 4a634b4..843292c 100644
--- a/src/TMstate.c
+++ b/src/TMstate.c
@@ -717,10 +717,13 @@ static void PushContext(
XtRealloc((char *)context->matches,
context->maxMatches * sizeof(MatchPairRec));
}
- context->matches[context->numMatches].isCycleStart =
newState->isCycleStart;
- context->matches[context->numMatches].isCycleEnd =
newState->isCycleEnd;
- context->matches[context->numMatches].typeIndex = newState->typeIndex;
- context->matches[context->numMatches++].modIndex = newState->modIndex;
+ if ( context->matches )
+ {
+ context->matches[context->numMatches].isCycleStart =
newState->isCycleStart;
+ context->matches[context->numMatches].isCycleEnd =
newState->isCycleEnd;
+ context->matches[context->numMatches].typeIndex =
newState->typeIndex;
+ context->matches[context->numMatches++].modIndex =
newState->modIndex;
+ }
*contextPtr = context;
}
UNLOCK_PROCESS;
--
1.6.0.2
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: X under valgrind?
Jeremy Huddleston schrieb: > I have a bunch of reports of this on version 1.4.2-apple53 as well (which > cherry picked changes to support the new libXfont), so it probably reduces > down to something in those change which were cherry picked. That's not much > help, but it looks like it probably landed in late 2008 or early 2009... > > 30 libSystem.B.dylib: usleep$NOCANCEL + 0 > 36 libSystem.B.dylib: __semwait_signal_nocancel + 10 > 36 libSystem.B.dylib: nanosleep$NOCANCEL + 129 > 36 libSystem.B.dylib: usleep$NOCANCEL + 57 > 66 libSystem.B.dylib: abort + 93 > 66 libSystem.B.dylib: free + 128 > ==> 66 libXfont.1.dylib: FontFileFreeEntry + 107 <== > 66 libXfont.1.dylib: FontFileFreeTable + 36 > 66 libXfont.1.dylib: FontFileFreeDir + 21 > 66 libXfont.1.dylib: FontFileFreeFPE + 26 > 66 X11.bin: FreeFPE + 43 > 66 X11.bin: FreeFontPath + 101 > 66 X11.bin: FreeFonts + 55 > 66 X11.bin: dix_main + 1486 > 66 X11.bin: server_thread + 50 > 66 libSystem.B.dylib: _pthread_start + 331 > 66 libSystem.B.dylib: thread_start + 13 > > > Application Specific Information: > abort() called > X.Org X Server 1.4.2-apple53 Build Date: 20100211 > > > On Oct 20, 2010, at 13:11, Nix wrote: > >> I'm trying to track down a strange bug in X 1.9.0.901 (and probably .902 >> as well), whereby after a suspend/resume cycle long enough to time out >> nonlocal TCP connections, my X server crashes the first time I map an >> XEmacs window (probably 'the first thing that uses core fonts at all') >> with this unhelpful backtrace: >> >> Backtrace: >> 0: X (xorg_backtrace+0x28) [0x49b7d8] >> 1: X (0x40+0x5dde9) [0x45dde9] >> 2: /lib/libpthread.so.0 (0x7f50fc27f000+0xe9b0) [0x7f50fc28d9b0] >> 3: /lib/libc.so.6 (0x7f50fb1f3000+0x731c0) [0x7f50fb2661c0] >> 4: /lib/libc.so.6 (cfree+0x6c) [0x7f50fb269abc] >> 5: /usr/lib/libXfont.so.1 (FontFileFreeEntry+0x8f) [0x7f50fbdf12ef] >> 6: /usr/lib/libXfont.so.1 (FontFileFreeTable+0x2e) [0x7f50fbdf136e] >> 7: /usr/lib/libXfont.so.1 (FontFileFreeDir+0xd) [0x7f50fbdf139d] >> 8: /usr/lib/libXfont.so.1 (FontFileFreeFPE+0x12) [0x7f50fbdf4692] >> 9: X (0x40+0x2d04b) [0x42d04b] >> 10: X (0x40+0x2fa8b) [0x42fa8b] >> 11: X (ProcessWorkQueue+0x21) [0x4307e1] >> 12: X (WaitForSomething+0x82) [0x456f72] >> 13: X (0x40+0x2bf92) [0x42bf92] >> 14: X (0x40+0x209ee) [0x4209ee] >> 15: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f50fb211d6d] >> 16: X (0x40+0x205a9) [0x4205a9] >> Segmentation fault at address 0x0241b148 >> >> gdb is not much more helpful (I mean, yes, obviously we have a >> double-free(), but why? something to do with the font server I've got at >> the end of the font path specifically to trip bitrot like this, I >> suppose), so I'm planning to valgrind it... but I'm a bit chary of that >> because the last time I valground the X server, horrible disasters >> resulted which ended in a system lockup and massive filesystem >> corruption. Of course, that was before the era of KMS: perhaps things >> are better now that X hardly touches the hardware. >> >> So... has anyone ever valground the X server? Does it work? (Of course >> it will be slow. I'm expecting *that*.) can you see what is freed ? perhaps you can grep the code to see if that is used somewhere else, then setting the variable there to NULL. If this is not happening with X 1.9.0. <901 the most easy way is to use git-biset. hope that helps, re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: libXi-1.3.2: SIGBUS in ParseClassInfo on sparc/64 bit
Julien Cristau schrieb: > On Thu, Oct 14, 2010 at 13:23:01 +0200, Nicolai Stange wrote: > >> Hi everybody, >> >> I've got a SIGBUS on sparc/64 bit in ParseClassInfo here: >> XListDev.c:126: B->class = ButtonClass; >> >> the reason is that B->class is an XID which is unsigned long which >> is 8byte here. >> B points to an address not divisible by eight because there have >> been some XAxisInfo's put before it in the *Any-Storage (in previous >> iterations of the same loop). >> sizeof(XAxisInfo)=3*sizeof(int) = 0x0C and thus, it breaks the >> alignment at some point in *Any. >> >> A quick fix that works here is to replace >> int resolution >> by >> long resolution >> in struct _XAxisInfo, XInput.h:809 >> > That would break ABI, though, so we can't do that... I think we should > make sure the length field of a XAnyClassInfo is a multiple of > sizeof(XID). > perhaps an __attribute__ ((aligned (8))) will help ? can you test it with a small sample programm ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
re:patch:libXt-1.0.8 fix possible NULL access
hi i got no feedback for my patch could you please take a look ? subject: patch:libXt-1.0.8 fix possible NULL access re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Info about X-architecture
vijay singh schrieb: > On Mon, 2010-10-04 at 13:11 +0300, Timo Juhani Lindfors wrote: >> vijay singh writes: >>> I would like to know is their any document available which will explain >>> about X-architecture. >> Even just http://en.wikipedia.org/wiki/X_Window_System gives a rough >> overview. >> >>> if i want to add any new X-client then what is the way. >> Things like evolution and firefox usually work as X clients on >> gnu/linux. You can take a look at them or google for "GTK hello world" >> or "QT hello world" to get something simpler. >> > Thanks for the info.. > > If i want to build test filesystem for new HW (In my case it is > ARM11)where some basics X-client (xterm,xeyes..) should work, in this > case how i should configure X to work. > > If more details about what all kernel dependency, how X can be test will > be helpful. > > > This is a bold goal, what you need is a driver for you particular chipset. IMHO the most easy way to start is to setup a framebuffer (see: man xvfb). this way you can use X11 from remote and you are sure that the related libs are working. Then you may need an driver for your particular hardware, see other how the other driver work and you are next to ready. later you may want to add the driver to the linux kernel to make use of the KMS infrastructure, see related information LKML. good luck, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xcmsdb 1.0.3
Kai-Uwe Behrmann schrieb: > Am 23.09.10, 19:15 -0700 schrieb Alan Coopersmith: >> xcmsdb is used to load, query, or remove Device Color Characterization >> data stored in properties on the root window of the screen as >> specified in section 7, Device Color Characterization, of the >> X11 Inter-Client Communication Conventions Manual (ICCCM). > > Curious asking, who uses xcmsdb? > the programm or the underlying system ? Xcms.txt is the only way to define colornames like "myfancycolor" since rgb.txt is gone. re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch: libXt-1.0.8 fix possible array overflow
Pat Kane schrieb: > In the original code if 'i' is equal to 10 then the line >(void) memmove((char*)par, (char*)params, i * sizeof(String) ); > moves ten things, which is okay. > > The next line: >bzero( &par[i], (10-i) * sizeof(String) ); > moves zero things to a bad address, which is probably okay, > but I bet some code checker would complain. > > The code is very ugly. > yes, i can fix that too but i still feel that i=10 bzero( &par[i], (10-i) * sizeof(String) ); setting the limit to i=9 would fix that. most maintainers prefer 1 fix 1 patch, i can send a revisited patch re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch: libXt-1.0.8 fix possible array overflow
Barry Scott schrieb: > On Wednesday 22 September 2010 08:18:21 walter harms wrote: >> hi List, >> the code checks the upperlimit to 10 while the upperlimit is actualy 9. > > You could use "(sizeof( par )/sizeof( String ))-1" to make the code robust > aginst > a change to the size of par. > yep, i could use XtNumber(), personally i prefer i%=10; par=Xtmalloc(i*sizeof(String)); but i wanted to fix the overflow first. the point i to not understand what do they copy the pointer at all ? they could yjust do the fprintf() and ready .. re, wh and change to printf below into a loop > Barry > >> re, >> wh >> >> >> --- libXt-1.0.8/src/Error.c.org 2010-09-21 23:23:00.0 +0200 >> +++ libXt-1.0.8/src/Error.c 2010-09-21 23:24:03.0 +0200 >> @@ -257,7 +257,7 @@ >> */ >> Cardinal i = *num_params; >> String par[10]; >> - if (i > 10) i = 10; >> + if (i > 9) i = 9; >> (void) memmove((char*)par, (char*)params, i * sizeof(String) ); >> bzero( &par[i], (10-i) * sizeof(String) ); >> (void) fprintf (stderr, "%s%s", >> @@ -292,7 +292,7 @@ >> */ >> Cardinal i = *num_params; >> String par[10]; >> - if (i > 10) i = 10; >> + if (i > 9) i = 9; >> (void) memmove((char*)par, (char*)params, i * sizeof(String) ); >> bzero( &par[i], (10-i) * sizeof(String) ); >> if (i != *num_params) >> ___ >> xorg@lists.freedesktop.org: X.Org support >> Archives: http://lists.freedesktop.org/archives/xorg >> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >> Your subscription address: barry.sc...@onelan.co.uk >> >> > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
patch: libXt-1.0.8 fix possible array overflow
hi List, the code checks the upperlimit to 10 while the upperlimit is actualy 9. re, wh --- libXt-1.0.8/src/Error.c.org 2010-09-21 23:23:00.0 +0200 +++ libXt-1.0.8/src/Error.c 2010-09-21 23:24:03.0 +0200 @@ -257,7 +257,7 @@ */ Cardinal i = *num_params; String par[10]; - if (i > 10) i = 10; + if (i > 9) i = 9; (void) memmove((char*)par, (char*)params, i * sizeof(String) ); bzero( &par[i], (10-i) * sizeof(String) ); (void) fprintf (stderr, "%s%s", @@ -292,7 +292,7 @@ */ Cardinal i = *num_params; String par[10]; - if (i > 10) i = 10; + if (i > 9) i = 9; (void) memmove((char*)par, (char*)params, i * sizeof(String) ); bzero( &par[i], (10-i) * sizeof(String) ); if (i != *num_params) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
patch: Xt-1.0.8 fix dereference
Hi List, i found something that looked like a bug in libXt. eventWidget->core.tm.proc_table is used before eventWidget is checked. this patch fixes that. re, wh --- libXt-1.0.8/src/TMprint.c.org 2010-09-21 23:42:08.0 +0200 +++ libXt-1.0.8/src/TMprint.c 2010-09-21 23:44:44.0 +0200 @@ -782,12 +782,16 @@ PrintRec stackPrints[STACKPRINTSIZE]; PrintRec *prints; TMShortCardnumPrints, maxPrints; -TMBindData bindData = (TMBindData) eventWidget->core.tm.proc_table; +TMBindData bindData ; TMComplexBindProcs complexBindProcs; if ((eventWidget == NULL) || - ((xlations = eventWidget->core.tm.translations) == NULL) || - (bindData->simple.isComplex == False)) + (eventWidget->core.tm.translations == NULL) ) + return; + +xlations = eventWidget->core.tm.translations; +bindData = (TMBindData) eventWidget->core.tm.proc_table; +if (bindData->simple.isComplex == False) return; sb->current = sb->start = __XtMalloc((Cardinal)1000); ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X.Org and network
Hi Maxime, i think there is actually MUCH interest in X11 over network. The fact that there are several solutions proves that. I am not a core developer but use X11 very ofter via network and the BIG problems are not inside X11 itself but inside the toolskits (use xrestop and become speachless: E.g. 1164 windows for Firefox now on this box now) The next problem is the licenses of e.g. NX or VNC they use GPL while xorg is MIT (i may be wrong). NTL it would be interesting to document more about profiling X11, so people can easly complain WHO is eating there performance. re, wh Maxime ACCADIA schrieb: > Hi, > > I was wondering if there is any project aiming to improve network > features in X.Org. > > Despite X11 was designed to work over a network, using X11 over a low > bandwidth network with common desktop environments is a pain. > > Thin client architecture is of growing interest for schools, enterprises etc. > Current thin client solutions use one of these technology : > * VNC (eg. ThinLinc) > * ssh -X (eg. LTSP) > * NX > > NX gives reasonably good performances (I didn't tried TigerVNC). > However, it seems that open source community isn't very interested by > NX (there might be some good reason to that). Even major distributions > doesn't provide official packages for NX implementations (freeNX, > neatx). > > I think a good open source solution for remote display is missing, and > improving X.Org network capabilities is the best way to fix this. This > may imply a fairly great amount of work but also a lot of fun ! > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
bug in libXaw 1.0.7
When testing smatch i found a minor bug in libXaw.
re,
wh
--- libXaw-1.0.7/src.org/TextSrc.c 2010-08-16 18:42:12.0 +0200
+++ libXaw-1.0.7/src/TextSrc.c 2010-08-16 18:43:17.0 +0200
@@ -537,10 +537,11 @@
Cardinal size;
switch (*(XawTextEditType *)fromVal->addr) {
- case XawtextAppend:
+
case XawtextRead:
buffer = XtEtextRead;
break;
+ case XawtextAppend:
buffer = XtEtextAppend;
break;
case XawtextEdit:
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: libXfont 1.4.2 build issue
Gaetan Nadon schrieb: > On Wed, 2010-06-23 at 14:40 -0400, Marty Jack wrote: > >> I suggest the following patch to discontinue generating the .txt >> version entirely. >> > > I'll see if I can skip the build if lynx is not installed. I think there > are still people working on character based platforms. > > In the mean type you can configure the package --without-xmlto > please do not drop txt support. txt is much more accessable/processable that html. txt can always be read without special tools. re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is MAXRESOURCES 400?
Yoshihiro Takahashi schrieb: > Hi. > > Why is MAXRESOURCES 400? > I want to get of Resources more than 400 in XtGetApplicationResources. > > libXt-1.0.2/src/Resources.c and libXt-1.0.5/src/Resources.c > #define MAXRESOURCES 400 > mmmh, it should be defined only once. but i guess its abitrary do odd things happen when you define something else ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: mwm
Hi Peter, The first think that comes to my mind is to check if the events are "real". Did you check with xev and see the keypress events ? [ to see if its a general kbd problem or not ] Do other WM have the same problem ? (twm ?) [ perhaps an other programm grabs the events ] When you use other key combinations in your mwmrc do they work ? [ something odd in mwm ] did you report to ubuntu-bug-ml ? [ they should know that they broke something ] re, wh Peter A. Buhr schrieb: > I have been using mwm for over 20 years. I just installed Ubuntu 10.4 on my > laptop and now when I press Alt-button1 in a window (versus frame) to raise > the window (defined in my .mwmrc file), mwm locks up and only allows input > into > the window where I performed the Alt-button1. (It also fails for Alt-button2 > and Alt-button3, which are defined to do other actions.) I have to kill mwm > and > restart it to make it work again. I have no problems on Ubuntu 8.4 and 9.10. > Is > anyone else having this problem? Can anyone suggest what's going wrong? I've > tried everything to make it work, including building and installing the latest > and older versions of open-motif. I really don't want to switch window > managers, as I love the simplicity of mwm. HELP!!! > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: wha...@bfs.de > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: libXcolor package name
Kai-Uwe Behrmann schrieb: > The man command gives me: > > Man: find all matching manual pages > * Xcolor (3) >Xcolor (3x) >XColor (3) > > Will this be a problem? The XColor man page referes to the XColor > structure. Is XColor much used these days, so I would need to pick an > other name? > > what is about libXcm ? feel free at an "s" like libXcms re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: problem with xset
JD schrieb: > > > On 05/17/2010 09:36 PM, Mike Oliver wrote: >> On 5/17/2010 9:15 PM, JD wrote: >>> xset r rate 2 255 >>> belches out the error that Xlib does not have XFree86-Misc >>> for display 0:0 >>> and my autorepeat gets set to 0 delay and probably maximum >>> repeat rate, so that I am not even able to type any command. >>> For example, doing an ls becomes: >>> $ lss >> >> That sounds like it's working then. So instead of asking for a 2ms >> pause before the autorepeat begins and 255 repeats per second >> (which is what you're doing now), play with the numbers to get >> closer to the behaviour you really want. >> >> You said you wanted a slow repeat, right? Try 'xset r rate 1000 4', >> which should wait one second (1000ms) before beginning to repeat and >> should then repeat at a rate of 4 events per second. >> >> Mike. > > Thank you Mike, > That did it. But the server still says: > Xlib: extension "XFree86-Misc" missing on display ":0.0". > > So why would the man page say the rate comes before the delay in the > args list? > What a &*...@#$@%#&$ man page!!! > Even --help specifies the args backwards. > my man page says: " The first specifies the delay before autorepeat starts and the second specifies the repeat rate." is there an other line ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Gettys notes posted to wiki
Barton C Massey schrieb: > Jim Gettys has kindly allowed me to post to the X.Org wiki a > draft document he wrote a while back on the status of various > X.Org technologies. Please see > http://www.x.org/wiki/Development/Documentation/Obsolescence > Hi Bart, that is very nice, but using pdf in a wiki is missing the point of a wiki. To fullfill the point "is known to need work" it would be helpful to have a text version. can you ask for a text version (conversion would also work). re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Find a shell
LALLIER Cedric (EXT TEAMLOG) schrieb: > Hi, > > How to find a shell from its name? Which command/function? > > Thx > > Cédric hope that helps, $whereis bash bash: /bin/bash ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
Dirk Wallenstein schrieb:
> On Tuesday 17 November 2009 09:56:35 walter harms wrote:
>> xkbcomp -xkm ${DISPLAY} -o keymap.xkm
>> Warning: Could not load keyboard geometry for :0.0
>> BadAlloc (insufficient resources for operation)
>> Resulting keymap file will not describe geometry
>>
>>
>> xkbprint keymap.xkm >keymap.ps
>> Error:Couldn't read geometry from XKM file "keymap.xkm"
>> Exiting
>
>
> The keymap you get from the $DISPLAY does not contain the geometry, you must
> obtain it per setxkbmap/xkbcomp
> For example:
> setxkbmap -model pc104 -print | xkbcomp -xkm -o keymap.xkm -
> Note the '-' at the end.
> Feeding keymap.xkm to xkbprint should now work.
>
> By omitting '-model xxx' you get the geometry for the current keymap
>
>
yeees, this works for me. thx a lot.
perhaps you can spend some time to upgrade the kbd tools so so work as expected
and give
useful error msg (if any).
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
Dirk Wallenstein schrieb:
> On Monday 16 November 2009 19:09:11 walter harms wrote:
>
>> any idea why this BadAllocmay show up ? i have plenty of ram,
>> and the resulting keymap.xkb seems resonable.
>>
>> xkbcomp -xkb ${DISPLAY} -o keymap.xkb
>> Warning: Could not load keyboard geometry for :0.0
>> BadAlloc (insufficient resources for operation)
>> Resulting keymap file will not describe geometry
>
>
> By means of the geometry description it is possible to draw a picture of
> diverse keyboards. This info is of no value in the server (it only occupies
> space) and can be obtained separately. Thus you can ignore those warnings. If
> you want to see some of those keyboard pictures you can try `xkbprint`
>
It seems something is returning a wrong error.
xkbcomp -xkm ${DISPLAY} -o keymap.xkm
Warning: Could not load keyboard geometry for :0.0
BadAlloc (insufficient resources for operation)
Resulting keymap file will not describe geometry
xkbprint keymap.xkm >keymap.ps
Error:Couldn't read geometry from XKM file "keymap.xkm"
Exiting
I would say there is much work ahead, perhaps you can start adding a -version ?
(that would be helpful in situations like that here). Obviously i can generate
with xkbcomp (beside a wrong error msg) an .xkm that is not processable by
xkbprint,
also a nice bug.
hope that helps for a stating point
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
Dirk Wallenstein schrieb:
> On Sunday 15 November 2009 01:01:49 Maciej Piechotka wrote:
>
>> Everything is working except AltGr+e/E and AltGr+n/N. What is wrong?
>
>
>
> You probably have to change the key types. You can get the current keymap by
> executing this command:
>
> $> xkbcomp -xkb ${DISPLAY} -o keymap.xkb
>
> Now edit the resulting file keymap.xkb and find the sections for the keysym
> assignment. They might look something like this:
>
> key {
>type[group1]= "FOUR_LEVEL_ALPHABETIC",
>type[group2]= "ONE_LEVEL",
>symbols[Group1]= [ e, E, EuroSign, EuroSign ],
>symbols[Group2]= [ e ]
> };
>
> key {
> type[group1]= "FOUR_LEVEL_ALPHABETIC",
> type[group2]= "FOUR_LEVEL_ALPHABETIC",
> symbols[Group1]= [ o, O, End, End ],
> symbols[Group2]= [ o, x, y, z ]
> };
>
>
> You have to change the values for the type[groupX] entries. Just take the
> values from the keys that work, and fill in the keysyms.
>
> You can install the result by executing the following command:
>
> $> xkbcomp keymap.xkb ${DISPLAY}
nice tip i could not resist to test it here is my result,
unfortunately there is no -version information available
nore does the man page indicate that you can use $DISPLAY
as input.
any idea why this BadAllocmay show up ? i have plenty of ram,
and the resulting keymap.xkb seems resonable.
xkbcomp -xkb ${DISPLAY} -o keymap.xkb
Warning: Could not load keyboard geometry for :0.0
BadAlloc (insufficient resources for operation)
Resulting keymap file will not describe geometry
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: Edid quirk for Philips LCD LP154W01
ykzhao schrieb:
> On Fri, 2009-11-13 at 09:34 +0800, Zhao, Yakui wrote:
>> From: Zhao Yakui
>>
>> Move the EDID quirk for Philips LCD LP154W01 as the panel reports the
>> vertical
>> size in cm.
> Hi, Ajax
> The EDID in several Philips LCD monitor reports the panel vertical
> size in cm, which causes that the user gets the incorrect DPI. So we
> should add the EDID quirk for such display monitors.
>
> In fact we also have the edid quirk for these display monitors. But
> it is put into the wrong place.
>
> Do you have an opportunity to look at this patch?
>
> Thanks.
>
>
>> https://bugs.freedesktop.org/show_bug.cgi?id=24482
>>
>> Signed-off-by: Zhao Yakui
>> ---
>> hw/xfree86/modes/xf86EdidModes.c | 10 --
>> 1 files changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/xfree86/modes/xf86EdidModes.c
>> b/hw/xfree86/modes/xf86EdidModes.c
>> index 449078e..356e51e 100644
>> --- a/hw/xfree86/modes/xf86EdidModes.c
>> +++ b/hw/xfree86/modes/xf86EdidModes.c
>> @@ -131,8 +131,11 @@ static Bool quirk_detailed_v_in_cm (int scrnIndex,
>> xf86MonPtr DDC)
>> return TRUE;
>>
>> /* Bug #21000: LGPhilipsLCD LP154W01-TLAJ */
>> +/* Bug #10304: LGPhilipsLCD LP154W01-A5 */
>> if (memcmp (DDC->vendor.name, "LPL", 4) == 0 &&
>> -DDC->vendor.prod_id == 47360)
>> +(DDC->vendor.prod_id == 47360 ||
>> +DDC->vendor.prod_id == 0 ||
>> +DDC->vendor.prod_id == 0x2a00))
>> return TRUE;
>>
>> /* Bug #21750: Samsung Syncmaster 2333HD */
>> @@ -145,11 +148,6 @@ static Bool quirk_detailed_v_in_cm (int scrnIndex,
>> xf86MonPtr DDC)
>>
>> static Bool quirk_detailed_use_maximum_size (int scrnIndex, xf86MonPtr DDC)
>> {
>> -/* Bug #10304: LGPhilipsLCD LP154W01-A5 */
>> -if (memcmp (DDC->vendor.name, "LPL", 4) == 0 &&
>> -(DDC->vendor.prod_id == 0 || DDC->vendor.prod_id == 0x2a00))
>> -return TRUE;
>> -
>> /* Bug #21324: Iiyama Vision Master 450 */
>> if (memcmp (DDC->vendor.name, "IVM", 4) == 0 &&
>> DDC->vendor.prod_id == 6400)
>
just a general question,
is it clever to do such things in code ?
IMHO something like a "blacklist" is needed so the system can bail out
on monitors that report crap. That would add the opportunity for other to
contribute.
/* note i have no idea how to do this practical given the huge number of
possible bugs but certainly that would be a huge boost for the autoconfig
stuff
*/
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
Eirik Byrkjeflot Anonsen schrieb:
> Adam Jackson writes:
>
>> On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote:
>>> Hi all,
>>>
>>> can anyone fix compiling of xrandr against uClibc (reported in
>>> http://bugs.freedesktop.org/show_bug.cgi?id=12958)
>>>
>>> see also:
>>> http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html
>>> http://lists.x.org/archives/xorg-devel/2009-February/000281.html
>>> http://bugs.gentoo.org/197013
>>> http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html
>> Pretty sure this is a uclibc header bug. glibc has exactly the same
>> definitions in and does not have this problem. Which I
>> already said the last time this was brought up:
>>
>> http://lists.x.org/archives/xorg-devel/2009-March/000365.html
>>
>> - ajax
>
> If you think that it is a bug in the uclibc headers to declare the
> clone() function at all, your argument is valid. However, I think the
> comment in the bug ("why cant this symbol get renamed so that things
> compile?") is also valid (regardless of who is "at fault"). Renaming
> the enum value to avoid the potential conflict may be the better option
> anyway...
>
> And I don't think glibc's behaviour is a normative reference :) (If
> someone could find a specification that clearly says whether it is
> disallowed to declare clone(), that would be nice...)
>
I have no clue where clone is coming but you may like to know:
glibc/linux also has a syscall called clone, who is that handled ?
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: disable export:DISPLAY
Glynn Clements schrieb:
> strat...@telenet.be wrote:
>
>> On multiseat/multi-users system there are multiple users logged in via
>> gdm.Problem is that a user can start programs or take over a display
>> from another user.How to prevent this?I have read about
>> mit-magic-cookie but did not found a howto.
>
> Use user-based ("xauth") access control rather than host-based ("xhost").
>
> This should be the default if the server is started by a display
> manager, unless you explicitly allow host-based access via xhost
> (which you shouldn't do for a multi-user system).
>
> I can't comment on GDM specifically (I don't use it, and the
> documenation is silent on this issue), but it's possible that either
> GDM or the default startup scripts perform the equivalent of
> "xhost +local:" or "xhost +inet:localhost".
>
i do not understand the problem. how do you connect to the server ?
Normaly each user should have a separate session or uses every user the
same login ?
the most easy way is to use "X :0 -query server" and become an X11-Terminal.
The other way is the login using ssh -X host and export the gfx.
re,
wh
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C&T ct65545 problem
Xavier Bestel schrieb: > On Mon, 2009-10-26 at 18:15 +0100, walter harms wrote: >>> recently versions of the server don't support ISA anymore. >>> >>> >> the the error message should be more clear: >> >> if Primary Device is == ISA >> ISA is not supported anymore (since 1.x) > > If the server doesn't support ISA, it will have a hard time knowing that > "Primary Device is == ISA" ... > > Xav i am confused, the message says : (II) Primary Device is: ISA So somehow someone knows he must scan the isa bus. can this part send a warning ? The message (EE) No devices detected clearly sends anyone - not knowing about the missing ISA support - searching in the wrong direction. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C&T ct65545 problem
Tiago Vignatti schrieb: > Yan Seiner wrote: >> I have a very, very old laptop - 1995 vintage - that I want to repurpose >> for a net-terminal. It has a Chips and Technologies 65545 video >> chipset. This works with X as I've run it in the past with both freeBSD >> and an older version of linux (something with a 2.4 kernel and an old >> version of xfree.) I decided to upgrade this to a current version to >> get some net tools. Now I can't get X to recognize the C&T chipset. >> >> I am using xorg 7.4, with the chips driver. X fails with: >> >> (II) Primary Device is: ISA >> (EE) No devices detected >> >> Unfortunately I don't have pcmcia working either so I can't copy and >> paste quite yet. >> >> I suspect that the driver cannot auto-probe the ISA bus and it's looking >> for some sort of IRQ or base address. But how do I go about finding >> this? I don't recall having to do anything special in the past, but who >> knows >> > > recently versions of the server don't support ISA anymore. > > the the error message should be more clear: if Primary Device is == ISA ISA is not supported anymore (since 1.x) re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X using 95% CPU (intel, latest git)
Carl Worth schrieb: > On Thu, Aug 13, 2009 at 06:01:34PM -0400, Andy Neitzke wrote: >> My problem is that frequently, even when the system should be idle, KDE's >> CPU >> monitor applet shows that one of the two processors is fully loaded. When >> this happens, "top" blames the X process, showing it using around 95% CPU. > ... >> My question is: how can I diagnose this problem more precisely? (Is it >> a symptom of an Xorg bug, or could it that some part of KDE is issuing an >> enormous number of requests to the X server for some reason?) > > Could be either. The next step would be to use a profiler, (such as > sysprof or oprofile), to find out what functions are eating up all of > the CPU. > > -Carl > Hi Andy, you can start a pure X simply bei starting X (see man X) on the commandline. That should give a an impression if the server/driver (aka X11) is responsible or something other, later in the food chain. Next you can try with an application (xterm), then a simple WM (twm or), and see what will happen, perhaps the effekt is related to an special option like 3d functions ... re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: liblbxutil broken?
Julien Cristau schrieb: > On Mon, Aug 10, 2009 at 10:04:06 +0200, Robert Schwebel wrote: > >> Hi Adam, >> >> In 57d09e47d05fce0d6df4060b2eff9a8efcc25b2f you have removed lbxzlib.h >> from the xextproto sources. However, liblbxutil does still reference >> this header file (1.0.1 as well as git head). >> >> Is there some new dependency, or is this just a bug? >> > lbx has been dead for years. So out of curiosity, why are you building > liblbxutil? > if its dead why it is still with GIT ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: make[4]: *** No rule to make target `-lselinux', needed by `libxorg.la
Justin P. Mattock schrieb: > On an x86_64 build, > I think xserver is not looking in /lib64 for > libselinux. under the options how would > I go about doing this > i.g. LIBS=L/lib64 or something different? > in theorie ./configure LDFLAGS=-L/lib64 should do the trick. ntl is is a bug in configure not to detect this. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP over SSH - a better idea (hopefully)
Vic Lee schrieb: > Hi, > > Sorry I sent this email to xorg-devel but I realized that this should be > a feature discussion, not yet a development discussion... So I resend it > here. > > Recently I want to implement XDMCP over SSH feature when doing my > project. I've done some research and understand that "XDMCP uses UDP > that natively cannot be tunnelled over SSH", however there's a > well-known workaound: > > LOCAL$ ssh -X REMOTE Xephyr :1 -query localhost > > which query XDMCP in a remote Xephyr, then to tunnel the Xephyr window > using X11 forwarding. However this is not working good enough for me > since (1) I don't want to ask users to install Xnest or Xephyr on SSH > server (2) Somehow the tunnelled Xephyr window won't recognize -parent > argument to embed into my app - it always create a top-level window; > well, this could be another bug but I don't want to waste my time > investigating on this, since now I came up with a better solution. > > I would like to implement a new binary, let's temporarily call it > "xdmcp-bin". It will fully implement the XDMCP protocol and talks to any > Display Manager; however, instead of creating a new X server like Xephyr > or Xnest does, it simply ask the Display Manager to connect to an > existing one (usually this is the X server that $DISPLAY is pointing to > - like any other X clients). > > So here comes the real thing. :) A typical XDMCP over SSH senario would > be: > > LOCAL$ Xephyr :1 (or even X :1, whatever that creates a new X server) > LOCAL$ export DISPLAY=:1 > LOCAL$ ssh -X REMOTE xdmcp-bin -query localhost > > What happen in the third line is that, "xdmcp-bin" runs on REMOTE, query > its Display Manager to create a new session and connect to "xdmcp-bin"'s > DISPLAY environment, which is a X11 tunnel that connects back to :1 at > LOCAL. You know what should happen next: we tunnel XDMCP session. > > I am totally new to X.org development. I would like to get your comments > before I get started with this new feature. > It sounds a bit like nx or neatx, are you aware of this solutions ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
walt schrieb: > On 07/26/2009 01:56 PM, Jim Gettys wrote: >> David Moffatt wrote: >>> Responding to the thread about mapping hardware scan codes --> X key >>> codes and keyboards with> 248 keys. >>> >>> Perhaps the solution is to take the hardware scan code --> Symbol >>> problem out of the X layer entirely. Let the OS deal with that in its >>> own manner. >>> >> X already does this: keycodes in X have no need to be even remotely >> similar to what the operating system does, or what the hardware generates. >> >> Keycodes on various other platforms may have values that bear no >> resemblance to the codes used in Linux, or in IBM derivative keyboards... > > Being strictly an amateur programmer, I've always wondered how many > people/institutions actually use X for remote display the way it was > designed to be used. Seems to introduce a great deal of confusing > complexity for features many of us never use. > it is common to have a fat server and several clients that use it remote (not only thin clients) re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/3] Fix printf() format
David Sharp schrieb: > On Sun, Jun 14, 2009 at 12:06 AM, Ben Gamari wrote: >> Fix compiler warning: >> >> imLcIm.c:364: warning: format ‘%03x’ expects type ‘unsigned int’, but >> argument 6 has type ‘long unsigned int’ >> imLcIm.c:367: warning: format ‘%03x’ expects type ‘unsigned int’, but >> argument 6 has type ‘long unsigned int’ >> --- >> modules/im/ximcp/imLcIm.c |8 >> 1 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/modules/im/ximcp/imLcIm.c b/modules/im/ximcp/imLcIm.c >> index 17121b5..e398112 100644 >> --- a/modules/im/ximcp/imLcIm.c >> +++ b/modules/im/ximcp/imLcIm.c >> @@ -363,11 +363,11 @@ Private int _XimCachedFileName ( >> *res = Xmalloc (len + 1 + 27 + 1); /* Max VERSION */ >> >> if (len == 0 || dir [len-1] != '/') >> - sprintf (*res, "%s/%c%d_%03x_%08x_%08x", dir, _XimGetMyEndian(), >> - XIM_CACHE_VERSION, sizeof (DefTree), hash, hash2); >> + sprintf (*res, "%s/%c%d_%03lx_%08x_%08x", dir, _XimGetMyEndian(), >> + XIM_CACHE_VERSION, sizeof(DefTree), hash, hash2); > > This will break systems where size_t is 32 bits. 'z' is the correct > length modifier for size_t > >> else >> - sprintf (*res, "%s%c%d_%03x_%08x_%08x", dir, _XimGetMyEndian(), >> - XIM_CACHE_VERSION, sizeof (DefTree), hash, hash2); >> + sprintf (*res, "%s%c%d_%03lx_%08x_%08x", dir, _XimGetMyEndian(), >> + XIM_CACHE_VERSION, sizeof(DefTree), hash, hash2); >> >> /* fprintf (stderr, "-> %s\n", *res); */ >> if ( (fd = _XOpenFile (*res, O_RDONLY)) == -1) >> -- it also breaks for dir="very log string that will overflow the buffer" there is an asprintf(3) equivalent that would be more save and you can remove the Xmalloc. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Missing symbols (_xcb_lock_io, _xcb_unlock_io)
Christopher Dale schrieb: > Hi Joel, > > I just wanted to let you know that I'm having the same problem with > today's git pull. The first time I ran into this problem was with > xbacklight (which I skipped over) and then the next time I ran into it > was with xrandr (which I did *NOT* skip over) which has me stopped in > my tracks until I can get it to compile correctly. I've tried all > kinds of things with grepping for la files and deleting la files and > nothing's worked. I've even re-compiled libX11 in the hopes that it > might pick up on some of the attempts at grep/deleting the *la's. If > anyone has any ideas, they are most welcome. > > Thanks everyone! > IMHO the most easy way is grep -i _xcb_unlock_io if it does not show up it is not there. for me it shows up in libxcb and libxcb-xlib here you can go into details. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
Peter Hutterer schrieb: > On Tue, May 12, 2009 at 09:49:08AM +0200, walter harms wrote: >> >> Emanuele Tamponi schrieb: >>> In data lunedì 11 maggio 2009 14:48:51, walter harms ha scritto: >>>> maybe you can reproduce that with xev ? >>>> does ist happen with other inputs devices also ? keyboard ? >>> I'll try with xev. >>> Every mouse device stops working: wireless mouse and builtin trackpad. >>> >> sounds like a strange bug in the subssystem. >> This is beyond my capabilities :( > > no, actually. this is how input devices work. the physical devices are > abstracted away through the virtual core pointer. all events go through this > core pointer device, and if an application grabs it then events are no > longer sent to anyone else. same with the keyboard. > hence if you have a rogue grab, all devices seem to stop working. > but only mouse events are missing, the keyboard seems to work fine At least i would notice very fast if someone is eating my letters. I think it is unlikely that a programm would only grap a mouse but not the keyboard. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
Emanuele Tamponi schrieb: > In data lunedì 11 maggio 2009 14:48:51, walter harms ha scritto: >> maybe you can reproduce that with xev ? >> does ist happen with other inputs devices also ? keyboard ? > > I'll try with xev. > Every mouse device stops working: wireless mouse and builtin trackpad. > sounds like a strange bug in the subssystem. This is beyond my capabilities :( re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X stops receiving mouse clicks
maybe you can reproduce that with xev ? does ist happen with other inputs devices also ? keyboard ? re, wh Emanuele Tamponi schrieb: > In data sabato 9 maggio 2009 18:09:50, Emanuele Tamponi ha scritto: > >> I exclude the toolkit because it happens on both Qt-based and GTK-based >> application... I'll try to install compiz or some other window manager and >> replace KWin, I'll let you know if the problem goes away. > > Tried with wm2, same problem. > > So it really looks related to X. Any hint? > > Emanuele > ___ > 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: [Fwd: intel driver: xorg does not give an error, but I do not see anything]
did you try xrandr to get some basic info ? re, wh Dirk De Becker schrieb: > > Hi all, > > I am running a Gentoo system with X.Org server version 1.5.3 and > xf86-video-intel version 2.6.3-r1. > I have a board with the following Intel graphics chip on it: >> lspci | grep Graphics > 00:02.0 VGA compatible controller: Intel Corporation Mobile > 915GM/GMS/910GML Express Graphics Controller (rev 04) > 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML > Express Graphics Controller (rev 04) > > If I startx, I do not get any errors (anymore), but I do not see > anything on my screen. I tried connecting a VGA display, a DVI display > and even an LVDS display. > I attached the xorg.conf file, and Xorg.0.log file > Previously, I used the iegd proprietary intel embedded driver, but that > is not working anymore since a recent gcc upgrade from version version > 4.1.2 to 4.3.2-r3. > > Any help is greatly appreciated, since I do not have any clue what else > I can try. > If you need any more info, please feel free to ask me. > > Dirk > > > > > > ___ > 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: bug in xfont xlfd rounding code
Dave Airlie schrieb: > Hi guys, > > Maybe someone understand wtf the code in > libXfont/util/fontxlfd.c:xlfd_round_double > is all about, but the results were different on different endian > machines due to the code > being hardcoded for little endian. > > I reimplemented it for other endian, however I'm unsure about the > endian detect code on other OSes, > it just uses the autoconf macros. > hi dave, looks nice. the code does not seem to be used often. can you test what the speed penalty of using the general case is ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Floats in the protocol
> Hello people, > > I'm trying to get some consensus about floats on the wire. I cc'ed some > who spoke about the issue on the list in a non-exhaustive search. > > Recap: Peter and I want to transfer floats in input properties, see there: > http://lists.freedesktop.org/archives/xorg/2008-December/041647.html > > On XDS 08, Keith suggested simply putting them on the wire. That is, > require IEEE756 32 bit and account for endianness. > > Roland suggested to drop the binary representation, and favored a string > rep. specified in C99. He claims interchange of binary representations > is unsafe due to platform details: > http://lists.freedesktop.org/archives/xorg/2008-December/041650.html > > While I see benefits of a string rep, X isn't C99 AFAIK. Also, the > protocol in general is built on binary representations, so a string > encoding seems somewhat odd to me. > > I don't actually need floats badly, but they're more natural than fixed. > > Comments/Suggestions please? if floats are realy needed i would go with an already established like XDR it is already in glibc and it is a defined RFC. the next best thing is to use plain ascii as it removes the need to think about endians. just my 2 cents, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
more than one Cursor ?
hi list, it is possible to use 2 mice in parallel with X11. Is it also possible to have 2 cursors ? each one controlled by one of the mice ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LBX? or faster remote X?
Bob Tracy schrieb: > On Tue, Nov 04, 2008 at 10:37:43AM -0800, Alan Coopersmith wrote: >> Keith & Jim's 2003 Usenix paper suggests ssh with compression beats LBX >> in most cases: >> http://keithp.com/~keithp/talks/usenix2003/ > > They lie, *especially* for slow links. However, NX is a vastly > superior alternative to consider: it's actually usable over modem > connections. You won't miss LBX. > i also have good experience with NX but is uses SSH. the have published there code as GPL. license problems aside it would be a huge advantage for xorg to incorporate the changes in the std. libraries. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Embedded X
uClibc is in heavy development. perhaps you can forward your problems building with uClib to the uClib Mailinglist ? IMHO the lack of I18N (i do not know the state of uClib here either!) is not a problem since it is designed for memorytight systems where it is unlikly to have i18n at all. re, wh Jim Gettys schrieb: > Does uClibc actually buy you anything? Last I looked, (admittedly quite > a few years ago), it lacked I18N support that most products now require, > at least by the time you are doing serious UI work. But times may have > changed, and it isn't obvious from the sketchy documentation. > > At that date, we ended up having to carry glibc anyway, at which point > it is moot, and uClibc just ended up costing space, rather than saving > it. > - Jim > > > > On Tue, 2008-10-14 at 09:22 -0700, William Tracy wrote: >> On Tue, Oct 14, 2008 at 12:40 AM, John Tapsell <[EMAIL PROTECTED]> wrote: >>> Why not just go for the full X11? Memory wise I found no difference >>> in the memory usage between X11 and kdrive on the OMAP. >> I am told that the full Xorg isn't very happy when built against uClibc. >> >> The original poster probably isn't using uClibc, but can anyone >> comment on building the full server against uClibc? >> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: problem with i830M interlaced VGA output (915G works fine)
Thomas Hilber schrieb: > On Mon, Oct 06, 2008 at 09:58:57AM -0700, Keith Packard wrote: >> On Sun, 2008-10-05 at 09:21 +0200, Thomas Hilber wrote: >>> Hi list, >>> >>> with the attached patch and xorg.conf I successfully use interlaced modes >>> like 720x576i on a 915G chipset. For an i830M this unfortunately does not >>> yet work completely. First of all thanks to Keith Packard and >>> Krzysztof Halasa for their basic PIPEACONF investigations posted here: >> I845 and earlier chips (I didn't look at the i855 or i865) do not >> support interlaced display at all. > > but it's quite strange. Even my i810 is running in > interlaced mode (i.e. 720x576i) with exactly the patch above with no > problems at all. > > OK, but if there is an 'interlace gap' between and including i830 - i865 then > I will stop to find a solution for this issue. > > anyway, thank you for your answer! > > can you produce a testcase ? i have a notebook with i830m maybe we can use that program to test other chipsets also and establish what chips a capable. Sometimes these features are simply undocumented. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken XNextEvent()(libX11 1.1.2 - 1.1.5)
mmh,
i am not an expenrt on xorg internal but why not add
if (!XPending()) return; to XNextEvent(); ?
that would translate old stile loop into the new form
and leave other programs with 2 Pending() calls, what
should be harmless. in the long run the if would eliminate
the if XPending() from all the loops in the current programs.
re
wh
Fumihito YOSHIDA schrieb:
> Hi lists,
>
> In libX11 1.1.2 (and newer), XNextEvent() sometimes segfault by null
> exception.
>
> This problem look like come from _XReadEvents()/_XSend() behavior.
> The problem is not reproduce in 1.1.1 and old.
>
> Compiz and IIIMF fall under this problem, but these are typically
> example, I think that many programs stuck by this problem.
>
> Is it bug, or new specification?
>
> =
> Details:
> =
>
> A new implementation of _XReadEvents() is lockless, and compatible
> for olddays behavior, but it cause segfault at some conditions.
>
> (_XReadEvents() take least one events, but when XLostDisplay flag is
> true, _XReadEvents() does not returned any valid events.
> So, it cause segfault in XNextEvent() by null pointer exception.),
>
> For example, Florian Echtler said in below mail,
> http://lists.freedesktop.org/archives/xorg/2008-September/038344.html
> this crash is typicial pattern of this bug.
>
> This is *not* coding issue, but you can evade this problem with some
> coding design.
>
> Case1: Classical X event loop
> // It will cause segfault in some conditions
>
> Display *pdisplay;
> XEvent event;
> pdisplay = XOpenDisplay(NULL);
>
> for (; ;){
> XNextEvent(pdisplay, &event);
> /* X Event Handler */
> }
>
> This code (rarely) causes segfault at XNextEvent().
> If you trace it, you will find below crash point.
>
> --- XNextEvent() --
> int
> XNextEvent (
> register Display *dpy,
> register XEvent *event)
> {
> register _XQEvent *qelt;
>
> LockDisplay(dpy);
>
> if (dpy->head == NULL)
> _XReadEvents(dpy); // <- it hope _XReadEvents return valid
>// handler, it believev
> dpy->head != null...
> qelt = dpy->head;
> *event = qelt->event; // <- but, dpy->head->event is null, CRASH.
> // Because dpy->head is null!
> _XDeq(dpy, NULL, qelt);
> UnlockDisplay(dpy);
> return 0;
> }
> --
>
> If you replace "if(dpy->head == null)" to "while(dpy->head == null)",
> the problem solved.
> // Notice: if => while replacement cause busy loop and possible infinite loop.
>
> This segfaults conditions are:
> a) X Event queue is empty.
> b) XDisplayIOError is true.
> You call XNextEvent() when (a && b), your program will segfault.
>
>
> Case2: Modern X event loop style is below:
> // It wont cause segfault, and lockless.
>
> Display *pdisplay;
> XEvent event;
> pdisplay = XOpenDisplay(NULL);
>
> for (; ;){
> if (XPending()){
> XNextEvent(pdisplay, &event);
> /* X Event Handler */
> }
> /* other event looping and some usleeps. */
> }
>
> Because this implement want evading XNextEvent()'s blocking.
> XNextEvent() always return least one events, but when X event
> queue is empty, cause blocking-wait for next new events.
>
> But, man XNextEvent(3) says:
> | The XNextEvent function copies the first event from the event queue
> | into the specified XEvent structure and then removes it from the queue.
> | If the event queue is empty, XNextEvent flushes the output buffer and
> | blocks until an event is received.
>
> Current implement is not "blocks", "sometimes blocks, sometimes crash".
>
> And we have big issue, the classical X event loop(Case1) are not failure
> in old-days, their coding were(are?) right. (But, their old style coding are
> not
> efficient, we need modern style.).
>
> We can find their classical event loop in many code asset, they will crash
> by this problem.
>
> =
> Root cause:
> =
> It cause by xcb_io.c::_XReadEvents() and xcb_io.c::_XSend().
>
> When dpy->head is null, the XNextEvent() called _XReadEvents(),
> but xcb_io.c::_XReadEvents() and xcb_io.c::_XSend() has dpy->flags check,
> when XlibDiskpayIOError bit is set, their procedure return without any work.
>
> if(dpy->flags & XlibDisplayIOError)
> return;
>
> So, XNextEvent()'s dpy is still null, and crash.
>
> I suggest dirty hack.
> XlibDisplayIOError flag can be cleard with some wait times.
>
> --- NextEvent.c.orig
> +++ NextEvent.c
> @@ -45,9 +45,14 @@
> register _XQEvent *qelt;
>
> LockDisplay(dpy);
>
> - if (dpy->head == NULL)
> +while(dpy->head == NULL){
> _XReadEvents(dpy);
> + usleep(400);
> + }
> qelt = dpy->head;
> *event = qelt->event;
> _XDeq(dpy,
Re: Switching Virtual consoles causes ALTERNATE console to crash.
Yalenti, Mark schrieb: > BTW, the same thing happens on a Single-Head System as well, which does not > have > nVidia video drivers...So that answers that question... > > Let me know if you'd like me to post my config and logs... > > I"m hoping this is something someone has seen before. > > > > Regards, > > Mark > not exactly the same but ... with on older X11 (1.4.0.90) that comes with OpenSuse 11.0. I started a second session using X :1 -once -query . Switching caused the mouse and console to lockup. it worked again after killing the Xsession. NTL after reboot the problem disappeared. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Beso schrieb: > 2008/9/24 Glynn Clements <[EMAIL PROTECTED]>: >> Ben Gamari (FOSS) wrote: >> >>> My completely unprofessional opinion is that Jason brings up a really >>> good point here. Accidentally zapping Xorg can not only be extremely >>> frustrating, but it could be extremely confusing for a new user. This >>> being said, I also agree that any change that might be zapping >>> unreliable or even unduly difficult is unacceptable.However, I do >>> believe there is a better solution than what we have presently. Ctrl, >>> Alt, and Backspace are usually three of the largest keys on most >>> keyboards and I can personally attest to the ease of triggering on some >>> keyboards (try typing on a laptop balanced on your knee). >>> >>> I think that requiring two presses of Ctrl-Alt-Backspace in close >>> succession would be perfect, so long as a tightly looping Xorg would >>> still register the event. Otherwise, perhaps adding Shift to the >>> Ctrl-Alt-Backspace combination would be a reasonable course of action so >>> long as it doesn't preclude any keyboards. If this too is not possible, >>> perhaps making use of the Pause/Break key in replacement of the >>> Backspace key would be workable. >> Ctrl-Alt-Break would be an improvement. Apart from anything else, that >> isn't bound to anytyhing in Emacs (which pre-dates X, BTW). >> >> For me, if X locks up to the extent that I can't quit the WM (and thus >> the session) normally, it is normally locked up to the extent that >> Ctrl-Alt-BS doesn't work either, and I need to resort to Alt-SysRq-K. >> Unfortunately, that tends to leave the video card in a state where >> consoles don't work, but I can at least use Ctrl-Alt-Del to trigger a >> clean reboot. >> > > maybe could be interesting the adding of a function to remap the > keyboards instead of mapping an alternative. in this way people that > continue to trigger it without really wanting to might change the key > sequence. remapping it would mean that 99% of xorg users need to go > and search for the new key sequence. so in my opinion the proposal is > stupid and would only trigger a users stand up against it. you don't > like it, then just assign another sequence (this should be the real > proposal) if already this has not been implemented. > i do not like the idea, people that use X11 are used to have crtl-alt-bs. it is confusing not to have it. i do not see a real problem. if xorg is confused to an extend that c-a-b does not work anymore it is clear that the code may need some improvements. An other idea would to allow additional key combinations (mod+mouse) to behave like c-a-b. looks like a nice config option. re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: No LoaderPrintSymbol in newer version Xorg-Server?
lu zhihe schrieb: > What I mean is: when you catch some SEGV bug, if the func. is static, and > was in module .so file, how can you catch it now? In older version we had > LoaderPrintSymbol() to find the SEGV caused func. > if the segv is inside the .so you need to build the .so with -g (and remove -Ox). when you debug you should build always with -g. size explodes but it helps to debug with gdb. re, wh > 2008/9/16 Adam Jackson <[EMAIL PROTECTED]> > >> On Tue, 2008-09-16 at 17:41 +0800, lu zhihe wrote: >>> Dear all: >>> >>>There is no LoaderPrintSymbol function in Xorg-Server >= >>> 1.1.0, so if you meet segmentation fault, and use gdb to debug; >>> while, meet the following result: 0x08086000 ??() >>>How can you deal with it now? >> Build the X server with debugging information. See the -g option to >> gcc. >> >> - 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
