CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/11 17:29:01 Log message: Fixed indirect GLX on Mac OS X when the client can not make a connection to the CoreGraphics window server (Apple). Modified files: xc/lib/GL/apple/: dri_dispatch.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.2 +8 -30 xc/lib/GL/apple/dri_dispatch.c 3.2804+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/06 07:04:06 Log message: 357. Include Xmd.h in Xpm/lib/XpmI.h to get definitions of LONG64 (Bugzilla #562, John Dennis). 356. Moved Meta_L/R keys and added Super_L/R keys on macintosh keyboard. This makes the layout more compatible to the PC keyboard layout (Bugzilla #565, Frank Murphy). 355. Add check for Xmalloc() return value in XGetErrorDatabaseText() to avoid Sig11 (Bugzilla #563, Alan Coopersmith). 354. Separated build of libglx.a module and normal libglx.a library (Bugzilla #541, Frank Giessler). 353. Fixed build of Xnest, Xprt and Xvfb for OS/2 by linking with the linker definition files (Bugzilla #541, Frank Giessler). 352. Fixed freeing of properties form xkb_geomerty block (Bugzilla #550, Alexander Pohoyda). 351. Fixed string octal number parsing and string to int conversion for \00 in xkbcomp (BugzillaR #553, Egbert Eich). 350. Removed stale definition from XftCompat.h (BugzillaR #543, Egbert Eich). 349. Added XLC_LOCALE file for zh_CN.UTF-8, moved iso10646 encoding to the end in ja_JP, ko_KR and zh_TW UTF-8 XLC_LOCALE files (Bugzilla #544, Akira TAGOH). 348. Fixed typo in #if conditional in cfb code (Bugzilla #556, Dave Love). Modified files: xc/extras/Xpm/lib/: XpmI.h xc/lib/X11/: ErrDes.c xc/lib/Xft/: XftCompat.h xftlist.c xc/nls/: compose.dir locale.alias locale.dir xc/nls/XI18N_OBJS/: Imakefile xc/nls/XLC_LOCALE/: Imakefile ja_JP.UTF-8 ko_KR.UTF-8 zh_TW.UTF-8 xc/programs/Xserver/: Imakefile xc/programs/Xserver/GL/: Imakefile xc/programs/Xserver/GL/glx/: Imakefile xc/programs/Xserver/cfb/: cfbglblt8.c xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/xkbcomp/: expr.c geometry.c xkbscan.c xc/programs/xkbcomp/symbols/macintosh/: us Added files: xc/nls/XI18N_OBJS/: zh_CN.UTF-8 xc/nls/XLC_LOCALE/: zh_CN.UTF-8 xc/programs/Xserver/GL/glx/module/: Imakefile Revision ChangesPath 1.9 +1 -0 xc/extras/Xpm/lib/XpmI.h 3.11 +13 -5 xc/lib/X11/ErrDes.c 1.6 +0 -3 xc/lib/Xft/XftCompat.h 1.4 +0 -0 xc/lib/Xft/xftlist.c 1.24 +0 -0 xc/nls/compose.dir 1.63 +1 -0 xc/nls/locale.alias 1.43 +1 -0 xc/nls/locale.dir 1.8 +1 -0 xc/nls/XI18N_OBJS/Imakefile 1.26 +1 -0 xc/nls/XLC_LOCALE/Imakefile 1.2 +23 -23xc/nls/XLC_LOCALE/ja_JP.UTF-8 1.2 +24 -24xc/nls/XLC_LOCALE/ko_KR.UTF-8 1.2 +23 -23xc/nls/XLC_LOCALE/zh_TW.UTF-8 3.288 +7 -5 xc/programs/Xserver/Imakefile 1.12 +5 -0 xc/programs/Xserver/GL/Imakefile 1.10 +50 -4 xc/programs/Xserver/GL/glx/Imakefile 3.8 +5 -5 xc/programs/Xserver/cfb/cfbglblt8.c 3.2795+21 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.7 +10 -3 xc/programs/xkbcomp/expr.c 1.5 +5 -5 xc/programs/xkbcomp/geometry.c 3.12 +17 -14xc/programs/xkbcomp/xkbscan.c 1.9 +7 -7 xc/programs/xkbcomp/symbols/macintosh/us ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/11 06:28:24 Log message: updates Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2802+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/05 14:08:29 Log message: BIG_ENDIAN swap the nv driver's new RGB Xv data format. Modified files: xc/programs/Xserver/hw/xfree86/drivers/nv/: nv_video.c Revision ChangesPath 1.18 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/09 07:30:50 Log message: 361. Fixes and updates for XKB keyboard maps: - Added numpad:microsoft XKB option (Bugzilla #558, Will Styles). - Fixed inconsistence in indicator names (Bugzilla #577, Noah Levitt). - Added type6 model of Sun keyboard (Warren Turkal). Modified files: xc/programs/xkbcomp/geometry/: dell everex hp keytronic kinesis macintosh microsoft northgate pc sun xc/programs/xkbcomp/geometry/ibm/: thinkpad xc/programs/xkbcomp/geometry/sgi/: O2 indigo indy xc/programs/xkbcomp/keycodes/: sun xc/programs/xkbcomp/rules/: sun sun.lst xfree86 xfree86.lst xfree86.xml xc/programs/xkbcomp/symbols/sun/: us xc/programs/xkbcomp/types/: Imakefile Added files: xc/programs/xkbcomp/types/: numpad Removed files: xc/programs/xkbcomp/types/: nocancel Revision ChangesPath 3.6 +3 -3 xc/programs/xkbcomp/geometry/dell 1.2 +4 -4 xc/programs/xkbcomp/geometry/everex 1.8 +4 -4 xc/programs/xkbcomp/geometry/hp 1.3 +3 -3 xc/programs/xkbcomp/geometry/keytronic 3.3 +1 -1 xc/programs/xkbcomp/geometry/kinesis 1.3 +4 -4 xc/programs/xkbcomp/geometry/macintosh 3.3 +3 -3 xc/programs/xkbcomp/geometry/microsoft 1.2 +4 -4 xc/programs/xkbcomp/geometry/northgate 3.14 +22 -22xc/programs/xkbcomp/geometry/pc 1.7 +14 -14xc/programs/xkbcomp/geometry/sun 1.3 +5 -5 xc/programs/xkbcomp/geometry/ibm/thinkpad 3.3 +9 -9 xc/programs/xkbcomp/geometry/sgi/O2 3.3 +6 -6 xc/programs/xkbcomp/geometry/sgi/indigo 3.4 +9 -9 xc/programs/xkbcomp/geometry/sgi/indy 3.6 +152 -1xc/programs/xkbcomp/keycodes/sun 3.2 +9 -3 xc/programs/xkbcomp/rules/sun 3.6 +3 -1 xc/programs/xkbcomp/rules/sun.lst 3.68 +2 -1 xc/programs/xkbcomp/rules/xfree86 3.69 +3 -2 xc/programs/xkbcomp/rules/xfree86.lst 1.10 +12 -9 xc/programs/xkbcomp/rules/xfree86.xml 1.7 +139 -36 xc/programs/xkbcomp/symbols/sun/us 3.8 +3 -2 xc/programs/xkbcomp/types/Imakefile ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: )
[EMAIL PROTECTED] CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/12 15:51:22 xc/lib/apple Update of /home/x-cvs/xc/lib/apple In directory public.xfree86.org:/tmp/cvs-serv22312/apple Log Message: Directory /home/x-cvs/xc/lib/apple added to the repository ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/13 13:30:03 Log message: 375. Fix for the Brazilian ABNT2 keyboard extra key that now translates to a different keycode value. Patch suggested by Ivan Pascal. Thanks to Ivan Pascal for suggesting a simpler/cleaner patch, previously I had changed keycodes/br to match K73. Modified files: xc/programs/xkbcomp/keycodes/: xfree86 xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.24 +2 -1 xc/programs/xkbcomp/keycodes/xfree86 3.2808+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/11 06:26:11 Log message: 364. Add Microsoft Pro OEM model to XKB inet map (Bugzilla #458, [EMAIL PROTECTED]) Modified files: xc/programs/xkbcomp/rules/: xfree86.lst xfree86.xml xc/programs/xkbcomp/symbols/: inet Revision ChangesPath 3.70 +2 -1 xc/programs/xkbcomp/rules/xfree86.lst 1.11 +6 -0 xc/programs/xkbcomp/rules/xfree86.xml 1.32 +31 -1 xc/programs/xkbcomp/symbols/inet ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/07 08:04:42 Log message: Further fix for Clevos; additional sisctrl interface feature Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c oem310.h sis.h sis_driver.c sis_video.c Revision ChangesPath 1.22 +5 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.12 +17 -13xc/programs/Xserver/hw/xfree86/drivers/sis/oem310.h 1.41 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.101 +9 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.22 +8 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/12 16:47:11 Log message: Added Apple-WM extension and library (Apple and Torrey T. Lyons). Modified files: xc/lib/: Imakefile xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/config/cf/: X11.tmpl darwin.cf darwinLib.tmpl xc/programs/Xserver/hw/darwin/: darwin.h xc/programs/Xserver/hw/darwin/quartz/: Imakefile XServer.h XServer.m quartz.c quartzCommon.h xc/programs/Xserver/hw/darwin/quartz/XDarwin.pbproj/: project.pbxproj xc/programs/Xserver/hw/darwin/quartz/xpr/: Imakefile xprScreen.c Added files: xc/lib/apple/: AppleWM.man Imakefile applewm.c applewm.h applewmstr.h xc/programs/Xserver/hw/darwin/quartz/: applewm.c Revision ChangesPath 3.75 +6 -2 xc/lib/Imakefile 3.2805+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.212 +39 -1 xc/config/cf/X11.tmpl 1.38 +5 -3 xc/config/cf/darwin.cf 1.16 +2 -1 xc/config/cf/darwinLib.tmpl 1.18 +3 -2 xc/programs/Xserver/hw/darwin/darwin.h 1.9 +12 -4 xc/programs/Xserver/hw/darwin/quartz/Imakefile 1.10 +11 -2 xc/programs/Xserver/hw/darwin/quartz/XServer.h 1.10 +166 -3xc/programs/Xserver/hw/darwin/quartz/XServer.m 1.10 +10 -1 xc/programs/Xserver/hw/darwin/quartz/quartz.c 1.12 +8 -2 xc/programs/Xserver/hw/darwin/quartz/quartzCommon.h 1.17 +7 -14 xc/programs/Xserver/hw/darwin/quartz/XDarwin.pbproj/project.pbxproj 1.3 +2 -2 xc/programs/Xserver/hw/darwin/quartz/xpr/Imakefile 1.3 +4 -1 xc/programs/Xserver/hw/darwin/quartz/xpr/xprScreen.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/10 14:25:39 Log message: Fix for TVX/YPosOffset options; enhanced SiSCtrl interface Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis.h sis_driver.c sis_opt.c sis_video.c Revision ChangesPath 1.42 +4 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.102 +67 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.25 +64 -34xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.23 +74 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/11 10:41:34 Log message: 370. Fixed support for 64bit PCI bus on 32bit systems (Egbert Eich). 369. Added support for using aliases in the -nolisten option. '-nolisten tcp' aliases to IPv4 and IPv6 (Matthieu Herrb, Egbert Eich). 368. Added fallback Xlib transport layer if IPv6 socket cannot be openend (Egbert Eich). 367. Added missing symbol to the vbeSymbols table in i740 driver (BugzillaR #583, Egbert Eich). 366. Changed scripts containing 'head -1' which is not supported by POSIX 1003.1-2001 any more (Bugzilla #570, #569, Paul Eggert, Egbert Eich). 365. Changed POSIX 1003.1-2001 non-conformant 'sort +2' to 'sort -k 3' with backward compatibility (Bugzilla #568, Paul Eggert). Modified files: xc/config/util/: mkhtmlindex.sh xc/lib/xtrans/: Xtrans.c Xtransint.h Xtranslcl.c Xtransos2.c Xtranssock.c Xtranstli.c xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: xf86pciBus.c xc/programs/Xserver/hw/xfree86/drivers/i740/: i740_driver.c xc/programs/Xserver/hw/xfree86/etc/: Xinstall.sh xc/programs/xterm/unicode/: make-precompose.sh Revision ChangesPath 1.5 +1 -1 xc/config/util/mkhtmlindex.sh 3.33 +11 -3 xc/lib/xtrans/Xtrans.c 3.38 +2 -2 xc/lib/xtrans/Xtransint.h 3.40 +20 -0 xc/lib/xtrans/Xtranslcl.c 3.9 +1 -0 xc/lib/xtrans/Xtransos2.c 3.61 +103 -91 xc/lib/xtrans/Xtranssock.c 3.12 +6 -0 xc/lib/xtrans/Xtranstli.c 3.2803+13 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.72 +15 -2 xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c 1.45 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/i740/i740_driver.c 1.53 +1 -1 xc/programs/Xserver/hw/xfree86/etc/Xinstall.sh 1.2 +1 -1 xc/programs/xterm/unicode/make-precompose.sh ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: )
[EMAIL PROTECTED] CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/06 06:29:43 xc/programs/Xserver/GL/glx/module Update of /home/x-cvs/xc/programs/Xserver/GL/glx/module In directory public.xfree86.org:/tmp/cvs-serv79519/module Log Message: Directory /home/x-cvs/xc/programs/Xserver/GL/glx/module added to the repository ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/13 12:05:59 Log message: remove hpux section as __hppa__ section overrides this anyway thus removes compilation problems. Modified files: xc/programs/Xserver/include/: servermd.h Revision ChangesPath 3.55 +1 -15 xc/programs/Xserver/include/servermd.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/13 14:48:41 Log message: __hppa__ - hpux Modified files: xc/programs/Xserver/include/: servermd.h Revision ChangesPath 3.56 +3 -3 xc/programs/Xserver/include/servermd.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/13 12:12:10 Log message: 373. Be a little more precise about differentiating between active and inactive non-video PCI resources (Marc La France). + small fix to previous commit. Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/common/: xf86pciBus.c Revision ChangesPath 3.2806+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.73 +33 -25xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/07 05:49:15 Log message: Update 358. Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2796+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: Change of behavior of shift+numpad arrow keys (without numlock)
--- Owen Taylor [EMAIL PROTECTED] wrote: On Mon, 2003-08-04 at 09:10, Egbert Eich wrote: Bugzilla 558 requests to change the behavoir of shift+numpad arrow keys In reasonable X GUIs (GNome/KDE), shift + regular arrow key selects text. But if i press shift + numpad arrow key, i get numbers! So the current XKB behavior makes Shift kind of like the lockless version of Numlock, which is insane, IMHO. the numpad keys are *arrow* keys (unless numlock is turned on) by definition. Shift should have no effect on them. The current behavior is contrary to what Windows users are used to (and highly annoying for this reason). I see no reason to have a different behaviour to Microsoft in this regard (seeing as though this can potentially piss off 90+% of users), apart from the sake of wanting to be different (which is not a good reason). Instead of a being just a whinger, I provide this patch (please apply with -l) This requests sounds reasonable so I would like to find out if somebody has a strong opinion on this issue. If not I will commit the supplied fix. Well, the current setup is compatible with the non-XKB behavior documented in section 12.7 of the Xlib reference manual. Doesn't the X Protocol also state that Shift shouldn't cancel CAPS? :P So, there are some compatibility concerns about changing it. You could imagine an application that documented shortcuts with respect to the current system. Yes, I agree. Making it configurable as others have suggested is certainly a good idea. I don't think that is necessarily a killer objection if there are significant usability advantages to a different mapping, but what seems to be missing above (and in the bug report) is more details of *why* this behavior is annoying. While it may be unexpected, it doesn't seem to me that pressing shift+KP_whatever is something you would do by accident. Let me explain: passionate_argument My first keyboard was a mainframe keyboard that just didn't have the gray arrow keys between the main part of the keyboard and the numpad as found on 104-key extended us keyboards. So I got into the habit of using the numpad as arrow keys since they were the only arrow keys on the keyboard. This is also why I expect Shift+KP_arrow to select text because it's a habit I've gotten into (and like smoking, it's hard to quit). So right now, I'm trying to select text and I end up typing numbers instead. Grrr. The other reason is that, imho, the numpad is superior to the gray arrow keys in terms of navigational usability. The Home, End, PgUp, PgDn and Del keys are placed in close proximity to the numpad arrow keys and they are placed logically (rather than the seemingly random layout of the corresponding gray keys). This means that while editing source code, you can just move your right hand to the numpad and quickly jab PgUp, Up, Left and then Delete that extra semicolon all in a split second and then return your hand to the main part of the keyboard and continue touch typing. If you try doing this with the middle, gray keys, you'll find that: a) your fingers will have to move more because the arrows are separated from Insert, Home, Delete, PgUp etc. b) you'll press the wrong keys since they are sooo badly laid out. Someone today at work accused me of missing the point of the numpad. He claims that it is only useful for typing numbers quickly with Numlock on. My opinion is that if you're a touch typist, it is far quicker to press the numbers above the main part of the keyboard. For these usability reasons, I think Shift+KP_key should select text by default. /passionate_argument And I wouldn't expect many people to have learned to use shift+kp_arrows for extending the selection. Yes, I asked around today at work and apparently, normal people keep Numlock on so they never even try pressing shift+kp_arrows. I just think they don't understand the power of the numpad used properly :-) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Post-processing X-server output
you could also create a desktop using OpenGL textures and polygons. something like an Xnest server that uses openGL for windowing. Alex --- Alexander Block [EMAIL PROTECTED] wrote: Hello, I want to post-process the output of an x-server. In detail I want to take e.g. the desktop view of any windowmanager, apply some OpenGL image manipulation functions to it and then send the manipulated image to the graphic card. What is the best way to realize this behavior ? Does there exist any documentation for further readings ? Thanks in advance, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
On 13 Aug 2003, John Dennis wrote: These are issues that go beyond cached vs. uncached memory but can cause symptoms that are similar. Some of the issues may be due to PCI bridges, but I personally do not feel I understand PCI bridge issues well enough to make assertions. (For example bridges have complex rules on queuing transactions, delays, retrys, etc. If a bridge transaction timeouts, as I think is the case with VGA data which seems to be slower, then a bridge is susposed to return all ones which is what I was seeing, but I think this is only for PCI configuration cycles, not regular memory cycles, and here is a good example of where my understanding starts to break down :-( No. In XFree86 4.3 at least, you will _always_ get all ones on master aborts, whether the cycles be for configuration, I/O or memory. The alternative isn't pretty: master aborts would kill the system with no OS recourse, i.e. the so-called (and braindead) hard-fail behaviour. How many bridges are between the CPU and the nVidia? And by bridges I mean PCI-to-PCI bridges, not host bridges. If none, or only AGP (as I suspect is the case here), the only explanation I see is that the nVidia somehow schedules VGA accesses at a lower priority, something I find hard to believe. I'd check if increasing PCI timeouts along the path to the nVidia makes any difference. BTW, I/O port 0x80, on ix86, is the BIOS POST port, and I don't think SlowBCopy() should continue to assume 0x80 remains free for that purpose for very much longer, even on ix86, let alone other archs. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
--- Dr Andrew C Aitchison [EMAIL PROTECTED] wrote: There is a GATOS project to add 3D to those mach64 chips which support 3D; it has never been merged into the XFree86 driver. Xv may or may not have made it into the mach64 driver too. GATOS develops the Xv and video in/out features of ATI cards. the DRI developers have added 3D support for mach64 (rage pro) chips (3D on the older rage I/II/IIc is still not supported). basic Xv support was recently added to xfree86 cvs for mach 64. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: autotooling xrandr
Warren Turkal writes: Is there any chance of upstream acceptance of this type of work? A lot of the utility binaries should be pretty easy to break out the xc hierarchy. This issue is coming up from time to time and I have jet failed to understand the benefit of breaking out things out of the xc hirachy. In fact I can think of a very few things where this may be worthwhile doing. Applications: You can roughly split applications into three groups: 1. system/query: xvidtune, xdpyinfo, xlsfonts, xfd ... 2. applications: xterm, xedit... 3. minor apps/toys: xeyes, oclock, xclock, xcalc ... I would say 1. needs to be shipped with the server core. xrandr belongs in there, too. Most of these apps are meant to either allow for checking the status of the server (for debugging etc) or serve as sample implementations of a functionality which would be absorbed in a GUI base system. Any package in 2 may be worthwhile to be shipped separately. But why bother at all about 3? Libs: The libs can be split up in three cathegories: 1. low level C-bindings for the protocol: libXv, libXcursor, ... 2. Xlib and friends. 3. Toolkits. libXt, libXaw ... I would say 1. needs to be shipped within xc/ as it reflects the version of the extensions shipped with the server. Some people are talking about shipping 2. separately. This could be done, of course, still, I don't see a huge benefit. And why bother about 3 at all? These toolkits are mostly used by legacy applications, they are not under heavy development. The Servers: Building then separately is difficult. To many common parts. The drivers could be built separately but we have an SDK for that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Kaixo!
On Wed, Aug 06, 2003 at 04:38:19PM +0700, Ivan Pascal wrote:
The name was misleading I thought it was the system where capslock
is similar to shift lock (how is that mode named then?)
There is not such option now. In my opinion it is inconvenient because such
key affects all keys (including numpad) and can't be canceled with Shift key
(the behaviour that usualy expected). Nobody requested such option yet.
Well, I used to like that behaviour of typewriter capslock (with shift
key removing the caps lock, and the capslock affecting all keys and
being a shift lock in fact)
And why isn't caps:shift made the default? It doesn't seem to change
anything for other layouts (after some quick tests).
Well. When I two years ago suggested such behavior for CapsLock *you* argued
against it. :-)
I misunderstood it; I tought it was a shiftlock...
: But that behaviour won't be welcome in all cases, for example on French and
: Balgian keyboards there is:
:
:key AE09 {[ccedilla, 9 ]
I tought that it meant that capslock will produce a 9 instead of
a Ccedilla.
1) most of user will not notice any differences but
2) French or Belgian keyboard users will be surprised unpleasantly.
I tested it and it seems to work correctly with caps:shift
(setxkbdmap fr -options caps:shift) ?
And what is exactly the difference between the caps:shift and the currently
default behaviour?
In caps:shift mode if Lock modifier is set Xlib gets from keyboard map
a keysym from the second shift level the same as is chosen when Shift modifier
is set.
?? You said that such behaviour is no more present.
But since CapsLock key doesn't lock Shift modifier but Lock modifier
it allows to distinguish cases CapsLock is active and CapsLock is active and
Shift key is pressed. Also it allows only part of keys (alphabetical ones)
be affected by CapsLock.
So, it is not the second shift level that is chosen; but
- if the second shift level is alphabetic, it is chosen;
- if not, the first shift level is uppercased.
is that right?
In such case, trhe difference between caps:shift and caps:internal
will only be visible in keyboard layouts with alphabetic letters on
unshifted and shifted positions of a same key, but which are not different
cases of the same letters (that is the case of the Swiss keyboard, I'll
test with de_CH...
Mmh, the results are surprising; I see no difference at all between
caps:internal and caps:shift; maybe it is now the default?
in cas of a same key with different letters (I tested with agrave and
otilde) the capslock gives uppercase of Agrave, and with shift it gives
the uppercase of Otilde.
The case of i with and without dots work well; some more tests show this:
- when i/Iabovedot are paired in a same key, Iabovedot is used as the uppercase
of i. Otherwise, I is used as the upepercase.
- when idotless is paired with I, then I is used as the uppercase;
otherwise CapsLock has no effect on that letter and the lowercase
idotless is returned.
In fact the behaviour (with caps:internal or caps:shift, I see no difference
at all) seems to be this one (when capslock is active):
- if position shift 1 is a lowercase letter, and if shift2 is an uppercase
letter; then the symbol in position shift2 is used as the uppercase value,
and the symbol in shift1 as the lowercase value.
that is, pressing the key gives the uppercase. pressing shift-key gives
the lowercase (the letters may be different, eg: [ x, A ] will
work.
- otherwise, for each alphabetic letter, the uppercase letter is returned;
also for symbols in shift2 (eg: [ x, a ] gives X when you press
the key, and A when pressed with shift).
- for non alphabetic letters, the symbol is returned as (CapsLock has
no effect)
Tested with XFree86 4.3; I haven't tested with non latin alphabetic
letters that have upper/lower pairs (greek, cyrillic, armenian).
So it seems the problem is indeed solved; but the behaviour (a quite good
one in fact) is different of what you and I thought it was.
--
Ki ça vos våye bén,
Pablo Saratxaga
http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Italian or Portuguese]
pgp0.pgp
Description: PGP signature
Re: Xrender transforms...
On Sun, 2003-08-10 at 19:05, Carsten Haitzler wrote: The current plan for addressing the second two is to do it as part of the 'libic' library so the same code can be used in the X server and in the software fallbacks for Cairo. I think a couple of people have taken a look at doing that optimization work, though I'm not sure if anybody is working on it actively at this time. libic? hmmm part of Xr? or Xc? i have handy code to optimize paths when you need it. For now it happily lurks at the bottom of all my own software rendering pipelines... :) It used to be libXr depends on libXc depends on libic. But libXr and libXc have now been merged and renamed to 'Cairo'. The hope is certainly that we can pool knowledge to get the ultimately fast code for each platform in libic without having to do it over and over again in different places; right now, everybody has there own favorite set of routines, and as fun as it is to hand-tweak MMX and squeeze out a few extra million pixels per second (I have my own set of such routines around somewhere), it's not really efficient... Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
Matthew Allum writes: *but* if you use a libXcursor theme with every cursor icon fully transparent you can *really* get rid of the cursor, an app changing the cursors appearance just changes it to another 'invisible' cursor. I've not seen this 'technique' discussed before. You can do so for the core cursor also by creating new cursor font with blank glyphs. However if the application specifies it's own cursor you're lost. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xrender transforms...
Would I be correct in the assumption that the only accelerated path for xrender (Bis the identity transform (1:1 scale)? all other transforms are done in (Bsoftware? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (B(as of about a month ago) seem to indicate as much...) (and yes... my drivers (Bare using acceleration... GL definitely is). ? (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
On 13 Aug 2003, John Dennis wrote:
On Tue, 2003-08-12 at 09:49, Egbert Eich wrote:
Mark Vojkovich writes:
NVIDIA root caused this at one point and came to the conclusion
that Linux kernel was incorrectly mapping the memory as cached.
Experiments with setting bit{63} of Base Register fixed the
problem.
OK, this sounds like a very reasonable explanation.
Hmm... It's an interesting observation but I'm a little dubious
because while it may have been true in the past that the Linux
kernel may have failed to map memory as uncached I don't believe
this is true any longer. This assertion has been raised in past with
other ia64 driver bugs and because I'm fortunate enough to sit next to
2 ia64 kernel developers we were able to examine the low level kernel
memory mappings when XFree86 was running and we verified that the MMIO
space was indeed mapped as non-cached. One caveat though, the ia64 kernel
code has been reworked since that exercise so its possible there may
have been a regression. It would be good to verify there has been no
regression, but the kernel engineer who helped is out of the office for
a few days so I'm going to have to wait, but I will post a follow-up.
I spoke with David Mosberger about it before. He was dubious
as well, perhaps to the point that he didn't take it seriously.
Never-the-less, an NVIDIA engineer who's opinion I value came to
the conclusion that what Linux kernel was doing wasn't in line
with what the IA64 specifications described. Hacking things to
bring them in line made the problems go away. All this outb
business is just trying to put a bandaid on the real problem,
which I still believe is due to Linux kernel misprogramming
the caching.
Mark.
What did seem to work was to call outb twice rather than once hence
doubling the delay.
What we were seeing here was that the nv driver on HP ZX2000's needed
the outb Egbert added before entering the SlowBCopy loop. But HP ZX6000's
continued to fault. Doubling the outb's seemed to make the ZX6000's
happy. I'm not comfortable with the solution because it feels like
guessing, but it seems to work and I guess that's the bottom line.
John
P.S. this is how the code now looks:
void
xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
{
#if defined(__ia64__)
outb(0x80, 0x00);
outb(0x80, 0x00);
#endif
while(len--)
{
*dst++ = *src++;
#if !defined(__sparc__) !defined(__powerpc__) !defined(__mips__)
#if defined(__ia64__)
outb(0x80, 0x00);
#endif
outb(0x80, 0x00);
#endif
}
}
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
initial palette wrong.
I've written a driver for an 8-bpp-only device. This is a non-VGA device and runs as a second display alongside another board (in my case, an S3 - also running in 8bpp) The problem I am seeing is that after I first boot-up the screen colors are wrong for my device. I've verified that I am writing the correct colors to the the CLUT, it is that XFree86 is giving me the wrong colors. Now, if I Ctrl-Alt-F1 to a console (which appears on the S3 card) and then Ctrl-Alt-F7 back to the X desktop, now the colors appear correctly. Or if the screen saver kicks in, then when the screen saver exits, my colors will be correct. This is my first X driver, and I am not sure where to start looking. I am not sure how I have caused X to not select the proper colors upon startup. Any pointers on where to start looking would be appreciated. Thanks, Noel. -- A precariously balanced mixture of myopic optimism and rampant paranoia. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
On Wed, 6 Aug 2003, [gb2312] tom wrote: I want to hide the cursor when I using touchscreen in XFree86 4.20, I found that this quesstion have been discussed three times,but no answer.Then,does this means I can't hide the cursor at all? Can xsetroot resolve this problem? I tried but faild.I just can't change the cursor with it. I think that X fundamentally requires that you have exactly one cursor. You can however change the way it looks by changing the cursor font. You can write a cursor font which has an invisible cursor, so the user will not see anything. (I don't remember the syntax, but there several ways of changing cursor font). The only problem I see with that is that any application can change the cursor font, and some applications use their own font, so you can't guarantee that a cursor will never appear. However this will only happen when such an application has focus, so should not be a major problem. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
cvsup problems
I had been using cvsup successfully to sync with the XFree86 CVS tree,
but after returning from vacation it has started to fail with what
appears to be an internal error in the client.
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
use option @M3stackdump to get a stack trace
Aborted
I will include the stackdump below and my config file, I didn't see
anything in the stackdump that meant anything to me. I did update my
cvsup client to the latest and I checked the cvsup web site looking for
possible causes/solutions. The only thing I found was if you DNS could
not reverse map your ip address you could get a similar failure, but my
DNS server can do the reverse mapping fine. So I'm a bit perplexed,
anybody have a suggestion as to what may be the problem. Like I said,
this has all been working fine previously. The only thing I can think of
is that my host machine did have some libraries updated but cvsup is
statically linked so I don't think that could explain the sudden
failure.
$ cvsup @M3stackdump cvsup.xfree86
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
- STACK DUMP ---
PC SP
0x80c9c18 0xbfffe130 Crash + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTProcess.m3
0x80c8d6f 0xbfffe144 EndError + 0x3f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80c8b74 0xbfffe168 FatalErrorI + 0x34 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80cd46a 0xbfffe17c SegV + 0x2a in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/LINUXLIBC6/RTSignal.m3
0x80eafb8 0xbfffe4f0
0x8106e0c 0xbfffe538
0x810694b 0xbfffe5fc
0x8106f36 0xbfffe628
0x8101ef9 0xbfffe634
0x810694b 0xbfffe6f8
0x8101772 0xbfffe758
0x8101dff 0xbfffe774
0x811b2d7 0xbfffe78c
0x8102c9d 0xbfffe7e4
0x810285c 0xbfffe83c
0x80a7e8e 0xbfffea0c CanGet + 0x16e in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/POSIX/MachineIDPosix.m3
0x80a7238 0xbfffea28 Init + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a73b1 0xbfffea94 New + 0x81 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a69a1 0xbfffead0 RandomSeed + 0x41 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x80a6876 0xbfffeae4 Init + 0x46 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x8066467 0xbfffeb1c New + 0x87 in
/usr/local/src/cvsup/cvsup-snap-16.1d/client/src/BackoffTimer.m3
0x806895b 0xb0bc
0x80c869f 0xb0d4 RunMainBodies + 0x6f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTLinker.m3
-- EXCEPTION HANDLER STACK -
0xbfffe85c RAISES {}
0xbfffea20 RAISES {}
0xbfffea60 LOCK mutex = 0x81842ec
0xbfffea6c RAISES {}
0xbfffeac8 RAISES {}
0xbfffec34 TRY-FINALLY proc = 0x8068d73 frame = 0xb0bc
0xbfffecfc TRY-EXCEPT {Main.Error}
0xbfffee68 TRY-EXCEPT {Thread.Alerted}
Aborted
Here is my cvsup config file:
*default release=cvs host=anoncvs.xfree86.org
base=/home/boston/jdennis/.cvsup
*default prefix=/home/boston/jdennis/src/xfree86 delete use-rel-suffix
*default compress
*default tag=.
xc-all
doctools-all
contrib-all
xtest-all
utils-all
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
On Wed, 6 Aug 2003, [gb2312] tom wrote: I want to hide the cursor when I using touchscreen in XFree86 4.20,I found that this quesstion have been discussed three times,but no answer.Then,does this means I can't hide the cursor at all?Can xsetroot resolve this problem?I tried but faild.I just can't change the cursor with it. Any idea? Thank you. Roy This has been discussed and answered many times. The answer is no. 1) X always must always have a cursor. 2) The cursor's appearence depends on the window it is over. You can change the root window cursor with xsetroot, and if another window doesn't specify a cursor, it inherits the cursor from it's parent. If no parent all the way down to the root window has specified a cursor then that window gets the root window cursor. But if windows have specified cursors explicitly, there's nothing you can do about that. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, 10 Aug 2003, Carsten Haitzler wrote: On Sun, 10 Aug 2003 05:59:54 +0100 Alan Hourihane [EMAIL PROTECTED] babbled: On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers(as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, and the vmware driver has it too. But that's it. I guess nvidia do some acceleration in their binary drivers though, as you've probably found. But it's bad to assume other drivers have xrender acceleration. I think the thing that's holding other drivers up in getting furthur xrender acceleration is that there's no test suite to check that the driver is doing the right thing. I think Keith Packard mentioned he had intern's working on a test suite a while ago, but nothing has materialized as far as I know. hmmm - well i could write a performance suite here... if that helps. so far as in my other e-mail, the hardware acceleration provides by the nvidia drivers so far manages to be 1/35th the speed of my own mmx asm blending routines... this is blending with 1:1 scaling (no transform). You're not hitting hardware paths. If you want to see this stuff in hardware there's going to need to be a correctness test suite. I'm already accelerating more than I can test. That worries me, and is why render acceleration is off by default in recent NVIDIA drivers. i just tested a quick scaling test and the software routines i have are 41 times faster than xrender... there is something suspicious here... a quick rundown: my software routines are in imlib2. machine is amd 1.7ghz gfx is nvidia gf4 4400ti 128mb NVAGP is set to 0 cause it manages to lock up my kernel regularly :( this is xfree 4.3.0 nvidia drivers: NVIDIA_kernel-1.0-4191 NVIDIA_GLX-1.0-4191 I thought you said you were using recent drivers. There's been two releases since then. There are known render bugs in 4191. well there goes my plans for a project to do an xrender display engine... opengl still is the big winner :) OpenGL reflects what the hardware can do, and has a compliance test suite. RENDER doesn't reflect hardware capabilities very well (it reflects what end users wanted to see in an API) and there's no compliance tests. Stick with OpenGL. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch to disable vt switching on hurd
I cannot find any info about [EMAIL PROTECTED] on the xfree86.org website.
Therefore, I will post this here. This patch is to disable vt switching on
hurd as hurd does not support the VT_ACTIVATE ioctl. Once again, this patch
comes from the debian patch set, and I simply ported it to the current
snapshot.
This patch from Robert Millan.
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.old 2003-04-11
15:03:23.0 +0200
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c 2003-04-11
15:04:55.0 +0200
@@ -320,6 +320,9 @@
}
break;
#if !defined(__SOL8__) !defined(__UNIXOS2__) (!defined(sun) ||
defined(i386))
+#ifndef VT_ACTIVATE
+#warning missing VT_ACTIVATE ioctl; vt switching is disabled.
+#else
case ACTION_SWITCHSCREEN:
if (VTSwitchEnabled !xf86Info.dontVTSwitch arg) {
int vtno = *((int *) arg);
@@ -355,6 +358,7 @@
ErrorF(Failed to switch consoles (%s)\n, strerror(errno));
}
break;
+#endif /* VT_ACTIVATE */
#endif
case ACTION_MESSAGE:
{
--
Treasurer, GOLUM, Inc.
http://www.golum.org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Fri, Aug 08, 2003 at 03:53:00PM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 10:14:58AM +0200, Sven Luther wrote: On Fri, Aug 08, 2003 at 02:21:28AM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 06:41:58AM +0200, Sven Luther wrote: On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. I usually update the date in xf86Date.h when committing. That gives some indication, and is printed on the line after the version in the log file. I don't think it matters that much personally, but if I wanted to achieve something like this for my own checkouts, I'd use a script that did something like this: #!/bin/sh date=`date` cvs co xc echo #undef XFree86CustomVersion xc/config/cf/host.def echo #define XFree86CustomVersion \$date\ xc/config/cf/host.def I'm not sure how you'd make cvs automatically create a reliable date for all possible ways of checking out the source. Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Do you have a specific example? Preferrably one that doesn't unnecessarily complicate things. Err, i was thinking of putting an #define XFree86CustomVersion $Date per default in one of the .cf files, and erase this lines when doing the export for the snapshots. Either by hand after having done the export, or with a special option to cvs export. I believe you would have to use another variable ($CheckoutDate ?) which you would usually have set to $Date, and which you would then set to nothing when doing the export. I believe there is a cvs option that can override one of the keyword expansions, but i am not familiar enough with cvs to tell you which, and if it doesn't work, it can be done by hand. Now, the problem is probably that the $Date will give a string prefixed by the $Date: string, and include the hour probably also, so maybe some kind of postreatment is needed, but i don't know if it is feasible in cpp. It was just an idea anyway. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
On 11 Aug 2003 17:55:50 -0400 John Dennis [EMAIL PROTECTED] wrote: Now it seems to me that using extra machine instructions (asm version) or no-op IO is inherently a risky solution to this problem. It would appear there is some interval of time one must wait for individual VGA bus transactions complete. The number of extra machine instructions and/or no-op IO to insert seems to be purely a guess and highly dependent on the processor and the bus its sitting on. I/O space port accesses have well defined strict timing requirements. If I remember correctly, these timing requirements are specifically mentioned in the PCI specifications. Therefore my understanding is that you can depend upon them taking a specific amount of time to complete. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
on Wed, Aug 06, 2003 at 11:14:07AM -0700, Mark Vojkovich wrote: This has been discussed and answered many times. The answer is no. 1) X always must always have a cursor. 2) The cursor's appearence depends on the window it is over. You can change the root window cursor with xsetroot, and if another window doesn't specify a cursor, it inherits the cursor from it's parent. If no parent all the way down to the root window has specified a cursor then that window gets the root window cursor. But if windows have specified cursors explicitly, there's nothing you can do about that. *but* if you use a libXcursor theme with every cursor icon fully transparent you can *really* get rid of the cursor, an app changing the cursors appearance just changes it to another 'invisible' cursor. I've not seen this 'technique' discussed before. -- Matthew ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
At 10:05 PM +0200 8/11/03, Michel Dänzer wrote: On Mon, 2003-08-11 at 05:29, Alex Deucher wrote: well, yeah... I only mention if in case anyone out there feels like adding basic transparency support to a driver. the driver could then register it's own version of the Xtransparency extension so that apps that were aware could make use of it. I'm not sure this is possible without the driver replacing significant parts of the core server code. I've thought about toying with it on radeon, but I don't know how to tickle the hardware to make it do that... It looks like the 3D engine would have to be used, the 2D engine doesn't seem to do any blending (or scaling, for that matter). One place that we could add this support rather easily is with Mac OS X's rootless mode. There are people writing Mac OS X-specific variants of X window managers that would like to use this kind of feature. In the past they've had to use custom hacks to the X server. If XTransparency/XOpacity became something closer to a defacto standard I would be interested in adopting it. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Sat, Aug 09, 2003 at 12:32:02PM -0400, David Dawes wrote: On Sat, Aug 09, 2003 at 05:41:25PM +0200, Sven Luther wrote: On Fri, Aug 08, 2003 at 03:53:00PM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 10:14:58AM +0200, Sven Luther wrote: Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Do you have a specific example? Preferrably one that doesn't unnecessarily complicate things. Err, i was thinking of putting an #define XFree86CustomVersion $Date per default in one of the .cf files, and erase this lines when doing the export for the snapshots. Either by hand after having done the export, or with a special option to cvs export. I believe you would have to use another variable ($CheckoutDate ?) which you would usually have set to $Date, and which you would then set to nothing when doing the export. I believe there is a cvs option that can override one of the keyword expansions, but i am not familiar enough with cvs to tell you which, and if it doesn't work, it can be done by hand. I don't think it is either necessary or desirable to make exceptions for snapshots. Snapshots are defined simply by tags, and not by the way they are later checked out or exported. Yep, manual manipulation is not nice and will most assuredly cause mistakes some days or others. Now, the problem is probably that the $Date will give a string prefixed by the $Date: string, and include the hour probably also, so maybe some kind of postreatment is needed, but i don't know if it is feasible in cpp. It was just an idea anyway. Well, I asked for a specific example because I can't think of one that will give consistent results without intruding on the commit process. The problem with $Date is that it expands to the commit date of the file, not the checkout date (or the -D date). If there was a Effectively, i didn't think of that. This would not work i guess. solution like this, it could go in xf86Date.h, and it wouldn't require exceptions for the snapshots/releases. What about using the date of the CHANGELOG file ? The only thing I can see that would give a consistent and predictable result in all cases (cvs co, cvs co -D date, cvs -r tag) would be to have xf86Date.h automatically modified with every single commit. This wouldn't be the checkout date, but a date representing the last commit in the checked out tree. The only ways I can think of doing that right now would cause more inconvenience than I think it's worth, but if someone has a specific tested solution, with documented impact and side-effects, let me know. Alternatively, we could use the almost same effect by somehow having the XFree86.0.log include the latest CHANGELOG entry number. This could be done by some preprocessing. If the date in the first XFree86 line is full, and we have a normal release, or it is marked as xx or some other sign, and we are facing a CVS checkout. In this case, we use the first number in the line just below the XFree86 line, and embed that number in the log message writing code. A little sed or awk or whatever processing in the Imakefile should produce the desired effect at build time. This would enable us to easily spot when the tree was checked out, and would not need us to fool with CVS stuff or so. Naturally this supposes that the CHANGELOG file is updated regularly between comits, but this is the case anyway. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
You might want to create a bug in bugzilla (bugs.xfree86.org) and attach the patches there. that way people can comment on the patches and the committers usually post a comment there if they decide to include it. Alex --- Warren Turkal [EMAIL PROTECTED] wrote: BTW, if I submit a patch to patches@, will I get a notification of acceptance or rejection? Warren Turkal __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xtrans: -nolisten with aliases
attached patch is an alternative solution for the nolisten handling
of aliases.
It takes the aliases from a list explicitely thus allowing a finer
control than by checking for the equality of the interface specific
functions.
Any opinions?
Egbert.
Index: Xtrans.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.32
diff -u -r3.32 Xtrans.c
--- Xtrans.c24 Jul 2003 13:50:18 - 3.32
+++ Xtrans.c7 Aug 2003 14:35:40 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtrans.c,v 3.31 2003/07/20 16:12:15 tsi Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtrans.c,v 3.32 2003/07/24 13:50:18 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -779,6 +779,7 @@
{
Xtransport *trans;
+ int i = 0, ret = 0;
if ((trans = TRANS(SelectTransport)(protocol)) == NULL)
{
@@ -787,9 +788,16 @@
return -1;
}
-
+ if (trans-flags TRANS_ALIAS) {
+ if (trans-nolisten)
+ while (trans-nolisten[i]) {
+ ret |= TRANS(NoListen)(trans-nolisten[i]);
+ i++;
+ }
+ }
+
trans-flags |= TRANS_NOLISTEN;
- return 0;
+ return ret;
}
int
Index: Xtransint.h
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtransint.h,v
retrieving revision 3.37
diff -u -r3.37 Xtransint.h
--- Xtransint.h 4 Aug 2003 10:32:21 - 3.37
+++ Xtransint.h 7 Aug 2003 14:45:50 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.36 2003/07/24 13:50:19 eich Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.37 2003/08/04 10:32:21 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -226,7 +226,7 @@
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
-
+char **nolisten;
XtransConnInfo (*OpenCOTSServer)(
struct _Xtransport *, /* transport */
char *, /* protocol */
Index: Xtranslcl.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtranslcl.c,v
retrieving revision 3.39
diff -u -r3.39 Xtranslcl.c
--- Xtranslcl.c 26 Nov 2002 01:12:30 - 3.39
+++ Xtranslcl.c 7 Aug 2003 15:07:03 -
@@ -2495,6 +2495,21 @@
* call to SelectTransport() in Xtrans.c.
*/
+#ifdef TRANS_SERVER
+static char * local_aliases[] = {
+# ifndef sun
+ pts,
+# endif
+ named,
+# ifndef sun
+# ifndef SCO325
+ isc,
+# endif
+ sco,
+# endif
+ NULL };
+#endif
+
Xtransport TRANS(LocalFuncs) = {
/* Local Interface */
local,
@@ -2503,6 +2518,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ local_aliases,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2544,6 +2560,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2585,6 +2602,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2626,6 +2644,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2665,6 +2684,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
Index: Xtransos2.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtransos2.c,v
retrieving revision 3.8
diff -u -r3.8 Xtransos2.c
--- Xtransos2.c 25 Mar 2003 03:38:32 - 3.8
+++ Xtransos2.c 7 Aug 2003 14:58:09 -
@@ -833,6 +833,7 @@
TRANS(Os2OpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(Os2OpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
Index: Xtranssock.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 3.60
diff -u -r3.60 Xtranssock.c
--- Xtranssock.c24 Jul 2003 13:50:19 - 3.60
+++ Xtranssock.c7 Aug 2003 14:50:46 -
@@ -27,7 +27,7 @@
from the copyright holders.
*/
-/* $XFree86: xc/lib/xtrans/Xtranssock.c,v 3.59 2003/07/18 15:39:48 tsi Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtranssock.c,v 3.60 2003/07/24 13:50:19 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio,
Re: pls help a newbie:how XFree86 wrap functions in libc
Rafa? Rzepecki wrote: On Tuesday 12 of August 2003 05:48, Tao, Qian (陶� IES) wrote: I'm sorry,my english is not good I want to add some code to xc/program/Xserver/hw/xfree86/input/mouse/mouse.c I have to call some functions in libc. To my surprise,fprintf wok well,but,gettimeofday doesn't work When I start my server,the server says:This should not happen;An unresolved function was called;Fatal server error I just cannot understand how XFree86 wrap functions in libc. Pls help me, and you can give me some docs What kind of functionality are you exactly trying to add? IMHO you should not call libc functions directly in drivers, especially those manipulating files. It's bad practice, and AFAIK it's security breach, because drivers work as root. I'm working on mouse.c personally, trying to add cordless mouse status reporting and some cordless-specific runtime control, such as RF channel switching. Unfortunately the only way I've found to communicate with userland is using shared memory (vide synaptics driver). But it has a drawback that it cannot be used to communicate with remote display, as it's not using the X protocol. One could try to communicate using LED feedbacks (like in citron driver), but there seem to be no way to manipulate feedbacks of the core pointer, so it's limited to extension devices. Or maybe I am mistaken, and there is a way? Could someone more familiar with input drivers clarify it? I'm not aware of any restriction with the mouse driver. But I think the LED feedback is very limited, both in terms of packet size, and in terms of reply. Possibly, we can activate StringFeedback and at least get larger packets, (it's a one-line patch), but until we do something using Atoms, you will suffer due endianness/sizeof intrinsics/padding issues. Excuse my stupidity, why are you not using GetTimeInMillis? OTOH, we could wait for the message passing in Xext to extend to input drivers, as I have read somewhere there is someone working on it. How's progress with that? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Mon, 11 Aug 2003, Jakub Jelinek wrote: On Sun, Aug 10, 2003 at 07:06:58PM -0500, Warren Turkal wrote: @@ -1003,6 +993,8 @@ break; } +r128_drm_page_size = getpagesize(); + sysconf (_SC_PAGESIZE) is the standardized way of querying page size. ... but non-portable to pre-standard systems. getpagesize() is provided on all platforms by the loader server's core binary. It is also available in the static server for systems that don't provide it. The one in libc is used if provided. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fix for Xlib with ipv6 support on ipv4 only systems
Mark Vojkovich writes: On Fri, 8 Aug 2003, Egbert Eich wrote: Mark Vojkovich writes: Out of curiosity. Is the ipv6 supposed to be working properly now? Last time I updated, I noticed that remote operation was broken. That is, Xlib was unable to connect to a remote system (I assume it didn't work with internet sockets anymore, but unix domain sockets still worked). Hm, what did you do? I never had any issues connecting to a remote system. Neither thru ipv4 nor ipv6. The only thing I noticed was that there are still issues with authetication for ipv6. For mu tests I used the -ac option to get around this. Did you get any error messages? The server is on dhcp-178-150:0 and is slightly newer than XFree86 4.3, but is not from any recent CVS. It is pre-ipv6 support. It has access control disabled (xhost +). The client is on dhcp-178-251 and is using fairly recent libraries from CVS. The DISPLAY is set to dhcp-178-150:0.0 and I get: _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/dhcp-178-150:0 xterm Xt error: Can't open display: dhcp-178-150:0.0 I find that: 1) The 4.3 libraries can connect to a CVS server. 2) CVS libraries can connect to a CVS server. 3) CVS libraries cannot connect to a 4.3 server. It looks like the same problem Andrew had. Your Xlib is built with IPv6 support, but your kerneld doesn't support it. One of the patches I've posted is supposed to take care of it. I still have a huge backlog of email to read. If noone has objected so far I will commit my fixes later. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Mon, Aug 11, 2003 at 07:06:01AM +0200, Jakub Jelinek wrote:
On Sun, Aug 10, 2003 at 07:06:58PM -0500, Warren Turkal wrote:
@@ -1003,6 +993,8 @@
break;
}
+r128_drm_page_size = getpagesize();
+
sysconf (_SC_PAGESIZE)
is the standardized way of querying page size.
getpagesize() as invoked from a driver is aliased to xf86getpagesize(),
which does this:
#if defined(linux)
#define HAS_SC_PAGESIZE
#define HAS_GETPAGESIZE
#elif defined(CSRG_BASED)
#define HAS_GETPAGESIZE
#elif defined(DGUX)
#define HAS_GETPAGESIZE
#elif defined(sun) !defined(SVR4)
#define HAS_GETPAGESIZE
#endif
#ifdef XNO_SYSCONF
#undef _SC_PAGESIZE
#endif
...
int
xf86getpagesize()
{
static int pagesize = -1;
if (pagesize != -1)
return pagesize;
#if defined(_SC_PAGESIZE) || defined(HAS_SC_PAGESIZE)
pagesize = sysconf(_SC_PAGESIZE);
#endif
#ifdef _SC_PAGE_SIZE
if (pagesize == -1)
pagesize = sysconf(_SC_PAGE_SIZE);
#endif
#ifdef HAS_GETPAGESIZE
if (pagesize == -1)
pagesize = getpagesize();
#endif
#ifdef PAGE_SIZE
if (pagesize == -1)
pagesize = PAGE_SIZE;
#endif
if (pagesize == -1)
FatalError(xf86getpagesize: Cannot determine page size\n);
return pagesize;
}
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
patch for sun type6 keyboard support from debian patches
This is a patch to add sun type6 keyboard support. It comed from the patches
debian puts on the 4.3.0 source before building the packages. I think this
type of info should be passed to the XFree86 core so that everyone who uses
XFree86 can take advantage of this.
Warren Turkal
--- xc/programs/xkbcomp/keycodes/sun~ 2002-10-31 02:42:01.0 -0500
+++ xc/programs/xkbcomp/keycodes/sun2002-10-31 02:45:50.0 -0500
@@ -301,6 +301,152 @@
indicator 1 = Num Lock;
};
+xkb_keycodes type6 {
+minimum= 8;
+maximum= 255;
+
+TLDE = 49;
+AE01 = 10;
+AE02 = 11;
+AE03 = 12;
+AE04 = 13;
+AE05 = 14;
+AE06 = 15;
+AE07 = 16;
+AE08 = 17;
+AE09 = 18;
+AE10 = 19;
+AE11 = 20;
+AE12 = 21;
+BKSP = 22;
+
+TAB = 23;
+AD01 = 24;
+AD02 = 25;
+AD03 = 26;
+AD04 = 27;
+AD05 = 28;
+AD06 = 29;
+AD07 = 30;
+AD08 = 31;
+AD09 = 32;
+AD10 = 33;
+AD11 = 34;
+AD12 = 35;
+RTRN = 36;
+
+CAPS = 66;
+AC01 = 38;
+AC02 = 39;
+AC03 = 40;
+AC04 = 41;
+AC05 = 42;
+AC06 = 43;
+AC07 = 44;
+AC08 = 45;
+AC09 = 46;
+AC10 = 47;
+AC11 = 48;
+
+LFSH = 50;
+AB01 = 52;
+AB02 = 53;
+AB03 = 54;
+AB04 = 55;
+AB05 = 56;
+AB06 = 57;
+AB07 = 58;
+AB08 = 59;
+AB09 = 60;
+AB10 = 61;
+RTSH = 62;
+BKSL = 51;
+
+LALT = 64;
+LCTL = 37;
+SPCE = 65;
+ALGR = 113;
+alias RALT = ALGR;
+
+LMTA = 115;
+RMTA = 116;
+COMP = 117;
+
+ESC = 9;
+FK01 = 67;
+FK02 = 68;
+FK03 = 69;
+FK04 = 70;
+FK05 = 71;
+FK06 = 72;
+FK07 = 73;
+FK08 = 74;
+FK09 = 75;
+FK10 = 76;
+FK11 = 95;
+FK12 = 96;
+
+PRSC = 111;
+SCLK = 78;
+PAUS = 110;
+
+INS = 106;
+HOME = 97;
+PGUP = 99;
+DELE = 107;
+END = 103;
+PGDN = 105;
+
+UP = 98;
+LEFT = 100;
+DOWN = 104;
+RGHT = 102;
+
+NMLK = 77;
+KPDV = 112;
+KPMU = 63;
+KPSU = 82;
+
+KP7 = 79;
+KP8 = 80;
+KP9 = 81;
+KPAD = 86;
+
+KP4 = 83;
+KP5 = 84;
+KP6 = 85;
+
+KP1 = 87;
+KP2 = 88;
+KP3 = 89;
+KPEN = 108;
+
+KP0 = 90;
+KPDL = 91;
+
+STOP = 222;
+AGAI = 223;
+PROP = 224;
+UNDO = 225;
+FRNT = 226;
+COPY = 227;
+OPEN = 228;
+PAST = 229;
+FIND = 230;
+CUT = 231;
+
+HELP = 232;
+
+MUTE = 165;
+VOL- = 159;
+VOL+ = 158;
+POWR = 160;
+
+indicator 1 = Caps Lock;
+indicator 2 = Num Lock;
+indicator 3 = Scroll Lock;
+};
+
xkb_keycodes type4_euro {
include sun(type4)
LSGT = 131;
@@ -311,6 +457,11 @@
LSGT = 131;
};
+xkb_keycodes type6_euro {
+include sun(type6)
+LSGT = 94;
+};
+
xkb_keycodes type5_se {
minimum= 8;
--- xc/programs/xkbcomp/symbols/sun/us~ 2002-10-31 02:53:25.0 -0500
+++ xc/programs/xkbcomp/symbols/sun/us 2002-10-31 03:10:18.0 -0500
@@ -34,8 +34,7 @@
key TLDE { [ grave, asciitilde ], [ acute ] };
key AC11 { [ apostrophe, quotedbl], [ acute ] };
-key RTSH { [ Shift_R ] };
-
+key RTSH { [ Shift_R ] };
key LALT { [ Alt_L ] };
key ALGR { [ Mode_switch ] };
key LMTA { [ Meta_L ] };
@@ -95,19 +94,19 @@
key KP1 { [ KP_End,KP_1], [ F33 ] };
key KP2 { [ KP_Down, KP_2], [ F34 ] };
key KP3 { [ KP_Next, KP_3], [ F35 ] };
-key KPEN { [ KP_Enter] };
+key KPEN { [ KP_Enter] };
key KP0 { [ KP_Insert, KP_0] };
key KPDL { [ KP_Delete, KP_Decimal ]};
// End Keypad section
// begin modifier mappings
-modifier_map Shift { Shift_R };
-modifier_map Mod1 { Meta_L, Meta_R };
-modifier_map Mod2 { Alt_L };
-modifier_map Mod3 { Mode_switch };
-modifier_map Mod4 { Num_Lock };
-modifier_map Mod5 { F13, F18, F20 };
+modifier_map Shift { Shift_R };
+modifier_map Mod1 { Meta_L, Meta_R };
+modifier_map Mod2 { Alt_L };
+modifier_map Mod3 { Mode_switch };
+modifier_map Mod4 { Num_Lock };
+modifier_map Mod5 { F13, F18, F20 };
};
hidden partial function_keys xkb_symbols broken_openlook_map {
@@ -137,7 +136,7 @@
key TLDE { [ grave, asciitilde ], [ acute ] };
key AC11 { [ apostrophe, quotedbl], [ acute ] };
-key RTSH { [ Shift_R ] };
+key RTSH { [ Shift_R ] };
key LALT { [ Alt_L ] };
key ALGR { [
Re: Post-processing X-server output
On Thu, Aug 14, 2003 at 11:07:46AM +0200, Alexander Block wrote: Thanks for your quick answer. Where can I get more information about the shadowfb driver (include file, library, API doc) ? In the X source file ? I don't know if the design document speaks about it, but it is rather straightforward to implement. The source code of shadowfb is in : xc/programs/Xserver/hw/xfree86/shadowfb And contain the following header file : /* $XFree86: xc/programs/Xserver/hw/xfree86/shadowfb/shadowfb.h,v 1.4 * 2003/02/18 19:10:35 alanh Exp $ */ #ifndef _SHADOWFB_H #define _SHADOWFB_H #include xf86str.h /* * User defined callback function. Passed a pointer to the ScrnInfo * struct, * the number of dirty rectangles, and a pointer to the first dirty * rectangle * in the array. */ typedef void (*RefreshAreaFuncPtr)(ScrnInfoPtr, int, BoxPtr); /* * ShadowFBInit initializes the shadowfb subsystem. refreshArea is a * pointer * to a user supplied callback function. This function will be called * after * any operation that modifies the framebuffer. The newly dirtied * rectangles * are passed to the callback. * * Returns FALSE in the event of an error. */ Bool ShadowFBInit ( ScreenPtr pScreen, RefreshAreaFuncPtr refreshArea ); /* * ShadowFBInit2 is a more featureful refinement of the original * shadowfb. * ShadowFBInit2 allows you to specify two callbacks, one to be called * immediately before an operation that modifies the framebuffer, and * another * to be called immediately after. * * Returns FALSE in the event of an error */ Bool ShadowFBInit2 ( ScreenPtr pScreen, RefreshAreaFuncPtr preRefreshArea, RefreshAreaFuncPtr postRefreshArea ); #endif /* _SHADOWFB_H */ If you need additional info, look at how the other drivers implement it. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
some mach64 mobility chips had a second crtc that was never supported. same thing with rage 128. I'm not sure about the accel engine on mach32, but I think mach64 is fairly well accelerated. If you want the databooks, register as a developer with ATI and request them (be patient). Also the old xfree86 3.x servers are a good reference for old cards. Alex --- [EMAIL PROTECTED] wrote: Hi, Can anyone tell me how good a job the old Mach32 and Mach64 servers did of taking advantage of the hardware capabilities of their respective silicon engines? Put another way, were there capabilities in the silicon that we did not use? If there are transistors not pulling their weight, are docs available to remedy the situation should one be so inclined to do so? Thanks, kevin __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
TAYLOR MUST GO
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: blanking of non-refreshing windows
On Wed, Aug 13, 2003 at 11:39:08AM +0200, Michel Dänzer wrote: On Tue, 2003-08-12 at 16:49, Andy Isaacson wrote: A more useful solution would be to schedule an event a few dozen milliseconds (say, 20 or 100 ms) in the future, which upon arrival would check that the window has been refreshed and, if not, write it with the background color, on the assumption that if the app hasn't refreshed yet, it's not going to anytime soon. Ideally this event would only be handled when the X server is otherwise idle. All this effort for a band aid? A different basic approach like in XDarwin or XDirectFB makes more sense to me. I'm not familiar with how those two X servers operate, so could you help me out by explaining? How do they handle window obscures? How is it different from X11's BackingStore? Note that BS is turned off by default precisely because it's frequently a pessimisation -- too often the BS pixmap is too old, and the X server writes it to the framebuffer only to have it overwritten by the app as soon as it's scheduled. Why are XDarwin and XDirectFB's approaches better? -andy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
Since this problem comes up quite frequently I have made an article at: http://xfree86.linuxwiki.org/AdvancedTopicsFAQ about how to do this. Egbert. Andrew C Aitchison writes: On Wed, 6 Aug 2003, [gb2312] tom wrote: I want to hide the cursor when I using touchscreen in XFree86 4.20, I found that this quesstion have been discussed three times,but no answer.Then,does this means I can't hide the cursor at all? Can xsetroot resolve this problem? I tried but faild.I just can't change the cursor with it. I think that X fundamentally requires that you have exactly one cursor. You can however change the way it looks by changing the cursor font. You can write a cursor font which has an invisible cursor, so the user will not see anything. (I don't remember the syntax, but there several ways of changing cursor font). The only problem I see with that is that any application can change the cursor font, and some applications use their own font, so you can't guarantee that a cursor will never appear. However this will only happen when such an application has focus, so should not be a major problem. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: autotooling xrandr
Ar an 13ú lá de mí 8, scríobh Egbert Eich : Bug #72 has not been committed as it is not yet clear what your final conclusions are. Perhaps a comment to that effect could have been added to the bug? Anyway, as I said, I don't have the free time any more. If anyone else wants to take that on, go for it, but if not, close it. -- These are the prettiest looking witnesses we have had in a long time. I imagine you are all married. If not, you could be if you wanted to be. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
There is a GATOS project to add 3D to those mach64 chips which support 3D; it has never been merged into the XFree86 driver. Xv may or may not have made it into the mach64 driver too. GATOS develops the Xv and video in/out features of ATI cards. the DRI developers have added 3D support for mach64 (rage pro) chips (3D on the older rage I/II/IIc is still not supported). basic Xv support was recently added to xfree86 cvs for mach 64. One DRI developer makes a Xv/DRI merged driver available as well on his website (can't remember where off of the top of my head). This is the driver I use for my Mach64 and I think also the driver with the best support for the Mach64 chipsets. It would be very nice to see the Xv+DRI merged drivers made available for X. If only some important soul within the XFree86 project with the correct privileges has time to oversee the mergin off code into the XFree86 main branch how nice that would be! James ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
Alan Hourihane wrote: On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, It's disabled because it doesn't work as Render. SiS hardware only supports one alpha per operation (and not per pixel). I kept the code within #if 0s for possibly upcoming XAA transparency support. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
autotooling xrandr
As an excercise, I autotooled xrandr. It was easy for xrandr, and I expect it would be easy for a number of other small utility programs in the X distribution. The source for this experiment is located at http://ss.kicks-ass.org/~wt/development/xfree86-autotool/xrandr/. Are there any efforts to autotool X as a whole? If so, who do I contact? If not, I would like to start an effort if there is any interest upstream acceptance. It would definitely allow for an easier way to modularize the X source. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
John Dennis writes: Now it seems to me that using extra machine instructions (asm version) or no-op IO is inherently a risky solution to this problem. It would appear there is some interval of time one must wait for individual VGA bus transactions complete. The number of extra machine instructions and/or no-op IO to insert seems to be purely a guess and highly dependent on the processor and the bus its sitting on. The fact this works on one class of machines and not another does not surprise me at all. No, I've tried this already. The out() on port 0x80 did some flushing appearantly which made things work. Note that I arrived at this solution purely by guessing. There may be a better fix for that. 3) Can we come up with a scheme that introduces a known timing delay (e.g. usleep) such that we don't have to make arbitrary guesses as to how much no-op is needed in the loop on a given system? I don't think so. See above. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Solution for 855GM video memory issue
Hi, I made a small webpage for 855patch that summarizes the important information: http://www.chzsoft.com.ar/855patch.html Christian ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, Aug 10, 2003 at 05:59:54AM +0100, Alan Hourihane wrote: On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, and the vmware driver has it too. But that's it. I guess nvidia do some acceleration in their binary drivers though, as you've probably found. But it's bad to assume other drivers have xrender acceleration. I think the thing that's holding other drivers up in getting furthur xrender acceleration is that there's no test suite to check that the driver is doing the right thing. I think Keith Packard mentioned he had intern's working on a test suite a while ago, but nothing has materialized as far as I know. And there is no documentation whatsoever on what to do. And Keith has been telling me each time i asked him that render was not yet ready and that i should wait. Last time was a year or so ago though, so ... Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
Hi,
Well, I used to like that behaviour of typewriter capslock (with shift
key removing the caps lock, and the capslock affecting all keys and
being a shift lock in fact)
Unfortunately I can't imagine how to make such mode (affects all keys but
Shift cancels Caps ) in XKB.
I tested it and it seems to work correctly with caps:shift
(setxkbdmap fr -options caps:shift) ?
Yes, it works! And it's a big surprise to me.
Of course now I understand why it happens but I didn't guess until you wrote
about it. :-)
Let me explain.
1) Xlib converts a keycode to a keysym in two steps.
At the first step it chooses a cell in a keyboard map table according to
the state of modifiers and gets a keysym. And the second step is that if
Lock modifier is set Xlib tries to convert the keysym to uppercase one using
an internal table.
2) For the cell choosing it uses rules called 'key type'. Such rule describes
what modifiers should be taken in account and what combiantion of modifiers
match each shift level. (Note that the modifers can be not Shift only but also
Control, Alt, etc.).
Each key can have own type (refer to own rule) and if there are more than one
'xkb group' in a keybaord map the key can have different types for different
groups.
3) The first step subroutine can remove some modifiers ('consume' in XKB terms)
if they are used for the sell selection. Otherwise it would be imposible to
cancel temporary a Lock modifier action. Thus if we want the Shift cancels
Caps mode we have to specify in the type description that if Shift is pressed,
Lock modifier should be removed (or hidden) and the second step will leave the
keysym unchaged.
4) xkbcomp program itself tries recognize what key is alphabetic and what key
is not and assign them different types (rules). The algorithm is simple,
if the keysym in the first level is some lowercase letter and the keysym in
the second level is some uppercase one it is an alphabetic key (note: the
program doesn't check any matching between them). Otherwise xkbcomp thinks
it is a 'non-alphabetic key with two levels'.
Also one can explicitly specify the key type in a keyboard map.
Now we can understand the results of your experiments.
The key [ccedilla 9] was not recognized as an alphabetic key because the second
symbol isn't an uppercase letter.
On the other hand the rule for 'simple two level' keys is:
if Shift is set choose the second level, otherwise choose the first one.
But (what I didn't guess) the rule says nothing about the consuming of Lock
modifier. And if Lock is set the second step converts ccedilla to uppercase
Ccedilla. If Shift is also set the first step chooses '9' and the second step
does nothing.
Actually there is not a difference between the 'two level' type and the
'alphabetic' type in caps:internal mode except Lock+Shift case.
'Alphabetic-internal' rule chooses first level when there is not any modifiers
set and the second level when Shift is active. If Lock (without Shift) is set
it chooses the first level keysym but allow second step to make it uppercase
one (using internal table !).
But the case Lock+Shift is processed differently. 'Two level' rule chooses
the second level symbol but 'alphabetic-internal' rule still gets the first
level keysym but consume Lock modifiers and prevents the capitalization at
the secont step.
Thus you see that the 'alphabetic-internal' rule *never* chooses the second
level if Lock is set but only pass it to or hide it from the second step.
The rule 'alphabetic' in caps:shift mode differ from both mentioned rules.
It *always* consume Lock and leave the second step idle. On the other hand
it use Lock for choosing the second level and returns to the first level
when Shift is added to Lock.
And what is exactly the difference between the caps:shift and the currently
default behaviour?
In caps:shift mode if Lock modifier is set Xlib gets from keyboard map
a keysym from the second shift level the same as is chosen when Shift modifier
is set.
?? You said that such behaviour is no more present.
No, I said that CapsLock key doesn't control Shift modifier (saying 'modifiers'
I don't mean keys themselvs but bit flags that the keys set).
The CapsLock key always set Lock modifier. But in this mode Lock and Shift
modifiers (flags) cause the same action at a level choosing.
But since CapsLock key doesn't lock Shift modifier but Lock modifier
it allows to distinguish cases CapsLock is active and CapsLock is active and
Shift key is pressed. Also it allows only part of keys (alphabetical ones)
be affected by CapsLock.
So, it is not the second shift level that is chosen; but
- if the second shift level is alphabetic, it is chosen;
- if not, the first shift level is uppercased.
is that right?
Not exactly, but it looks like that. :-)
As I tried to explain above, if the second shift level is alphabetic (and
uppercase) the 'alphabetic' rule is applied and in caps:shift mode
it means that the
Re: xfree86 for the VIA Apollo CLE266
On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
NeedFunctionPrototypes and ANSI C
Is there an effort to get rid of NeedFunctionPrototypes and to convert function prototypes to ANSI style? If so, I would like to work on doing this for the xwininfo binary. My research indicates that X11R6.3+ require an ANSI compiler and that this type of conversion is desirable. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
If you use XFree 4.3 with libxcursor, you can create a completely transparent cursor theme. -- Matthew on Wed, Aug 06, 2003 at 02:21:35PM +0800, tom wrote: I want to hide the cursor when I using touchscreen in XFree86 4.20,I found that this quesstion have been discussed three times,but no answer.Then,does this means I can't hide the cursor at all?Can xsetroot resolve this problem?I tried but faild.I just can't change the cursor with it. Any idea? Thank you. Roy - Do You Yahoo!? ?? ??+??? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: blanking of non-refreshing windows
On Tue, 2003-08-12 at 16:49, Andy Isaacson wrote: The problem: if an X11 app is very slow to refresh (it is swapped out, or SIGSTOPped, or is over a very slow link) its windows may remain garbage for a long time, which can be confusing when the garbage happens to be an image of windowmanager decorations (for example). The obvious solution, writing the background color into the framebuffer when a window is un-obscured, is a pessimisation of the normal case (where the app responds within a few milliseconds). A more useful solution would be to schedule an event a few dozen milliseconds (say, 20 or 100 ms) in the future, which upon arrival would check that the window has been refreshed and, if not, write it with the background color, on the assumption that if the app hasn't refreshed yet, it's not going to anytime soon. Ideally this event would only be handled when the X server is otherwise idle. All this effort for a band aid? A different basic approach like in XDarwin or XDirectFB makes more sense to me. Please CC me on any discussion, as I am not subscribed. Gladly, unfortunately the list makes this unnecessarily hard. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for ia64 page size
Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: This probably should be rewritten to be outside of the drivers themselves so that it doesn't have to be done per-driver. I'm applying this to our XFree86 for now however until I've got time to investigate doing it more generically. diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c 2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c 2002-10-20 03:05:24.0 +0900 @@ -54,15 +54,7 @@ #include GL/glxtokens.h #include sarea.h -/* ?? HACK - for now, put this here... */ -/* ?? Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t r128_drm_page_size; /* Initialize the visual configs that are supported by the hardware. These are combined with the visual configs that the indirect @@ -489,11 +481,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -642,11 +634,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = r128_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -1003,6 +993,8 @@ break; } +r128_drm_page_size = getpagesize(); + /* Create the DRI data structure, and fill it in before calling the DRIScreenInit(). */ if (!(pDRIInfo = DRICreateInfoRec())) return FALSE; diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/radeon_dri.c2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2002-10-20 03:04:18.0 +0900 @@ -56,15 +56,7 @@ #include sarea.h #include radeon_sarea.h -/* HACK - for now, put this here... */ -/* Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t radeon_drm_page_size; static Bool RADEONDRICloseFullScreen(ScreenPtr pScreen); @@ -774,11 +766,11 @@ /* Initialize the CP ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart= info-ringReadOffset + info-ringReadMapSize; @@ -900,11 +892,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + radeon_drm_page_size; info-ringSizeLog2QW = RADEONMinBits(info-ringSize*1024*1024/8)-1; info-ringReadOffset = info-ringStart + info-ringMapSize; -info-ringReadMapSize = DRM_PAGE_SIZE; +info-ringReadMapSize = radeon_drm_page_size; /* Reserve space for vertex/indirect buffers */ info-bufStart=
Re: xf86AddInputHandler
On Wed, Jul 30, 2003 at 07:01:45PM +0200, Mathieu Lacage wrote: Le mer 30/07/2003 à 16:36, Egbert Eich a écrit : One of the things I don't really get is what xf86AddInputHandler is supposed to be used for. Despite reading a lot of code and grepping multiple times, I found only very few locations using xf86AddInputHandler and I could not figure out what it is used for. I'd be most grateful for any kind of hint :) Please take a look at: http://xfree86.linuxwiki.org/xf86_2a_2a_20Functions Thanks for the pointer. This documentation is indeed useful but I had already figured what the function does by myself. I am more interested in what it is expected to be used for: who will call this function ? You could probably rephrase this to: what is an Input Handler?. An input handler consists of a file descriptor to get input from, and a function to call when it has input to read and be processed. The InputHandler functionality in xf86Events.c also ensures that such input is only read and processed when XFree86's VT is the active one. [EMAIL PROTECTED] Xserver]$ grep -r xf86AddInputHandler * hw/xfree86/common/xf86.h:pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data); hw/xfree86/common/xf86Events.c:xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data) hw/xfree86/drivers/glint/pm2_video.c: xf86AddInputHandler(xvipc_fd, Permedia2ReadInput, NULL); hw/xfree86/loader/xf86sym.c: SYMFUNC(xf86AddInputHandler) hw/xfree86/os-support/bsd/bsd_apm.c:APMihPtr = xf86AddInputHandler(fd, xf86HandlePMEvents, NULL); hw/xfree86/os-support/bsd/bsd_kqueue_apm.c:APMihPtr = xf86AddInputHandler(kq, xf86HandlePMEvents, NULL); hw/xfree86/os-support/linux/lnx_apm.c: APMihPtr = xf86AddInputHandler(fd,xf86HandlePMEvents,NULL); [EMAIL PROTECTED] Xserver]$ grep does not show any meaningful use of the function: I'd expect way more people to be interested in adding a fd to the list of fds to watch for in select. Is there another way to do this ? The APM cases you found with grep should be typical examples. Obviously, I missed something rather fundamental about this code because I feel like I am going nowhere. What specifically are you looking for? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: final issues... xfree86 for the VIA Apollo CLE266
On Tuesday, Aug 5, 2003, at 08:58 Europe/Paris, Aidan Kehoe wrote: Ar an 4ú lá de mí 8, scríobh George Georgalis : It works great, even if I kill X it comes back up, but it still listens on 6000. I find this odd, maybe I need to invoke it with Xfree86, not X? Hmm, that shouldn't make a difference. I've got -nolisten tcp working on this machine with the 4.3.99.5 snapshot; it's getting called as More recent snapshots have the IPv6 integrated, and on IPv6 capable systems, the handling of -nolisten has changed (and will probably change again before the next release). You should use '-nolisten inet4 -nolisten inet6' with the -current code to disable tcp sockets on both IPv4 and IPv6 addresses. A better solution that will make '-nolisten tcp' do that again is in the works. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
Mark Vojkovich writes:
NVIDIA root caused this at one point and came to the conclusion
that Linux kernel was incorrectly mapping the memory as cached.
Experiments with setting bit{63} of Base Register fixed the
problem.
OK, this sounds like a very reasonable explanation.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Fix for Xlib with ipv6 support on ipv4 only systems
The path below will fix the problem that arises when running
a client on an inet4 only system over tcp with Xlib compiled
with inet6 support.
If noone objects I'll commit it.
Egbert.
Index: Xtranssock.c
===
RCS file: /home/eich/cvs/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 Xtranssock.c
--- Xtranssock.c6 Aug 2003 16:17:24 - 1.1.1.10
+++ Xtranssock.c7 Aug 2003 13:12:47 -
@@ -192,6 +192,7 @@
{tcp,AF_INET,SOCK_STREAM,SOCK_DGRAM,0},
#else /* IPv6 */
{tcp,AF_INET6,SOCK_STREAM,SOCK_DGRAM,0},
+{tcp,AF_INET,SOCK_STREAM,SOCK_DGRAM,0}, /* fallback */
{inet6,AF_INET6,SOCK_STREAM,SOCK_DGRAM,0},
#endif
#endif /* TCPCONN */
@@ -275,20 +276,20 @@
*/
static int
-TRANS(SocketSelectFamily) (char *family)
+TRANS(SocketSelectFamily) (int first, char *family)
{
int i;
PRMSG (3,SocketSelectFamily(%s)\n, family, 0, 0);
-for (i = 0; i NUMSOCKETFAMILIES;i++)
+for (i = first + 1; i NUMSOCKETFAMILIES;i++)
{
if (!strcmp (family, Sockettrans2devtab[i].transname))
return i;
}
-return -1;
+return (first == -1 ? -2 : -1);
}
@@ -418,7 +419,7 @@
#endif
#endif
) {
- PRMSG (1, SocketOpen: socket() failed for %s\n,
+ PRMSG (2, SocketOpen: socket() failed for %s\n,
Sockettrans2devtab[i].transname, 0, 0);
xfree ((char *) ciptr);
@@ -483,26 +484,25 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2, SocketOpenCOTSClient(%s,%s,%s)\n,
protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCOTSClient: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCOTSClient: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCOTSClient: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG (1,SocketOpenCOTSClient: Unable to determine socket type for %s\n,
+ thistrans-TransName, 0, 0);
return NULL;
}
@@ -524,25 +524,24 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2,SocketOpenCOTSServer(%s,%s,%s)\n, protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCOTSServer: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCOTSServer: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCOTSServer: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG (1,SocketOpenCOTSServer: Unable to determine socket type for %s\n,
+ thistrans-TransName, 0, 0);
return NULL;
}
@@ -592,25 +591,24 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2,SocketOpenCLTSClient(%s,%s,%s)\n, protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCLTSClient: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCLTSClient: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCLTSClient: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG
Re: Xrender transforms...
On Sun, 10 Aug 2003 05:59:54 +0100 Alan Hourihane [EMAIL PROTECTED] (Bbabbled: (B (B On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: (B Would I be correct in the assumption that the only accelerated path for (B xrender is the identity transform (1:1 scale)? all other transforms are done (B in software? (my initial tests here with xfree86 4.3.0 nvidia's latest (B drivers(as of about a month ago) seem to indicate as much...) (and yes... my (B drivers are using acceleration... GL definitely is). ? (B (B No. About 99% of the drivers don't have any xrender acceleration. I think (B only the mga driver does. Although looking furthur the sis has some, but (B it seems disabled, and the vmware driver has it too. But that's it. (B (B I guess nvidia do some acceleration in their binary drivers though, as (B you've probably found. But it's bad to assume other drivers have xrender (B acceleration. (B (B I think the thing that's holding other drivers up in getting furthur xrender (B acceleration is that there's no test suite to check that the driver is (B doing the right thing. I think Keith Packard mentioned he had intern's (B working on a test suite a while ago, but nothing has materialized as far (B as I know. (B (Bhmmm - well i could write a performance suite here... if that helps. so far as (Bin my other e-mail, the "hardware acceleration" provides by the nvidia drivers (Bso far manages to be 1/35th the speed of my own mmx asm blending routines... (Bthis is blending with 1:1 scaling (no transform). (B (Bi just tested a quick scaling test and the software routines i have are 41 times (Bfaster than xrender... there is something suspicious here... (B (Ba quick rundown: (Bmy software routines are in imlib2. (Bmachine is amd 1.7ghz (Bgfx is nvidia gf4 4400ti 128mb (B (BNVAGP is set to 0 cause it manages to lock up my kernel regularly :( (B (Bthis is xfree 4.3.0 (Bnvidia drivers: (B (BNVIDIA_kernel-1.0-4191 (BNVIDIA_GLX-1.0-4191 (B (Bdestination is 32bpp pixmap (picture) i get similar speed results with (Bdestination being 24bpp window so that doesn't make a difference. source image (Bbeing blended is 100x100 32bpp. i just simply look 4096 times and blend it at a (Brandom co-ord with in a 320x320 destination. (B (Bif you want i can either attach the code data files direct, or if you give me (Ba little i can clean it up int something approximating a performance test suite (Bfor xrender compositing / some basic transforms. (B (Bsomehow i'd expect it to at least EQUAL software :) well there goes my plans for (Ba project to do an xrender display engine... opengl still is the big winner :) (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, and the vmware driver has it too. But that's it. I guess nvidia do some acceleration in their binary drivers though, as you've probably found. But it's bad to assume other drivers have xrender acceleration. I think the thing that's holding other drivers up in getting furthur xrender acceleration is that there's no test suite to check that the driver is doing the right thing. I think Keith Packard mentioned he had intern's working on a test suite a while ago, but nothing has materialized as far as I know. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64
On Sun, Aug 10, 2003 at 09:40:43PM -0600, Marc Aurele La France wrote: You seem to be submitting a string of old patches, some of them twice. Why? These patches are all from the Debian packages. -- Daniel Stone [EMAIL PROTECTED] http://www.debian.org - http://www.kde.org - http://www.xwin.org Jeff doesn't use pants often. -- Pia Smith pgp0.pgp Description: PGP signature
Re: CapsLock behaviour and Turkish keyboard
On Wed, 2003-08-13 at 08:56, Ivan Pascal wrote: With the actual mode of implementation (not using the Lock modifier), yes, you don't have the problem of it affecting non-alphabetic keys. I would have the problem with it affecting non-alphabetic keys if I didn't use the Lock modifier. There is not such problem because the actual mode of implementation does use the Lock modifier. I tried to explain it in my replies to Pablo. I think you just have to realize that XKB is too complex for anybody to fully understand it without spending several hours a week on it. :-) However, you do have the problem that applications can't tell that the level change was produced by the caps-lock key. Which sometimes is useful information. For instance, the obvious fix for: http://bugzilla.gnome.org/show_bug.cgi?id=115384 which is to strip out the Lock modifier before checking for accelerator matches, won't work. I am sorry for the repeating. Did you try it before writing this? You really don't have to be rude. Just tell me to try it. I made the assumption that if I had read the relevant Xlib XKB code and read the relevant rules file, I would have some idea what was going on. A dangerous assumption when XKB is involved. Going back and rereading your mail and rereading the code, I see how it's being accomplished via the magic of consumed modifiers. But really, I don't feel bad about not figuring that out the first time. And I don't feel bad about not doing a bunch of practical experimentation. Life's too short. Too many other bugs to worry about. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
On Wed, 13 Aug 2003 [EMAIL PROTECTED] wrote: Can anyone tell me how good a job the old Mach32 and Mach64 servers did of taking advantage of the hardware capabilities of their respective silicon engines? Put another way, were there capabilities in the silicon that we did not use? If there are transistors not pulling their weight, are docs available to remedy the situation should one be so inclined to do so? I don't have access to the docs, but there are many chipsets with the mach64 core, going from (iirc) isa to agp (or at least gart). Also iirc it is used on laptop chipsets released after the radeon (ATI Mobility M1 springs to mind, but I can't easily confirm). Since these are based on the Mach64 they all use the mach64 driver although there possess very different features. There is a GATOS project to add 3D to those mach64 chips which support 3D; it has never been merged into the XFree86 driver. Xv may or may not have made it into the mach64 driver too. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Post-processing X-server output
Hello, I want to post-process the output of an x-server. In detail I want to take e.g. the desktop view of any windowmanager, apply some OpenGL image manipulation functions to it and then send the manipulated image to the graphic card. What is the best way to realize this behavior ? Does there exist any documentation for further readings ? Thanks in advance, Alex ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
what parts of fb driver are used when Option USeFBDev is specififed?
From a functionality point of view, what is the difference between using Option UseFBDev and using the fb device driver directly via Driver fbdev in XF86Config? Specifically, in the case where I specify Driver radeon and Option UseFBDev exactly what parts of the radeon fb driver are used instead/in place of the XFree86 radeon driver? Whats the diff between this and just specifying Driver fbdev directly? -dean andreakis ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
On Tuesday 12 of August 2003 20:32, Bryan W. Headley wrote: Rafa Rzepecki wrote: On Tuesday 12 of August 2003 16:53, Bryan W. Headley wrote: I'm working on mouse.c personally, trying to add cordless mouse status reporting and some cordless-specific runtime control, such as RF channel switching. Unfortunately the only way I've found to communicate with userland is using shared memory (vide synaptics driver). But it has a drawback that it cannot be used to communicate with remote display, as it's not using the X protocol. One could try to communicate using LED feedbacks (like in citron driver), but there seem to be no way to manipulate feedbacks of the core pointer, so it's limited to extension devices. Or maybe I am mistaken, and there is a way? Could someone more familiar with input drivers clarify it? I'm not aware of any restriction with the mouse driver. From XChangeFeedbackControl (3x11): BadDevice An invalid device was specified. The specified device does not exist or has not been opened by this client via XOpenInputDevice. And you can only XOpenDevice if it is not a core pointer: BadDevice An invalid device was specified. The specified device does not exist, or is the X keyboard or X pointer. [XOpenDevice (3x11)] Or maybe there is another way to manipulate feedbacks that I am not aware of and it helps to get this problem around? Could someone either to approve above valid or disprove it and show a way to manipulate feedbacks of the core pointer? But I think the LED feedback is very limited, both in terms of packet size, and in terms of reply. Sure, it is limited, but at least it's a way to setup bidirectional driver-userland communication thru the X protocol, and the packet size problem is just a matter of protocol design. And I really don't need any big packets, as the data I am going to exchange is not very large in size. Another thing you can use is the xf86Misc message extension. The ati/radeon driver shows a stub of it (xf86HandleMessageProc) But isn't it only usable by display drivers? I believe that's what the message passing extension in Xext is going to do. I hope that's the same extension, and we don't have _three_ messaging APIs. I think so, I must have messed the names. My head is all buzzing with various X-words ;-). Excuse my stupidity, why are you not using GetTimeInMillis? Aren't you called gettimeofday? Oh. That's what Qian Tao asked about, I believe; not me. -- Rafa Rzepecki ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Using the radeon CP engine for Xv
If the CP is enabled for acceleration on the radeon, could I also use it to issue Xv commands rather than using mmio? It looks like it should be possible. I'd be willing to give it a try. would any sort of special locking be required or can I just issue the commands to the ring like the accel code does? What kind of speed up would I expect if any? Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
On Tuesday 12 of August 2003 16:53, Bryan W. Headley wrote: I'm working on mouse.c personally, trying to add cordless mouse status reporting and some cordless-specific runtime control, such as RF channel switching. Unfortunately the only way I've found to communicate with userland is using shared memory (vide synaptics driver). But it has a drawback that it cannot be used to communicate with remote display, as it's not using the X protocol. One could try to communicate using LED feedbacks (like in citron driver), but there seem to be no way to manipulate feedbacks of the core pointer, so it's limited to extension devices. Or maybe I am mistaken, and there is a way? Could someone more familiar with input drivers clarify it? I'm not aware of any restriction with the mouse driver. From XChangeFeedbackControl (3x11): BadDevice An invalid device was specified. The specified device does not exist or has not been opened by this client via XOpenInputDevice. And you can only XOpenDevice if it is not a core pointer: BadDevice An invalid device was specified. The specified device does not exist, or is the X keyboard or X pointer. [XOpenDevice (3x11)] Or maybe there is another way to manipulate feedbacks that I am not aware of and it helps to get this problem around? But I think the LED feedback is very limited, both in terms of packet size, and in terms of reply. Sure, it is limited, but at least it's a way to setup bidirectional driver-userland communication thru the X protocol, and the packet size problem is just a matter of protocol design. And I really don't need any big packets, as the data I am going to exchange is not very large in size. Possibly, we can activate StringFeedback and at least get larger packets, (it's a one-line patch), As I said, packet size really doesn't matter as long as I can communicate anyhow. but until we do something using Atoms, you will suffer due endianness/sizeof intrinsics/padding issues. I believe that's what the message passing extension in Xext is going to do. Excuse my stupidity, why are you not using GetTimeInMillis? Could you elaborate? -- Rafa Rzepecki ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, 10 Aug 2003 13:59:18 -0700 (PDT) Mark Vojkovich [EMAIL PROTECTED] (Bbabbled: (B (BRENDER is slow, so that's not surprising. (B (Byes. i'm getting the drift. :) it was slow 2 years ago. i was kind of hoping (Bit'd moved on since then. i started work on using it and found at the time even (B1:1 scaled blending was not outperforming client-side software routines. i (Bhalted work on that code pending improvement. :) (B (B display is 24bpp (src picture is 32bpp, with alpha, component alpha set, (B repeat set to true, dither true). i am not sure.. but a 35 TIMES speed (B difference with software being the faster... sounds wrong to me. (B (B (BSoftware being faster than what? It's all in software. I don't (B check to see if the transform is identity. If there's a transform, (B I punt. (B (Bhmmm bugger. i'd have expected at least identity checks. i'd also have expected (Bchecks for simple 2d scaling (no rotation) in the transform matrix as this is an (Beasier case to accelerate - especially in software. (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
SlowBCopy, IA64, PCI bus corruption
I'm trying to track down a problem on ia64 (Itanium), it seems to
manifest itself only with the Nvidia (nv) driver but I don't think
this is an nv driver issue, rather I think its a generic issue in
SlowBCopy which the nv driver happens to invoke.
Symptom:
The first time the nv driver is used for accelerated drawing the X
server enters an infinite loop that consumes almost all the CPU
cycles. Also, if you scan the pci bus at this point (e.g. with lspci)
you will discover bogus config values on the nv card (all ones,
e.g. ~0).
Cause:
--
The cause of the infinite loop in the nv driver is a sync function
that polls a device register waiting for the engine to go idle. At
this point all pci reads from the nv card on the bus return values
that are all ones (~0). These are not valid values, but I believe this
is defined behavior for PCI bridges after a master abort. The nv sync
function never exits its loop because the register its polling is not
being read correctly because of pci bus problems. This also explains
why scanning the pci bus (e.g. lspci) no longer works when the scan
gets to the nv card, its says 7F is not a valid config value and skips
the card (note all values printed below are all ones).
80:00.0 Class : nVidia Corporation NV25GL [Quadro4 900 XGL] (rev ff)
(prog-if ff)
!!! Unknown header type 7f
Root Cause:
---
After much investigation I tracked the problem down to VGA font save
and restore which invokes SlowBCopy. SlowBCopy would appear to a hack
designed to slow down bus transactions, seemingly used only when
accessing VGA data. There are two basic variants of SlowBCopy, on x86
architectures there is an asm version which basically just inserts
extra machine instructions in the loop that copies the data. For
some non-x86 architectures the copy loop includes:
outb(0x80, 0x00);
I learned via correspondence in the past the purpose of this outb is
no-op, supposedly io port 0x80 is not used for anything and thus the
write to this port does nothing other than introducing a delay.
Sort of fix:
On April 7th Egbert Eich checked in a fix to SlowBcopy.c (rev 1.6)
that introduced an extra outb delay before entering the copy loop,
xf86SlowBcopy now looks like this:
void
xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
{
#if defined(__ia64__)
outb(0x80, 0x00);
#endif
while(len--)
{
*dst++ = *src++;
#if !defined(__sparc__) !defined(__powerpc__) !defined(__mips__)
outb(0x80, 0x00);
#endif
}
}
The fix Egbert introduced fixed the nv hang we were seeing on HP
ZX2000's and the subsequent PCI Bus corruption (e.g. card only returns
~0 on all PCI reads). I thought we now had a fix for all nv cards on
all HP ZX systems. But my elation was premature. The exact same
symptoms reared its head on HP ZX 6000's even with the above fix. As
long as SlowBCopy for VGA font save/restore is not called things work
fine on the ZX 6000's.
Not surprised SlowBCopy is not robust:
--
For reasons I don't understand (can somebody explain this to me?)
reads/writes to VGA data perform slower than bus transactions. This
would appear to be why SlowBCopy was introduced originally, to slow
down reads and writes to the VGA data and hence either preventing the
data from being corrupted and/or prevent the bus from getting into a
bad state when bus transactions start to timeout.
Now it seems to me that using extra machine instructions (asm version)
or no-op IO is inherently a risky solution to this problem. It would
appear there is some interval of time one must wait for individual VGA
bus transactions complete. The number of extra machine instructions
and/or no-op IO to insert seems to be purely a guess and highly
dependent on the processor and the bus its sitting on. The fact this
works on one class of machines and not another does not surprise me at
all.
So my real questions are:
-
1) Why are VGA transactions so slow and is there a known timing value?
2) Is the fact that reads from the nv card return as all ones (~0)
due to PCI master abort as a consequence of timing out on a VGA
transaction and is the PCI bridge never recovering from the abort (I
believe its the bridge who is responsible for returning all
ones). And if this is true can/should the bridge be configured not to
stay in this state (it seems to stay in this state until hw reset).
OR
Is it not the bridge that is the culprit for returning all ones but
the card (an nvidia in this instance) that is in some screwed up state
such that it returns all ones till hw reset?
I think this is important distinction, if this is a PCI bridge
configuration issue we might be able to address it in a more generic
manner. If its a card issue then that suggests a driver specific
solution.
3) Can we come up with a scheme that introduces a known timing delay
(e.g. usleep) such that we don't have to make arbitrary guesses as
Re: initial palette wrong.
What are you passing to xf86HandleColormaps() ? I looked at this, at it appears I need to set CMAP_EVEN_IF_OFFSCREEN. At least setting that fixed the problem. Must be a multi-monitor thing??? Anyway, thanks Mark. Noel. -- A precariously balanced mixture of myopic optimism and rampant paranoia. _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Questions about Widgets in X window and XMoveResizeWindow
Cópia dd jj [EMAIL PROTECTED]: Hello everyone, Hi, I hope this is the correct mailing list to post these questions... Could you please give some comments on them? thanks. 1) Now I want to search a button with specific caption, such as Save or Cancel.. Ok on X window (no matter GNOME or KDE) screen. Can I implement this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or it's toally impossible? I think there is no standard way of doing it. And, frequently buttons are not even separate windows. Probably in most cases it is only possible to retrieve this kind of information from the same program; Xt based toolkits can use the XEditRes protocol, see the editres program. As my understanding, The button in Gnome is built using GTK but that in KDE is built using Qt, they are different widgets belong to differen Toolkit, right? But since GTK and Qt are both based on Xlib, I am wondering whether we can handle this using lowest level Programming - xlib? You can use Xlib in both toolkits, assuming your program is only mean't to run under X, but you cannot expect reliable behaviour depending on the Xlib functions you call. Or maybe I can only program using GTK for GNOME, using Qt for KDE separately for different desktop enviroment? You can use any toolkit uder any desktop. 2) I tried to use XMoveResizeWindow to move a X window application such as Xclock, or Xcalc, I parsed the window ID w got from xwininfo and display dsp = XOpenDisplay(NULL) to it like: XMoveResizeWindow(dsp, w, 0, 0, 200, 200); it doesn't work, but when I creat my own window application using XCreateSimpleWindow, then it can work. Seems the display parameter is different every time when implement: dsp = XOpenDispaly(ULL) ? Did I miss something to deal with such existing Application window? Did your program enter an event loop? It is a common mistake to send X requests, but the program exit before they are processed. Normally calling XSync or XFlush before exiting is enough. Thank you for help me out. - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software You can see some low level information on toolkits and programming with Xlib in the famous Kenton Lee site: http://www.rahul.net/kenton/xsites.framed.html There you can also find some tutorials on X programming. Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Questions about Widgets in X window and XMoveResizeWindow
On Thu, Aug 14, 2003 at 02:19:26PM -0700, Alan Coopersmith wrote: dd jj wrote: Can I implement this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or it's toally impossible? As my understanding, The button in Gnome is built using GTK but that in KDE is built using Qt, they are different widgets belong to differen Toolkit, right? But since GTK and Qt are both based on Xlib, I am wondering whether we can handle this using lowest level Programming - xlib? Any program using any toolkit - GTK, Motif, Xaw, Qt, whatever - should be able to run in any desktop (CDE, GNOME, KDE, Afterstep, etc.) or under any window manager. Pick whichever toolkit you want for your application - it may look out of place in a desktop mostly using other toolkits, but it should still work. Additionally, it may look _odd_ if there happens to be resource settings which leak into the application from global settings. (but it should work -- barring that ;-) -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
On Wed, 13 Aug 2003 06:36:04 -0700 (PDT), Alex Deucher wrote: some mach64 mobility chips had a second crtc that was never supported. same thing with rage 128. Same thing with most of the Savage chips, because I couldn't see an easy way to support it. Is this double-headed feature now common enough that there should be some kind of architectural support for it? I'm not sure what that support would look like, but implementing it today seems an awful lot like a hack. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
Rafa? Rzepecki wrote: Another thing you can use is the xf86Misc message extension. The ati/radeon driver shows a stub of it (xf86HandleMessageProc) But isn't it only usable by display drivers? I don't see anything that specifically says deliver this only to display drivers; on the other hand, I don't see where you get to specify WHICH device you are writing to. Every device driver serving Display* x, screen y? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Questions about Widgets in X window and XMoveResizeWindow
On Thu, 14 Aug 2003 14:07:54 -0700 (PDT) dd jj [EMAIL PROTECTED] babbled: (B (B Hello everyone, (B (B I hope this is the correct mailing list to post these questions... Could you (B please give some comments on them? thanks. (B (B 1) Now I want to search a button with specific caption, such as "Save" or (B "Cancel".. "Ok" on X window (no matter GNOME or KDE) screen. Can I implement (B this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or (B it's toally impossible? (B (Bno. you can't. there is no foolproof generic way of detecting a widget (Birrespective of widget set. you'd need to do hacks in each widget set to do (Bthis. not to mention programs that use other widget sets or don't use them at (Ball. (B (B As my understanding, (B (B The button in Gnome is built using GTK but that in KDE is built using Qt, they (B are different widgets belong to differen Toolkit, right? But since GTK and Qt (B are both based on Xlib, I am wondering whether we can handle this using lowest (B level Programming - xlib? (B (B Or maybe I can only program using GTK for GNOME, using Qt for KDE separately (B for different desktop enviroment? (B (B 2) I tried to use XMoveResizeWindow to move a X window application such as (B Xclock, or Xcalc, I parsed the window ID "w" got from xwininfo and display (B dsp = XOpenDisplay(NULL) to it like: (B (B XMoveResizeWindow(dsp, w, 0, 0, 200, 200); (B (B it doesn't work, but when I creat my own window application using (B (Bfirst did you flush your x command buffer - XFlush(dsp); or XSync(dsp, False); ? (Bsecond. did you get the window id right? ie it was still around? third - was it (Bmanaged by the wm? the wm could have it fixed and not allowing resizes (or (Bswallowed) ? (B (B XCreateSimpleWindow, then it can work. Seems the display parameter is (B different every time when implement: dsp = XOpenDispaly(ULL) ? (B (B Did I miss something to deal with such existing Application window? (B (B Thank you for help me out. (B (B (B (B (B (B - (B Do you Yahoo!? (B Yahoo! SiteBuilder - Free, easy-to-use web site design software (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: NeedFunctionPrototypes and ANSI C
On Wed, 13 Aug 2003, Mark Vojkovich wrote:
On Wed, 13 Aug 2003, Warren Turkal wrote:
Is there an effort to get rid of NeedFunctionPrototypes and to convert
function prototypes to ANSI style? If so, I would like to work on doing
this for the xwininfo binary.
I change them whenever I'm working in particular parts of the
tree that haven't been converted yet, and so do a few other people.
I think we avoid wholesale changes across the board because of
the risk it imposes. There have been some breakages when people
didn't pay enough attention and had the arguments reversed. eg:
int func(y, x)
int x;
int y;
{
/* watch out! */
}
Comparing binaries addresses this (except of course where an ifdef
confuses the issue). Even with that, I recall two instances where I
made an error (caught by other people).
So piecemeal changes seem safer. People tend to go on autopilot
when making too many changes of this type in one sitting and have a tendency
to break the case above. You can also introduce some promotion problems
if you're not careful.
That, and changing things incompatibly (putting 'void' on prototypes where
the old headers don't specify).
--
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: initial palette wrong.
On Tue, 12 Aug 2003, Cheshire Cat Fish wrote: I've written a driver for an 8-bpp-only device. This is a non-VGA device and runs as a second display alongside another board (in my case, an S3 - also running in 8bpp) The problem I am seeing is that after I first boot-up the screen colors are wrong for my device. I've verified that I am writing the correct colors to the the CLUT, it is that XFree86 is giving me the wrong colors. Now, if I Ctrl-Alt-F1 to a console (which appears on the S3 card) and then Ctrl-Alt-F7 back to the X desktop, now the colors appear correctly. Or if the screen saver kicks in, then when the screen saver exits, my colors will be correct. This is my first X driver, and I am not sure where to start looking. I am not sure how I have caused X to not select the proper colors upon startup. Any pointers on where to start looking would be appreciated. I think it's unlikely that XFree86 is giving you the wrong colors since it isn't giving other drivers the wrong colors. It seems more likely that the hardware isn't taking the values at that point. What are you passing to xf86HandleColormaps() ? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: NeedFunctionPrototypes and ANSI C
On Wed, 13 Aug 2003, Warren Turkal wrote: Is there an effort to get rid of NeedFunctionPrototypes and to convert function prototypes to ANSI style? If so, I would like to work on doing this for the xwininfo binary. People do work on this occasionally. I've made some notes here: http://dickey.his.com/ansification/index.html My research indicates that X11R6.3+ require an ANSI compiler and that this type of conversion is desirable. Warren Turkal -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: autotooling xrandr
On Tue, Aug 12, 2003 at 04:53:32PM +0100, Aidan Kehoe wrote: Ar an 12ú lá de mí 8, scríobh Harold L Hunt II : However, I wouldn't expect a lot of interest from others, as this gets mentioned every so often but the person suggesting it often gives up after they realize how large of a job it is. I would venture to say too that since the build system isn't that well understood by _anyone_, patches to it move to the back of the queue, and stay there. Cf, http://bugs.xfree86.org/show_bug.cgi?id=72 . And if attempts at minor patches are silently dropped, anyone whose long-term plan is to rework the entire build system is going to get discouraged. Some of us do understand the build system. Bug 72 is not really a minor patch. I replied when you posted a note to devel about it in May, but don't recall seeing any followup from you. As far as I'm concerned, #72 is waiting on further input from you. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 14:32, Ivan Pascal wrote: Owen Taylor wrote: On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: Now Turkish keyboard users just have to set XkbOption caps:shift. With that option Xlib doesn't use 'internal capitalization' but CapsLock key acts as 'locking Shift' (but can be canceled by Shift key). It solves the problem. I don't think that this is a particularly good way to handling things. Using caps:shiftproduces all sorts of strange behavior - for example, the number keys will give their shifted variants. I risk to seem impolite but did you try this option before making such assertion? If you tried you would notice that it is not true. I had the made the assumption that caps:shift did the classic X thing and changed the keysym to be Shift_Lock rather than Caps_Lock. With the actual mode of implementation (not using the Lock modifier), yes, you don't have the problem of it affecting non-alphabetic keys. However, you do have the problem that applications can't tell that the level change was produced by the caps-lock key. Which sometimes is useful information. For instance, the obvious fix for: http://bugzilla.gnome.org/show_bug.cgi?id=115384 which is to strip out the Lock modifier before checking for accelerator matches, won't work. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: NeedFunctionPrototypes and ANSI C
On Wed, 13 Aug 2003, Warren Turkal wrote:
Is there an effort to get rid of NeedFunctionPrototypes and to convert
function prototypes to ANSI style? If so, I would like to work on doing
this for the xwininfo binary.
I change them whenever I'm working in particular parts of the
tree that haven't been converted yet, and so do a few other people.
I think we avoid wholesale changes across the board because of
the risk it imposes. There have been some breakages when people
didn't pay enough attention and had the arguments reversed. eg:
int func(y, x)
int x;
int y;
{
/* watch out! */
}
So piecemeal changes seem safer. People tend to go on autopilot
when making too many changes of this type in one sitting and have a tendency
to break the case above. You can also introduce some promotion problems
if you're not careful.
Mark.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
NVIDIA root caused this at one point and came to the conclusion
that Linux kernel was incorrectly mapping the memory as cached.
Experiments with setting bit{63} of Base Register fixed the
problem.
Mark.
On 11 Aug 2003, John Dennis wrote:
I'm trying to track down a problem on ia64 (Itanium), it seems to
manifest itself only with the Nvidia (nv) driver but I don't think
this is an nv driver issue, rather I think its a generic issue in
SlowBCopy which the nv driver happens to invoke.
Symptom:
The first time the nv driver is used for accelerated drawing the X
server enters an infinite loop that consumes almost all the CPU
cycles. Also, if you scan the pci bus at this point (e.g. with lspci)
you will discover bogus config values on the nv card (all ones,
e.g. ~0).
Cause:
--
The cause of the infinite loop in the nv driver is a sync function
that polls a device register waiting for the engine to go idle. At
this point all pci reads from the nv card on the bus return values
that are all ones (~0). These are not valid values, but I believe this
is defined behavior for PCI bridges after a master abort. The nv sync
function never exits its loop because the register its polling is not
being read correctly because of pci bus problems. This also explains
why scanning the pci bus (e.g. lspci) no longer works when the scan
gets to the nv card, its says 7F is not a valid config value and skips
the card (note all values printed below are all ones).
80:00.0 Class : nVidia Corporation NV25GL [Quadro4 900 XGL] (rev ff)
(prog-if ff)
!!! Unknown header type 7f
Root Cause:
---
After much investigation I tracked the problem down to VGA font save
and restore which invokes SlowBCopy. SlowBCopy would appear to a hack
designed to slow down bus transactions, seemingly used only when
accessing VGA data. There are two basic variants of SlowBCopy, on x86
architectures there is an asm version which basically just inserts
extra machine instructions in the loop that copies the data. For
some non-x86 architectures the copy loop includes:
outb(0x80, 0x00);
I learned via correspondence in the past the purpose of this outb is
no-op, supposedly io port 0x80 is not used for anything and thus the
write to this port does nothing other than introducing a delay.
Sort of fix:
On April 7th Egbert Eich checked in a fix to SlowBcopy.c (rev 1.6)
that introduced an extra outb delay before entering the copy loop,
xf86SlowBcopy now looks like this:
void
xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
{
#if defined(__ia64__)
outb(0x80, 0x00);
#endif
while(len--)
{
*dst++ = *src++;
#if !defined(__sparc__) !defined(__powerpc__) !defined(__mips__)
outb(0x80, 0x00);
#endif
}
}
The fix Egbert introduced fixed the nv hang we were seeing on HP
ZX2000's and the subsequent PCI Bus corruption (e.g. card only returns
~0 on all PCI reads). I thought we now had a fix for all nv cards on
all HP ZX systems. But my elation was premature. The exact same
symptoms reared its head on HP ZX 6000's even with the above fix. As
long as SlowBCopy for VGA font save/restore is not called things work
fine on the ZX 6000's.
Not surprised SlowBCopy is not robust:
--
For reasons I don't understand (can somebody explain this to me?)
reads/writes to VGA data perform slower than bus transactions. This
would appear to be why SlowBCopy was introduced originally, to slow
down reads and writes to the VGA data and hence either preventing the
data from being corrupted and/or prevent the bus from getting into a
bad state when bus transactions start to timeout.
Now it seems to me that using extra machine instructions (asm version)
or no-op IO is inherently a risky solution to this problem. It would
appear there is some interval of time one must wait for individual VGA
bus transactions complete. The number of extra machine instructions
and/or no-op IO to insert seems to be purely a guess and highly
dependent on the processor and the bus its sitting on. The fact this
works on one class of machines and not another does not surprise me at
all.
So my real questions are:
-
1) Why are VGA transactions so slow and is there a known timing value?
2) Is the fact that reads from the nv card return as all ones (~0)
due to PCI master abort as a consequence of timing out on a VGA
transaction and is the PCI bridge never recovering from the abort (I
believe its the bridge who is responsible for returning all
ones). And if this is true can/should the bridge be configured not to
stay in this state (it seems to stay in this state until hw reset).
OR
Is it not the bridge that is the culprit for returning all ones but
the card (an nvidia in this instance) that is in some screwed up state
such that it
Re: Questions about Widgets in X window and XMoveResizeWindow
Hello thank you for helping, honestly I am brand new for Xlib programming, I checked my program, still can't figure out the problem: If I create a window my self, then use xwinfo to get the window Id as one parameter of XMoveResizeWindow, it works, but when I change the window id to be another application's id, such as Xclock, it just can't work, here's my codes:
#include .
...
main()
{ Window win = 0x1e1; //window's id got from xwininfo
Display *dsp = XOpenDisplay(NULL);
XMoveResizeWindow(dpy, win, 0, 0, 100, 500); //resizing and moving window
XFlush(dsp);
}
If I set win to be a window id of my own application, it works,
why it just doesn't work for other application like Xclock?
Thanks for help.
[EMAIL PROTECTED] wrote:
Cópia dd jj <[EMAIL PROTECTED]>: Hello everyone,Hi, I hope this is the correct mailing list to post these questions... Could you please give some comments on them? thanks. 1) Now I want to search a button with specific caption, such as "Save" or "Cancel".. "Ok" on X window (no matter GNOME or KDE) screen. Can I implement this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or it's toally impossible?I think there is no standard way of doing it. And, frequently buttonsare not even separate windows. Probably in most cases it is only possibleto retrieve this kind of information from the same program; Xt basedtoolkits can use the XEditRes protocol, see the editres program. As my understanding, The button in Gnome is built using GTK but
that in KDE is built using Qt, they are different widgets belong to differen Toolkit, right? But since GTK and Qt are both based on Xlib, I am wondering whether we can handle this using lowest level Programming - xlib?You can use Xlib in both toolkits, assuming your program is only mean'tto run under X, but you cannot expect reliable behaviour depending on theXlib functions you call. Or maybe I can only program using GTK for GNOME, using Qt for KDE separately for different desktop enviroment?You can use any toolkit uder any desktop. 2) I tried to use XMoveResizeWindow to move a X window application such as Xclock, or Xcalc, I parsed the window ID "w" got from xwininfo and display dsp = XOpenDisplay(NULL) to it like: XMoveResizeWindow(dsp, w, 0, 0, 200, 200); it doesn't work, but when I creat my own window application using
XCreateSimpleWindow, then it can work. Seems the display parameter is different every time when implement: dsp = XOpenDispaly(ULL) ? Did I miss something to deal with such existing Application window?Did your program enter an event loop? It is a common mistake tosend X requests, but the program exit before they are processed.Normally calling XSync or XFlush before exiting is enough. Thank you for help me out. - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design softwareYou can see some "low level" information on toolkits and programmingwith Xlib in the famous Kenton Lee site:http://www.rahul.net/kenton/xsites.framed.htmlThere you can also find some tutorials on X programming.Paulo___Devel mailing
list[EMAIL PROTECTED]http://XFree86.Org/mailman/listinfo/devel
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
old Mach32 and Mach64 servers
Hi, Can anyone tell me how good a job the old Mach32 and Mach64 servers did of taking advantage of the hardware capabilities of their respective silicon engines? Put another way, were there capabilities in the silicon that we did not use? If there are transistors not pulling their weight, are docs available to remedy the situation should one be so inclined to do so? Thanks, kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MergedFB mode question
you might try xfree86 cvs and then use the option MonitorLayout LVDS, CRT I think I also recall hearing that apple wired the DACS differently than most boards. I believe this is fixed in cvs. Alex --- Andreakis, Dean (MED) [EMAIL PROTECTED] wrote: I am utilizing MergedFB mode from Alex D. and have a problem. My config is: iBook w/ Debian (sid) and XFree86 v4.3.0. ATI radeon mobility 7500. External CRT connected., benh 2.4.21 kernel. When I startup X the external monitor turns on fine and it displays the left half of the 2048x768 virtual screen as defined in my XF86Config file BUT the internal LCD panel is off (i.e. completely blank/black). I looked thru the XFree86 log file and MergedFB mode (and DRI by the way) are both enabled with no errors or warnings. The little workspace switcher display on the bottom toolbar shows the 2048x768 area and I can move my mouse off of the right edge into what should be the lcd panel etc. so it seems that MergedFB is enabled and working ok except for the fact that the internal lcd panel is somehow disabled. Attached are my log and config. files. -dean andreakis __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: autotooling xrandr
Harold L Hunt II wrote: Warren, Most people are probably smart enough not to respond to this... so I will take the plunge for all of them :) Autotooling xrandr might not have been too hard, for one platform and one version of the autotools. However, autotooling X as a whole might be a much larger job than you are thinking of. For example, the current system supports cross compiling quite well, which you would have to be careful not to break in autotool scripts (again, on all supported platforms). For another example, X can be built on Cygwin and OS/2, both of which has strange handling of executable extentions and lots of special linker magic to make things work. Currently all of this magic is contained explicitly and implicitly in Imakefiles. It might be easy for you to autotool what is explicity mentioned in the Imakefiles, but it will be a very large job to autotool all of the implicit things going on behind the scenes. In other words, you can't just look at a given Imakefile and autotool it... you have to grok all of the *.cf files for the various supported platforms to understand what different combinations of flags are supposed to do. If you have thought of all of this and are still interested, then best of luck. However, I wouldn't expect a lot of interest from others, as this gets mentioned every so often but the person suggesting it often gives up after they realize how large of a job it is. Thus, a lot of people are probably going to assume that you will give up as others before you have. Harold Is there any chance of upstream acceptance of this type of work? A lot of the utility binaries should be pretty easy to break out the xc hierarchy. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
pls help a newbie:how XFree86 wrap functions in libc
Title: pls help a newbie:how XFree86 wrap functions in libc I'm sorry,my english is not good I want to add some code to xc/program/Xserver/hw/xfree86/input/mouse/mouse.c I have to call some functions in libc. To my surprise,fprintf wok well,but,gettimeofday doesn't work When I start my server,the server says:This should not happen;An unresolved function was called;Fatal server error I just cannot understand how XFree86 wrap functions in libc. Pls help me, and you can give me some docs Best Regards, RD Division SW30, Inventec (Shanghai) CO.,LTD Add.: 7F, No.1295, Yi Shan Rd., Shanghai, China P.C. : 200233 Tel.: +86(21) 54261366 Ext:1710 E-mail: Tao.Qian@inventec.com
XFree version problem
Hi Folks, My apologies for the general nature of this query. I have a program using X-Toolkit GUI running fine under the XFree that comes with RedHat Linux 5. I have upgraded to RedHat Linux 8 (newer version of XFree86), and the window painting no longer works correctly. Windows that should be refreshed are not being, and other windows are left black, etc. I am guessing this is a result of changes to the XFree86 code. I am sure that I am not the first person to come across this, so I am hoping for some info to help me resolve this. Many thanks, Greg Email: [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Questions about Widgets in X window and XMoveResizeWindow
Hello everyone,
Now I found my code works when the application window is not full screen size!
But when the original window is maximized window, this program doesn't work.
Does anyone can point out how to make it work even from maximum size?
Thanks.dd jj [EMAIL PROTECTED] wrote:
Hello thank you for helping, honestly I am brand new for Xlib programming, I checked my program, still can't figure out the problem: If I create a window my self, then use xwinfo to get the window Id as one parameter of XMoveResizeWindow, it works, but when I change the window id to be another application's id, such as Xclock, it just can't work, here's my codes:
#include .
...
main()
{ Window win = 0x1e1; //window's id got from xwininfo
Display *dsp = XOpenDisplay(NULL);
XMoveResizeWindow(dpy, win, 0, 0, 100, 500); //resizing and moving window
XFlush(dsp);
}
If I set win to be a window id of my own application, it works,
why it just doesn't work for other application like Xclock?
Thanks for help.
[EMAIL PROTECTED] wrote:
Cópia dd jj <[EMAIL PROTECTED]>: Hello everyone,Hi, I hope this is the correct mailing list to post these questions... Could you please give some comments on them? thanks. 1) Now I want to search a button with specific caption, such as "Save" or "Cancel".. "Ok" on X window (no matter GNOME or KDE) screen. Can I implement this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or it's toally impossible?I think there is no standard way of doing it. And, frequently buttonsare not even separate windows. Probably in most cases it is only possibleto retrieve this kind of information from the same program; Xt basedtoolkits can use the XEditRes protocol, see the editres program. As my understanding, The button in Gnome is built using GTK but
that in KDE is built using Qt, they are different widgets belong to differen Toolkit, right? But since GTK and Qt are both based on Xlib, I am wondering whether we can handle this using lowest level Programming - xlib?You can use Xlib in both toolkits, assuming your program is only mean'tto run under X, but you cannot expect reliable behaviour depending on theXlib functions you call. Or maybe I can only program using GTK for GNOME, using Qt for KDE separately for different desktop enviroment?You can use any toolkit uder any desktop. 2) I tried to use XMoveResizeWindow to move a X window application such as Xclock, or Xcalc, I parsed the window ID "w" got from xwininfo and display dsp = XOpenDisplay(NULL) to it like: XMoveResizeWindow(dsp, w, 0, 0, 200, 200); it doesn't work, but when I creat my own window application using
XCreateSimpleWindow, then it can work. Seems the display parameter is different every time when implement: dsp = XOpenDispaly(ULL) ? Did I miss something to deal with such existing Application window?Did your program enter an event loop? It is a common mistake tosend X requests, but the program exit before they are processed.Normally calling XSync or XFlush before exiting is enough. Thank you for help me out. - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design softwareYou can see some "low level" information on toolkits and programmingwith Xlib in the famous Kenton Lee site:http://www.rahul.net/kenton/xsites.framed.htmlThere you can also find some tutorials on X programming.Paulo___Devel mailing
list[EMAIL PROTECTED]http://XFree86.Org/mailman/listinfo/devel
Do you Yahoo!?Yahoo! SiteBuilder - Free, easy-to-use web site design software
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
