Re: [XFree86] xfree4.3 xf86config issue
Citando Pedro Pinto [EMAIL PROTECTED]: xfree4.3 as in slackware 9.1 there is a problem with xf86config if a range of 31.5-92 khz is specified for the monitor and then the hz field is like 50-85 then then null is printed to the configuration file instead of 50-85 Hi, I just checked the code. It does not check the input. I believe you have specified the values in the prompt for the vsync range. Please try: # xf86cfg -textmode -nomodules for an alternative to the xf86config program. sory for the bad english Pedro Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
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: [XFree86] Is XF86Config-4 sensitive to
Is XF86Config-4 sensitive to tabs, white space, ^M etc. We have a lot No, the parser just ignores these characters; but if identical configuration files only differing on these characters have different behaviour, there may be some subtle bug in the parser. of similar machines ( all using Nvidia) which we constantly change/rebuild the OS, monitors etc. Sometimes on two identical machines one will work with the XFconfigfile and the other won't. Seems that if the file is ftp'd in bin or acsii will make a diff. Using vi with a :set list shows both tabs and white space. Is there a convention or Tanks in advance Please send the logfile of the two computers when this happens. The configuration file on both computers would also be useful. Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XF86MiscSetGrabKeysState and AllowDeactivateGrabs
Quoting Jamie Zawinski [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: If the options AllowDeactivateGrabs and AllowClosedownGrabs are not specified in XF86Config, the function will always return a success status. So, does this function disable *only* C-A-KP-slash/star, or does it disable *all* the magic key sequences? That's what I couldn't figure out from reading the source. Only Ctrl+Alt+KP_Divide and Ctrl+Alt+KP_Multiply. (People request all the time that when the screen is locked, it should be impossible to switch to another VT, or to kill the server. But of course they want to be able to switch/kill when the screen is unlocked, so just turning those keys off permanently in XF86Config isn't what they want.) I understand, this shouldn't be too hard to implement on top of the existing interface. But the reason for the addition of those key sequences was just to allow users to have better control of keyboard/mouse grabs. -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XF86MiscSetGrabKeysState and AllowDeactivateGrabs
Quoting Jamie Zawinski [EMAIL PROTECTED]: Hi, Hi, Someone just brought to my attention this recent (?) addition to the XF86Config man page: Option AllowClosedownGrabs boolean [snip] Well, since I'm the author of xscreensaver, I guess I'm the one who is expected to be updating that screen saver/locker... But after quite a bit of searching, I can't find *any* documentation about this purported API that was added! I did see this message, which gave me the name XF86MiscSetGrabKeysState: http://www.spinics.net/lists/xf-xpert/msg03301.html but I can't find *any* documentation on that function. Google has only three hits on it, and those are the (uncommented) source. Unfortunately, the only documentation is the sources. The only API function is: int XF86MiscSetGrabKeysState( Display*/* dpy */, Bool/* enabled */ ); and the possible return values are: /* return values for XF86MiscSetGrabKeysState */ #define MiscExtGrabStateSuccess 0 /* No errors */ #define MiscExtGrabStateLocked 1 /* A client already requested that * grabs cannot be removed/killed */ #define MiscExtGrabStateAlready 2 /* Request for enabling/disabling * grab removeal/kill already done */ What exactly does it do? What are the consequences of calling or not calling it? If the options AllowDeactivateGrabs and AllowClosedownGrabs are not specified in XF86Config, the function will always return a success status. Else, it will only fail if another program already requested a temporary disable of the key sequences, or if the program is calling it twice. It also uses the XF86Config option AllowNonLocalModInDev, that defaults to off, to allow, or not, remote clients from disabling the keyboard sequence; this is actually one of the main reasons for that functionality, remote applications running over a slow link can make X unusable for a large amount of time during keyboard/mouse grabs, as well as broken apps. This interface was made available for XFree86 4.2.0, the code will need to make sure it is running under the XFree86 server, as well as make sure the required version of the XF86Misc extension is available. I am really sorry about the missing documentation. I was going to update the XF86Misc manpage, but the Imakefile change says it is not being installed since: -- revision 3.5 date: 2000/03/04 01:07:33; author: dawes; state: Exp; lines: +19 -3 don't install out of date man pages -- It is just expecting someone to volunteer in fixing/updating it (I am really not the best person to write english documentation)... Thanks, -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
WheelMouse in FreeBSD --- was Re: [XFree86] (no subject)
Quoting nathan [EMAIL PROTECTED]: I got it working, with these settings in /etc/rc.conf: moused_enable=YES moused_flags=-z 4 5 moused_port=/dev/psm0 moused_type=auto And /etc/X11/XF86Config: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol Auto Option Device /dev/sysmouse Option Buttons 5 EndSection How can i get my Microsoft WheelMouse to work in FreeBSD i thought it was suppose to be added to the xf86config: option Buttons 5 option ZAxisMapping4 5 Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works They are 'old layouts'. % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work They are new ones. The thing is new layouts have three-four levels and need a modifier bit for switching to those levels. But all real modifiers are already used: Lock, Shift, Control - according their names, and unnamed ones (Mod1-Mod5) are Alt, Meta, NumLock, ScrollLock and one for a Mode_Switch emulation for compatibility with the core protocol. Thus for the new ThirdLevel modifier I had to sacrifice one of them. The ScrollLock modifier seems me most unused and now this bit is used as the ThirdLevel modifier (of course the ScrollLock key still prodice a corresponded keysym). But the ScrollLock indicator still configured to show state of modifier bound to the ScrollLock keysym. I think if complaints will come I'll make an option that maps the ScrollLock virtual modifier to some real one. Otherwise we can use the indicator for something else. I think there won't be too many complaints about the ScrollLock leds not working. I am just not sure if there aren't programs that rely on ScrollLock working as before. For safety, I believe a xkb option for that case would be a good idea. BTW, I just tested the changes for MouseKeys, it is now working properly, thanks Ivan. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] xc/lib/Xaw/Imakefile lacks Private.h and XawI18n.h in HEADERS and so on
Quoting Hideyuki KURASHINA [EMAIL PROTECTED]:
Hi,
Hi,
Is there any reasons why
(a) xc/lib/{Private,XawI18n}.h not installed
to /path/to/X11R6/include/X11/Xaw ?
These are private headers, that define internal functions/macros.
While this did not change for a while, contents in these headers are
not guaranteed to be always available.
(b) xc/lib/Xaw/Template.c installed to /path/to/X11R6/include/X11/Xaw
?
This file just defines the basic structure of a new widget definition,
there isn't really too many reasons to install it tough, as anyone willing
to write new Xaw widgets will probably need the full Xaw sources, at least
as a reference.
I couldn't find those reasons from cvsweb
URL: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xaw/Imakefile
I hope this patch (to xc/lib/Xaw/Imakefile rev. 1.10) helps.
[snip]
@@ -128,6 +129,7 @@
SmeBSB.c \
SmeLine.c \
StripChart.c \
+ Template.c \
Text.c \
TextSink.c \
TextSrc.c \
@@ -179,6 +181,7 @@
SmeBSB.o \
SmeLine.o \
StripChart.o \
+ Template.o \
Text.o \
TextSink.o \
TextSrc.o \
The template widget doesn't need to be compiled, it is just a sample,
and it does nothing.
Sincerely,
-- rushani
o XFree86 version
% XFree86 -version
XFree86 Version 4.2.1 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 3 September 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/)
Build Operating System: FreeBSD 4.7-STABLE i386 [ELF]
Module Loader present
o Operating System
% uname -v
FreeBSD 4.7-STABLE #0: Thu Feb 6 02:08:38 JST 2003
o Area of the problem
Xaw
o Which X server
XFree86 (The XFree86 4.x server)
o Repeat by
(a)
% ( cd /path/to/X11R6/include/X11/Xaw/ ; ls *.h )
/tmp/installed-headers
% ( cd /path/to/xc/lib/Xaw/; ls *.h ) /tmp/dist-headers
% diff -u /tmp/{installed,dist}-headers
I got following output;
--- installed-headers Mon Feb 10 22:14:43 2003
+++ dist-headersMon Feb 10 22:17:04 2003
@@ -32,6 +32,7 @@
PannerP.h
Porthole.h
PortholeP.h
+Private.h
Repeater.h
RepeaterP.h
Reports.h
@@ -66,5 +67,6 @@
VendorEP.h
Viewport.h
ViewportP.h
+XawI18n.h
XawImP.h
XawInit.h
(b)
% ls /path/to/X11R6/include/X11/Xaw/*.c
I got following output;
/usr/X11R6/include/X11/Xaw/Template.c
If you have interest in working in Xaw or creating new widgets, there
is really plenty of work to be done regarding to i18n, and better support
for oriental languages :-)
Paulo
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: Hi, A short introduction: Any key in XKB can have keysyms, xkb actions, a virtual modifier(s) and some flags describing a key behavior such as 'repeat', 'locking' and so on. A core protocol knows about keysyms only. If one changes a keysym binding using the core protocol it can happen that the keysyms only will be moved but not actions or behavior flags. To solve this compatibility problem the XKB has a special 'compatibility map' which sets a relation between keysyms and other attributes a key can have. Thus when some keysym place in the keyboard map is changed the XKB searches this keysym in the compatibility map and if the keysym is found there it also moves an action and flags to the key. The same procedure the XKB does after any keyboard map loading (even it made by an XKB protocol). Therefore although an action of key can be specified in the symbols map directly it is a common way to tie the action to some special keysym in the compatibility map (xkb/compat/* files) and specify that keysym in the symbols map. Also each key has 'protection flags' which can protect the key from such changes. These flags are - 'forbid all changes' (include an action, a virtual modifier and other flags) - 'forbid a repeat flag change' - 'forbid a lock flag change' - 'forbid a modifier change' All written above you can read in XKBproto or XKBlib documentation. But you can't find there when and how those protection flags are set. The xkbcomp program does it using rules: - if any action for some key is specified directly in the symbols file the 'forbid all changes' flag should be set for this key - if a repeat flag is specified there the 'forbid a repeat flag change' bit should be set. - and similar rules for a locking flag and a virtual modifier. Now you can guess what happened with 'mouse actions'. Since new special actions were specified directly in the symbols map the xkbcomp set the protection flags for the corresponded keys and the 'mouse actions' which are tied to keysyms in the compatibility map now can't be bound to those keys. A disappearing of autorepeat isn't so clear but caused by the same reason. There are some details in an XKB design (I consider them as bugs) which lead to it. All keys initialy have not an autorepeat mark unless it explicitly specified in the symbols map (you know there are not such explicit spcifications in existent maps). The XKB sets these marks (bits) after a new map loading but does it for each key separately after attempt to apply a compatibility map ( of course if the key has not any keysyms mentioned in that map the autorepeat mark will be set unconditionaly). Thus if the key has the protection flag the XKB interrapts compatibility map applaying for this key and 'forgets' to set autorepeat but to the key. Thus you see the autorepeat losing is rather a bug and can be fixed (we need to make all keys marked as repeating initialy or to place the procedure which sets those marks before the protection bits checking). But disappearing of the 'mouse actions' is a feature of the XKB and can't be avoided without some redesign of XKB. Therefore a solution for the second problem is to 'make all actions equal in their rights'. It means - specify the mouse actions (and the repeat flag) in the same place where the 'special actions' are (e.g. in the symbols map) - or move the special action to the compatibility map. In the second case we need to introduce some new keysyms (something like xf86_Next_VMode, xf86_Prev_Mode, xf86_Ungrab, etc.). But we even don't need to add them to the keysymdef.h file but can use the lib/X11/XKeysymDB file instead. I have tested both solutions and it works in both cases. And I can make a patch quickly. But we have to chose one. As for me I prefer the second one becouse it is the way used for all other xkb actions. Any suggestions? Thanks for the explanation Ivan. I think creating a compatibility map seens the more sensate solution. I am just not sure what is the more robust/easy to maintain/predictable solution, but my instincts says it is the second option :-) Err, I think is just found another problem, forgive me if it is a known problem (and I missed some email about it), but for example: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work These are the settings I normally use, Scroll_Lock is of no use for me under X, but this maybe be a problem. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED]
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: 'xset r keycode' works. I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click Both problems are side-effects of an adding 'special key sequences' such as Ctrl+Alt+Keypad +, Ctrl+Alt+Keypad -, etc. (You see only keys that have a special action are affected.) Tommorow I will write an explaination and will try to offer a workaround for both problems. Thanks. My understanding of xkb isn't very good, but, could the new special key sequences be implemented as MouseKeys, i.e. as the descriptions in xkb/compat? (but always enabled). -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Bounce Keys AccessX setting
Quoting Jeremy Wilkins [EMAIL PROTECTED]: Hi, Hi, How do I set the AccessX settings in XF86Config-4. I've been unable to find anything about AccessX in the man page, but XFree86 appears to support the option, I can set them from within gnome2 but I want the setting to be systemwide. xf86cfg has an interface for accessx settings, and will save the configuration in a xkb specific configuration file, that may override XF86Config options; normally /usr/X11R6/lib/X11/xkb/X0-config.keyboard, where the 0 is the display number. At some time I considered adding accessx configuration to XF86Config, but there was already code done for a xkb specific configuration file, so I used the existing code. Xfree 4.2.0; Kernel 2.4.19; MDK9.0 Thanks Jeremy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 Paulo ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
A simple Xcursor theme for core cursors
Hi, I built a set of the core cursors (only size 16), for testing, it is available at http://www.conectiva.com.br/~pcpa/xcursor.tar.gz To build/test/install: $ tar zxvf xcursor.tar.gz $ cd xcursor == for sh $ for f in *.cfg; do xcursorgen $f `echo $f | sed -e 's@.cfg@@'`; done == for csh % foreach f (*.cfg) xcursorgen $f `echo $f | sed -e 's@.cfg@@'` end $ rm -f *.png *.cfg as root: # mkdir -p /usr/X11R6/lib/X11/icons/cursors/core # cp -f * /usr/X11R6/lib/X11/icons/cursors/core after that just test any app, example: == for sh $ (XCURSOR_THEME=core xedit) == for csh % (setenv XCURSOR_THEME core; xedit) If you want it as a default cursor theme, you can edit $HOME/.Xdefaults and add the line: Xcursor.theme:core This is a very simple theme, the cursors have very little transparency and the shadows are almost invisible when the cursor is over dark backgrounds. Well, this theme was created just for testing, after doing this, I was thinking that probably the best way to create cursor themes should be something like: 1) Draw the cursors in a vetorial drawing program. Try to use only lines in multiples of 45 degrees, and keep it simple. 2) Convert it to a pixmap, a good bet is 96x96, and lines with width 8, than it should be required little retouch when scaling it to create the 12, 16, 24, 32 and 48 sizes. These are just my ideas, I am very bad at gimp..., I don't think I will create some real artwork theme :-) Note that I am not proposing it to be the XFree86 4.3.0 default theme, as I said earlier, I did it only for testing. I would prefer redglass as the default for XFree86 4.3.0, at least for me, it is very good... Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Xpert]Re: CVS Update: xc (branch: trunk)
Quoting Branden Robinson [EMAIL PROTECTED]:
Hi,
437. Fix the number of beeps when using AccessX and XKB
(#A.1302, Alan Coopersmith).
I applied this patch to Debian's 4.2.1-4 packages and I have a report
that this causes nonstop beeping until the server exits if one uses
PointerKeys_Enable (i.e., Shift-NumLock).
I just reproduced this, and am going to have to restart my X server.
:(
Is the above patch perhaps dependent on some other changes to XKB
post-4.2?
Please try this patch:
--
Index: xc/programs/Xserver/xkb/ddxBeep.c
===
RCS file: /opt/XFree86/xc/programs/Xserver/xkb/ddxBeep.c,v
retrieving revision 3.8
retrieving revision 3.9
diff -u -r3.8 -r3.9
--- xc/programs/Xserver/xkb/ddxBeep.c 30 Oct 2002 12:52:44 - 3.8
+++ xc/programs/Xserver/xkb/ddxBeep.c 5 Dec 2002 21:59:00 - 3.9
@@ -322,7 +322,7 @@
next = SHORT_DELAY;
break;
}
-if (duration0) {
+if (timer == NULL duration0) {
CARD32 starttime = GetTimeInMillis();
CARD32 elapsedtime;
--
This may not be the best fix, but corrects the problem if a timer being
set just when the previous one finished.
--
G. Branden Robinson| The noble soul has reverence
for
Debian GNU/Linux | itself.
[EMAIL PROTECTED] | -- Friedrich Nietzsche
http://people.debian.org/~branden/ |
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xkb, console switch, kill server, etc.
Hi, I was trying to understand a bit more the xkb code, but just to allow people involved to know, it seens to not yet be working as correctly. For example, I have used: XkbModel pc105 XkbLayout us_intl for a long time, but now, I need to patch xkb/rules/xfree86 and change: pc101 us_intl = us(pc101)+us_intl to: $pcmodels us_intl = us(%m)+us_intl I think others may be having a similar problem. I also patched xf86cfg, as it is not always succeding in calls to XkbGetKeyboard, probably due to configurations like the one I was using. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X disables ps2 keyboard if ps2 mouse not plugged in
Quoting Tomas Pospisek's Mailing Lists [EMAIL PROTECTED]: Hi, OK, I'll try again: Why does X disable the ps2 keyboard when there's no ps2 mouse? If and only if the ps2 mouse is plugged in at *boot* [1] will X give me a ps2 keyboard. Otherwise X will start perfectly but without keyboard input. In the meantime the console is just fine. Gpm is also able to use the mouse. [2] The *grave* problem with that behaveour is that lacking a network one has to *powercycle* the machine. There's no other means. And endure the fs check afterwards etc. Setup: * linux kernel 2.4.18 * debian stable * xfree 4.1 * various i386 machines Can this problem be avoided? Why does X do this? *t [1] Even before the OS boots [2] One will *not* be able switch into the console though! Try this in the console after booting with the mouse not plugged: $ cat /dev/psaux If the keyboard stops working, you should check your kernel. I saw this problem a long time ago, but don't remember how it got fixed in the Conectiva kernel, but I believe there is a kernel build option for the broken motherboards that show this problem. -- --- Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 --- Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Extracting a KeySym from an action routine
Quoting Bruce M Beach [EMAIL PROTECTED]:
Hi,
[snip]
Please CC any replies to [EMAIL PROTECTED] (my paid for account)
since I'm forced to use the spam mail due to brain-dead SpamAssassin
[snip]
Hello All
I am writeing an applications using Intrinsics, and can't
figure out how to extract the KeySym from a key event routine
once the routine is executed. I.e. I have:
XtActionsRecedit_actions[] = {
. . .
. . .
. . .
{KeyEventEditor , KeyEventEditor}
};
String edit_trans =
. . .
. . .
. . .
KeyDown:KeyEventEditor();
After a key event KeyEventEditor executes correctly and then
I want to find out what key had been pressed and act accordingly.
KeySym XtGetActionKeysym(event, modifiers_return)
looks like a likely candidate but I can't figure out what or
where event comes from or how to point to it. The only
information
that I have is:
event: Specifies the event pointer passed to the
action procedure by the Intrinsics.
Depending on what you need, just the event passed to the XtActionProc
should be enough, not sure about modifiers state, but should be ok for
the translation table sample you provided. Is the function KeyEventEditor
being properly defined? XtActionProc is defined as:
typedef void (*XtActionProc)(
#if NeedFunctionPrototypes
Widget /* widget */,
XEvent* /* event */,
String* /* params */,
Cardinal* /* num_params */
#endif
);
so the XEvent pointer is available in KeyEventEditor.
and a grep through xc/programs just shows that nobody uses it.
Suggestions or pointers would be welcome.
Bruce
=
[EMAIL PROTECTED]
__
Post your free ad now! http://personals.yahoo.ca
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Help please: How to draw lines (and posible Arcs,too) to the place of instance of coreWidgetClass
Quoting peter Fodrek [EMAIL PROTECTED]: Dear Xlib experts, Hi, I am to write program which may to draw Lines and Arcs on the place where instance of coreWidgetClass is displayed ... I am not to find what I am doing wrong... Can Anyone help me,please? thank you for any help... yours faithfully Peter Fodrek P.S. source code of my failed attempt to do so is included.. file grafika contains tezt, which shows that function init_kresliaca was called, but nothing was displayed on the white coreWidgetClass instance [snip] From the sample it is not possible to know if your application is calling XtAppMainLoop. If it is not, you may still get the drawings on the screen by calling XFlush(), but what you should do is probably one of: o use XtAddEventHandler to handle Expose events o add a XtActionProc to handle Expose events and define a translation table like: Expose: my-expose-handler() o Add a subclass of the core widget and set the XtExposeProc field o Draw to a pixmap and set the backgroundPixmap resource Just some options from what I could understand from the small code sample. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xterm ::libXaw unresloved sysbol XmuCvtGravityToString
Quoting P.R. Patil [EMAIL PROTECTED]: Hi, hello, Pls see the following problem I' trying to execute the X windows on a m/c using XF86_FBDev driver and linnux 2.4 CS5530 graphics chipset Frame buffer support with 16bit color depth It gives me the first blank screen with crossed cursor and hangs there.The error is undefined symbol boldXmuCvtGravityToString /boldwhile loading the shared library libXaw.so.7 Can anyone pls help me out It seens to be an application that failed to start because it was linked with libXaw, but not with libXmu. Try finding out which application failed to start, probably in some initialization script, and run it as: LD_PRELOAD=/usr/X11R6/lib/libXmu.so the-program Yes the failed application is xterm. But I saw many script files but in none of them the the above line is there. Pls let me know the name of the file where it should be or is it a env variable You shouldn't need to do it, applications linked with Xaw should also link with Xmu. Are you building X from scratch? Is this a CVS snapshot? Maybe your xterm is linked with an alternative Xaw, like Xaw3d, just guessing... Thanks and Regds, PR ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XF86_FBDev : libXaw.so.7 :error while loading undefined sysmbol
Quoting P.R. Patil [EMAIL PROTECTED]: Hi, colorparam0100,0100,0100/paramHello, I' trying to execute the X windows on a m/c using XF86_FBDev driver and linnux 2.4 CS5530 graphics chipset Frame buffer support with 16bit color depth It gives me the first blank screen with crossed cursor and hangs there.The error is undefined symbol boldXmuCvtGravityToString /boldwhile loading the shared library libXaw.so.7 Can anyone pls help me out It seens to be an application that failed to start because it was linked with libXaw, but not with libXmu. Try finding out which application failed to start, probably in some initialization script, and run it as: LD_PRELOAD=/usr/X11R6/lib/libXmu.so the-program nofill Thanks and Regds, PR ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]New xedit syntax highlight code
Hi, I finally added the new syntax highlight code to xedit. The old builtin C mode was removed, now it is done by the lisp interpreter, and the rules can be changed in /usr/X11R6/lib/X11/xedit/lisp/progmodes/c.lsp. It does not yet load any defaults from the user home directory, but is being done in a way that will allow it in future versions. If you aren't using the current CVS, and likes hacking around, just checkout the latest versions of xc/lib/Xaw and xc/programs/xedit and recompile/install just these. I believe it should be very simple to understand the rules for creating new syntax highlight definitions. If you do so, just don't forget to update xedit.lsp to add a rule to the *auto-modes* list, so that the file will be recognized when loaded. I would like to have a copy of such new syntax highlight definition, to add it to the oficial version. IF you were using the old c mode in a slow computer, you may notice that it is now significantly slower to load the file. This is because it does not yet render the syntax highlight in the background. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X return segmentation fault when trying to start it
Quoting Tino Keitel [EMAIL PROTECTED]: I suggest compiling XFree86 with the optimization flags, but also with -g, and run it under the custom gdb at ftp://ftp.xfree86.org/pub/xpert/gdb Do it from a remote computer. It is dependant on your compiler version, snapshots may have bugs. But most times I found this sort of problem and could figure out what was wrong (sometimes I just find the chunk of code that is breaking and rewrite it...), it was some program error, like writting past the start/end of a stack buffer, uninitialized data that happens to have the same contents after some time (anything that was left in the heap after malloc/free calls), etc. Seem strange to me that a software like XFree86 cannot use optimization FLAGS durring compile time. Here is what I used as optimization -- -O2 -march=i686 -funroll-loops and XFree86 fail. Again without the previous optimization FLAGS, all run ok. For me, this mean that XFree86 cannot be compiled to get advantage of i686 CPU architecture :(( I would think about this in a different way. In my point of view, this is a code generation bug in the compiler (gcc?). In a perfect world, any piece of source code should compile and work perfectly even with the most exotic optimization flags turned on. I also had this problem with other software. Most of the time I could determine _one_ source file that will be broken with _one_ certain optimization option. I would at first try to build without the -funroll-loops option. Regards, Tino -- [EMAIL PROTECTED] dipl.-inf.Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3308 http://www.innominate.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [j_r_fonseca@yahoo.co.uk: Re: [Xpert]Is the XFree development stuck in a dead end?]
Quoting José Fonseca [EMAIL PROTECTED]: Go Georgina, Go! I really love reading Georgina's posts, besides I normally don't take them too seriously, sometimes it's so fun :-) I am not a native english speaker, but I will not be surprised if José Fonseca is brazilian or portuguese (maybe spanish). José is one of the most common brazilian first names, probably only missing the first place to João. Fonseca is a not so common last name, but was the last name of the first brazilian president (http://www.infoplease.com/ce6/people/A0819082.html). People should learn to tolerate each other... I know that is not good nettiquete to post private mails, but I never take insults from nobody, even from pour souls with trouble understanding english. Also thanks to those who sent me mails telling to ignore Georgina, even though they didn't imagine what was actually going on. I just wish I had had that option. José Fonseca - Forwarded message from José Fonseca [EMAIL PROTECTED] - Date: Tue, 16 Jul 2002 22:03:50 +0100 From: José Fonseca [EMAIL PROTECTED] Subject: Re: [Xpert]Is the XFree development stuck in a dead end? To: G O Economou [EMAIL PROTECTED] On Tue, Jul 16, 2002 at 04:06:21PM -0400, G O Economou wrote: - Original Message - From: José Fonseca [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 16, 2002 2:17 PM Subject: Re: [Xpert]Is the XFree development stuck in a dead end? [...] You are a sexist pig. English is my native language. I was born in America. My name has nothing to do with my national identiy but you being a racist probably cannot understand that can you? Don't both answering, you're total filth and a sexist animal. PS There is no way you knew my sex by my post. What are you talking about!? I have no idea what is your sex nor do I care! I know your full name because you already emailed personally to me! (See below) I _really_ thought you _could_ be from a foreign language (greak) due to your name - Georgina Economou -, and I _explained_ that my email. It's the third time already I have to explain my words to you, and you still wonder I think you're not a native speaker!? I *demand* an apology for this unrespectfull email ASAP. I never disrespected you in anyway, even when you insinuated I wasn't an adult, and I won't tolerate these insults. José Fonseca - Forwarded message from Georgina O Economou [EMAIL PROTECTED] - Date: Sat, 1 Jun 2002 22:15:03 -0400 From: Georgina O Economou [EMAIL PROTECTED] Subject: Re: Membership request To: José Fonseca [EMAIL PROTECTED], [EMAIL PROTECTED] On Tuesday 14 May 2002 06:10 am, José Fonseca wrote: I would like to request membership to the XFree86 development team. I have contributed several patches indirectly to XFree86 via the DRI and Mesa projects (of which I'm a developer) that will eventually reach the repository, but if you wish me to send a fix to [EMAIL PROTECTED] I'll surely think of something. The reason for my interest is mainly to be able to access the other XFree86 developers and follow the XFree86 development more closely via the internal lists. I don't foresee the need of commit access to the repository as my interests remain on the 3D rendering. Regards, José Fonseca Application attached. Send it back. AFter it's approved wnen you join announce yourself on devel. Georgina --- - End forwarded message - - Forwarded message from G O Economou [EMAIL PROTECTED] - Date: Tue, 16 Jul 2002 17:25:01 -0400 From: G O Economou [EMAIL PROTECTED] Subject: Re: [Xpert]Is the XFree development stuck in a dead end? To: José Fonseca [EMAIL PROTECTED] - Original Message - From: José Fonseca [EMAIL PROTECTED] To: G O Economou [EMAIL PROTECTED] Sent: Tuesday, July 16, 2002 5:03 PM Subject: Re: [Xpert]Is the XFree development stuck in a dead end? On Tue, Jul 16, 2002 at 04:06:21PM -0400, G O Economou wrote: - Original Message - From: José Fonseca [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 16, 2002 2:17 PM Subject: Re: [Xpert]Is the XFree development stuck in a dead end? [...] You are a sexist pig. English is my native language. I was born in America. My name has nothing to do with my national identiy but you being a racist probably cannot understand that can you? Don't both answering, you're total filth and a sexist animal. PS There is no way you knew my sex by my post. What are you talking about!? I have no idea what is your sex nor do I care! I know your full name because you already emailed personally to me! (See below) I _really_ thought you _could_ be from a foreign language (greak) Greek due to your name -
Re: [Xpert]Re: Is the XFree development stuck in a dead end?
Quoting Mike A. Harris [EMAIL PROTECTED]: I personally don't see any alternative to overcome the current problems of XFree. I don't see real problems in XFree, and think that one of the best features of X is the networking capabilities. Indeed, have a look to how easy is to have xinerama on two different video cards. Do this with windows or macos. It's hard, if not impossible at all. Is that a joke ? Did you ever try to set up a second gfx card and monitor under Mac OS ? It's a breeze, just point'n'click. Whereas in X, you have to hunt for the Xinerama HOWTO and mess with the config file. xf86cfg has multihead configuration built in, although it isn't what I personally consider user friendly. This is something that will become more friendly in the future though as multihead becomes much more popular. :-) I wan't to stop someday and write code for a better multihead configuration interface in the textmode (currently it just adds new screens to the left of the last one). For the graphics interface, I plan to write a wizard mode, similar to the text interface. And also, make this wizard mode allow configuring everything without the need of a working mouse; curently if the mouse does not work, it is required to use xkb mousekeys, and this really is not user friendly :-) Anyway, the code is there, and I don't mind if someone uses part (or all) of the xf86cfg code in a Gtk or Kde interface. I just think that any such code should use libxf86config, so that if it reads an existing XF86Config file, when writing a new one, does not miss any information from the previous configuration file (in the current libxf86config, comments may be rewritten out of order, but are not lost). -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CyberBlade/XP and xterm menus
Quoting Neale Banks [EMAIL PROTECTED]: On Wed, 10 Jul 2002 [EMAIL PROTECTED] wrote: [...] The menus may have a gradient or bitmap backgroundPixmap. Check with editres: Commands-Get Tree select the xterm window select the fontMenu toggle Commands-Show Resource Box check if the backgroundPixmap is anything other than XtUnspecifiedPixmap Indeed backgroundPixmap has a gradient, and I can make the symptoms move by tweaking the values of the gradient. This may happen because menu entries are painted with a xor gc, and the effect is more visible if you are running at 8bpp. AFAICT, I'm running 16bpp (pardon the ignorance, but how would I confirm this?). I take it that means it would be expected to be worse at 8bpp? Run xdpyinfo to verify the depth. Yes, in 8bpp it is worse, but in 16bpp the number of colors is slightly limited, gradients aren't always very smooth (and it's inverse, produced by the xor gc may be even worser). If this is the case, you can add: XTerm*SimpleMenu.backgroundPixmap: XtUnspecifiedPixmap to your $HOME/.Xdefaults Yes, using editres to change the backgroundPixmap value to XtUnspecifiedPixmap makes the symptoms go away. Is this a bug? If so, in what? No, it is not a bug. If you run at 24bpp it should not be noticeable. This is a feature of the Xaw SimpleMenu widget when using a backgroundPixmap. To fix this it is required to change the code to not use a xor gc, and to get a better visual effect, it should also mask pixmaps, instead or painting with the background color (this is valid for all widgets, mostly notably the leftPixmap resource of LabelWidget and it's subclasses). I will put this in my todo list of updates to Xaw. FWIW, I've just reproduced it with the stock trident_drv.o in 4.2, so I figure it's not to be blamed on the trident_drv.o from http://www.xfree86.org/~alanh Thanks, Neale. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CyberBlade/XP and xterm menus
Quoting Neale Banks [EMAIL PROTECTED]: Hi, I've got an odd quirk in xterm's menus with: * Toshiba Satellite 1800, with CyberBlade/XP * Linux 2.2.21, built with vesafb support * Debian woody and pre-release xfree86 4.2.0-0pre1v1 * trident_drv.o from http://www.xfree86.org/~alanh/ In each of the Main Options, VT Options and VT Fonts an entry approximately in the middle of the list gets a horizontally-striped background of three different colours. Camera snapshot is at: http://www.planet.net.au/~neale/images/vt_menu_1.jpeg Hmm... not so clear - the Medium entry actually has a black, mauve and grey background (others just have a black background). Any idea what's up here? The menus may have a gradient or bitmap backgroundPixmap. Check with editres: Commands-Get Tree select the xterm window select the fontMenu toggle Commands-Show Resource Box check if the backgroundPixmap is anything other than XtUnspecifiedPixmap This may happen because menu entries are painted with a xor gc, and the effect is more visible if you are running at 8bpp. If this is the case, you can add: XTerm*SimpleMenu.backgroundPixmap: XtUnspecifiedPixmap to your $HOME/.Xdefaults Thanks, Neale. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HELP !!! (EE) RADEON(0): [agp] AGP not available
Quoting Junior, Ricardo [EMAIL PROTECTED]: Hi Xpert people !! : ) Hi :-) I can't get my Radeon driver to work... I will explain about the envirounment and what I have already done. System: Mandrake 8.2 (without any graphical package: Xfree, KDE, Gnome...); GCC 2.96 (default from mandrake 8.2); Xfree86 4.2 + Fixes files (get in 06/28/2002) compiled without errors; XF86Config file generated by command XFree86 -configure, that is been changed yet...; Kernel 2.4.18 (default from mandrake 8.2); Radeon kernel module loaded on boot; Agpgart kernel module loaded on boot; /dev/dri/card0 with access to read/write/excute for every user; /dev/agpgart with access to read/write for every user; Hardware: All-In-Wonder Radeon 32mb MoBo PC-Chips M830 (chipset SiS735) 128mb RAM DDR SB Live MP3+ 5.1 M$ Wheel Mouse Optical KDS Visual Sensation 14 Here is my logs and configuration file: (zipped because the size...) * XF86Config; * XFree86.0.log (from /var/log); and * xdpyinfo.log (from xdpyinfo command ran on X) The X is running... but not as it should be... just work resolution 640x480 !!! Some suggestions: Try changing the order of the modes in XF86Config. Put 1024x768 first. You may try other values for the AgpMode option. Remove the path to the kernel modules from the Files section. Try running at different depth, 16 and 24. Help... I don't know what more can I do... Thanks, Ricardo Jr. Boa sorte, Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Grab key, mouse to a single window
Quoting root [EMAIL PROTECTED]:
Hi Xperts,
Can anyone help me how to grab all key events and send
them to a single window. Also when i do any mouse operations
it should take only those operations done on that window.
Like say i opened a dialog box. Until i close the window the focus
shouldn't go to any other window. Any key i press should be directed
to the dialog
I tried something and i have attached. but the window couldn't
get the key and mouse input
Can somebody give me clear picture!
Thanks,
Jeyasudha.
The sample code seems to be working, but you should check for
GrabSuccess and not GrabFrozen when grabbing the keyboard. Why
not just call XGrabServer?
Just a hint to anyone trying this:
Make sure the ServerFlags section in XF86Config has the options
AllowDeactivateGrabs and AllowClosedownGrabs or you will not
be able to close the test program. Something like:
Section ServerFlags
Option AllowDeactivateGrabs
Option AllowClosedownGrabs
EndSection
propaganda
AllowDeactivateGrabs releases any active grab when pressing
Ctrl+Alt+Keypad-Divide.
AllowClosedownGrabs closes the conection to the grabbing client
when pressing Ctrl+Alt+Keypad-Multiply.
These options also work when the client program called XGrabServer.
Note that these options will allow users to bypass screen savers.
I wrote this small/simple example of how to disable the options from
a screensaver:
#include stdio.h
#include stdlib.h
#include string.h
#include signal.h
#include X11/Xlib.h
#include X11/extensions/xf86misc.h
int
main(int argc, char *argv[])
{
int xfree86, major, minor;
Display *display = XOpenDisplay(NULL);
if (display == NULL) {
fprintf(stderr, Cannot open display.\n);
exit(1);
}
xfree86 = strstr(ServerVendor(display), XFree86) != NULL;
if (xfree86) {
signal(SIGHUP, SIG_IGN);
signal(SIGPIPE, SIG_IGN);
signal(SIGINT, SIG_IGN);
signal(SIGQUIT, SIG_IGN);
if (XF86MiscQueryVersion(display, major, minor) == False) {
fprintf(stderr, Failed to call XF86MiscQueryVersion.\n);
exit(1);
}
if (major = 0 minor = 5
XF86MiscSetGrabKeysState(display, False) ==
MiscExtGrabStateLocked) {
fprintf(stderr, Cannot disable XFree86 hotkeys to remove grabs.\n);
exit(1);
}
XFlush(display);
}
system(xlock);
if (xfree86 major = 0 minor = 5) {
XF86MiscSetGrabKeysState(display, True);
XFlush(display);
}
return (0);
}
/propaganda
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]is ATI Radeon 7000 Video w/ 64MB supported with xfree86 for redhat Linux 7.1
Quoting dmitri kerievsky [EMAIL PROTECTED]: when running X -configure or xf8cfg there an error message appears -Fatal server error -Module load failure any ideas how to proceed? You may have something misconfigured. Try running # xf86cfg -nomodules or even better # xf86cfg -nomodules -textmode so that it will not run X -configure to generate the initial config file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dr Andrew C Aitchison Sent: Wednesday, May 15, 2002 9:55 AM To: [EMAIL PROTECTED] Subject: RE: [Xpert]is ATI Radeon 7000 Video w/ 64MB supported with xfree86 for redhat Linux 7.1 On Wed, 15 May 2002, dmitri kerievsky wrote: Thanks for responding. I have followed the steps - downloaded the 4.2 binaries and run sh Xinstall.sh and xf86config. xf86config asks a series of questions and at one point lists a database of cards. The ATI Radeon is not in the list even though documentation says it is supported. Is this IIRC xf86config is obsolete in 4.2, and should have been removed. Try configuring with either X -configure or xf86cfg instead. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xf86vidmodeswitch usage
Quoting Mark Vojkovich [EMAIL PROTECTED]: Hi, Look also at the xf86cfg sources, xc/programs/Xserver/hw/xfree86/xf86cfg/vidmode.c On Wed, 6 Mar 2002, Louis Lu wrote: Hi Mark: thanks a lot for the answer, but where can I find the source code of xvidtune? if you know that. It's in the XFree86 source tree. Ships with XFree86. MArk. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: patch for xc/programs/xedit/lisp/format.c
Quoting [EMAIL PROTECTED]:
Hi,
Noticed this today when compiling X from CVS and fixed it as best as
I
could.
Hope you like it and if not let me learn how to fix it better by
telling
me.
Thanks, I applyed your patch as is :-) It will go in my next commit. I
am reworking some of the internals of the interpreter to support a slightly
simplified model of Common Lisp packages (should have the same semantics,
but not all features), to allow local variables and functions.
I also simplified the gc function and fixed a very bad bug, if you call
(gc) explicitly, it will trash some objects, and soon or later coredump, but
if the gc function is called automatically there are no problems.
Diff attached.
Thanks in advance.
Ooops, I should have sent it as plain-text but my webmailer mime'd it.
Here it goes.
Index: format.c
===
RCS file: /cvs/xc/programs/xedit/lisp/format.c,v
retrieving revision 1.16
diff -u -r1.16 format.c
--- format.c2002/02/10 02:50:06 1.16
+++ format.c2002/02/10 18:49:47
@@ -285,6 +285,7 @@
int test;
char *ptr;
FmtArg *argument;
+unsigned int tmpcmd = 0;
/* initialize */
test = objects == NULL || code == NULL || num_objects == NULL;
@@ -415,8 +416,10 @@
if (!test)
*code = NOERROR;
arguments-command = *ptr++;
-if (islower(arguments-command))
- arguments-command = toupper(arguments-command);
+if (islower(arguments-command)) {
+tmpcmd = toupper(arguments-command);
+ arguments-command = tmpcmd;
+}
++arguments-offset;
return (ptr);
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Default fonts for menus, dialogues, etc
Cópia Richard Stallman [EMAIL PROTECTED]:
Hi,
Emacs lets the user customize the colors used by menus by customizing
a special face. When the user sets the inverse video flag in that
face, for Emacs to do the right thing it must be able to determine
what colors would be used by default. It can check for resources to
specify them, but what if there are no resources--what colors would be
used then?
Xaw uses the resources XtDefaultBackground and XtDefaultForeground, that
are actually the value of WhitePixelOfScreen and BlackPixelOfScreen, or the
inverse if the resource reverseVideo is set.
Unfortunately the values of {Black,White}Pixel of screen can only be set
when running at 1bpp, but not all XFree86 drivers support 1bpp, and not all
of them will use the XF86Config options to set these values.
One suggestion was that Emacs should define fallback resources to
specify the foreground and background colors. That does enable Emacs
to determine, always, what colors are to be used. But is this proper
behavior for an application? It could mean an inconsistency between
Emacs and other applications in regard to how they display menus. Is
that a real issue?
I believe shipping a /usr/X11R6/lib/X11/app-defaults/Emacs file for
specifying default resources would be a better idea, but fallback resources
aren't completely a bad solution, better yet if it's value is programable,
and the user knows it is a fallback resource. For example, in the xedit
lisp interpreter I am working on, one can say:
(require xt)
(setq main-shell
(xt-app-initialize 'app-context MyApp '((title . MyTitle))
'(*Background: some-color *Foreground: some-other-color)))
That will set main-shell to a handle for the shell widget and will at
the same step create a new global variable (or change the value of the
lexically binded variable) app-context to a handle for an XtAppContext
implicitly created by the function.
The prototype is:
xt-app-initialize app-context-return application-class optional options
fallback-resources
But it is still subject to changes (probably for handling command line
parameters), as there is not yet a formal release of the xedit lisp
interpreter. The adavantage of using the fallback-resources argument is that
the code becomes completely self-contained, no need for an external
configuration file.
Is there some rule that says what the default menu colors should be
when there are no resource to specify them? Or is each toolkit
ideosyncratic in that regard? Currently Emacs supports the Athena
widgets and LessTif/Motif.
I believe there is no rule for this, but every toolkit has some way to
determine how it will look if no configuration was made, in the case of
Athena, it will be a simple rectangular window with white-color background,
black-color foreground, and 1 pixel black-color border.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XtAppCreateShell() fails
Quoting Ba la [EMAIL PROTECTED]:
Hi Mark,
I am opening two displays using
XtOpenDisplay()
function call after that I am creating two shells
using XtAppCreateShell(), in that my first function
XtAppCreateShell() succeeds, but the second function
call to create shell using XtAppCreateShell fails and
dumps the core, the parameters diff is the 1st
parameter app_name and the 4th parameter Display(what
I got from XtOpenDisplay) remaining all same, I didn't
find any syntax error in that 2nd call, then how come
it is getting fails ???, (I am working in 8bpp mode)
I am in the process of finding out the error, can
you give me some hints on this issue.
my questions are,
** out of two createshell functions one is succeeds
other fails, is it really error with
XtAppCreateSheel() function call or some errors with
XtOpenDisplay itself,
** is ther anyway to check whether the XtOpenDisplay
function executed properly and the display is opened
for funther operation like that.
Hi,
I just wrote this small test program, and it seens to work:
--
#include X11/Intrinsic.h
#include X11/StringDefs.h
#include X11/Shell.h
XtAppContext appcon;
Widget shell1, shell2;
Display *display1, *display2;
int
main(int argc, char *argv[])
{
Arg args[2];
Cardinal num_args;
XtToolkitInitialize();
num_args = 0;
XtSetArg(args[num_args], XtNwidth, 100);++num_args;
XtSetArg(args[num_args], XtNheight, 100); ++num_args;
appcon = XtCreateApplicationContext();
display1 = XtOpenDisplay(appcon, NULL, test1, Test, NULL, 0, argc,
argv);
display2 = XtOpenDisplay(appcon, NULL, test2, Test, NULL, 0, argc,
argv);
shell1 = XtAppCreateShell(test1, Test, applicationShellWidgetClass,
display1, args, num_args);
shell2 = XtAppCreateShell(test2, Test, applicationShellWidgetClass,
display2, args, num_args);
XtRealizeWidget(shell1);
XtRealizeWidget(shell2);
XtAppMainLoop(appcon);
return (0);
}
--
I noticed that if you pass NULL as the argc argument to XOpenDisplay, it
will try to deference it, so I believe the problem you are seeing may be
passing NULL were a valid pointer is expected. I didn't test connecting
to two different X servers, so there maybe some problem in this case.
Thanks in advance.
Bala.
__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]deadkeys
Cópia Thiago Sayao [EMAIL PROTECTED]: Oi, Deadkeys are not working on my XFree! it works on the console. See the file /usr/X11R6/lib/X11/xkb/X0-config.keyboard, it's contents should be something like: -- Rules= xfree86 Model= pc105 Layout = us_intl RepeatDelay = 699 RepeatInterval = 50 MouseKeysDelay = 160 MouseKeysInterval= 40 MouseKeysTimeToMax = 32 MouseKeysMaxSpeed= 26 MouseKeysCurve = 0 AccessXTimeout = 65535 Controls+= RepeatKeys + MouseKeysAccel Feedback+= SlowKeysPress + SlowKeysAccept + StickyKeys + LatchToLock -- Note the Model and Layout lines. These lines will override settings in XF86Config. You can remove that lines to make the XF86Config ones be used, edit the file by hand, or use xf86cfg to select the model and layout. Actually, that file will be used only for the :0 display, this needs some review for multiple keyboards and probably adding a XKB section/subsection to XF86Config. My Xfree Configuration: Section InputDevice Identifier Keyboard1 Driver Keyboard Option XkbModel pc105 Option XkbLayout us_intl EndSection My keyboard is US International. Im running Xfree4.1.0-19mdk please help! i need to use deadkeys in my language. :) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xkb+grabbing+intl. keyboard: mode_switch does not work?
Cópia Alexander Zangerl [EMAIL PROTECTED]: Hi, i'm running 3.3.6, and was up to now using xkb for my german keyboard. the problem i've encountered is: programs like xscreensaver, quintuple-agent etc. that are grabbing the keyboard for passphrase input cannot receive input that is generated using mode_switch+key, eg. @ (mode_switch+q). i've digged into both apps and added ugly printf debugging, and that is what i detected: there are two events generated, one for the keypress of altgr and one for q. XLookupString returns no string for the first event, which is ok as altgr/mode_switch is nonprintable and just a modifier. unfortunately, XLookupString does then return just q for the second event, which is wrong. all other x apps like xev that do not grab the keyboard work fine. everything works fine, if i switch off xkb totally. my xkb setup is absolutely plain, model pc102, layout de, variant nodeadkeys and options ctrl:nocaps. i went through the list archive, but i have not found anything that seems to be related to that problem. my question now is: is this a known problem? if so, how likely is a fix for this? If the application is using only XLookupString to get keyboard input, then it will not get properly composed characters (unless there is some hack in Xlib). Implementing support for 8 bit input characters is easy, and normally can be done with a simple wrap for XLookupString, with some initialization, and then calling XmbLookupString. But the real reason I am replying is to remember people that may be working with screensavers that now there are two XF86Config options that allow users to remove keyboard/mouse/server grabs, or close the connection to the grabbing client, but there is an API for disabling the keyboard hotkeys, for use by screensavers. See the function XF86MiscSetGrabKeysState. That function will do nothing if the options AllowDeactivateGrabs and AllowClosedownGrabs are not enabled in XF86Config. regards az -- + Alexander Zangerl + [EMAIL PROTECTED] + DSA 42BD645D + (RSA 5B586291) answering machine: you've reached an imaginary number. please rotate your phone 90 degrees and try again. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XrmPutLineResource for resources with newlines
I believe there is a problem in that case, for example, if I create a
fallback string list to call XtAppInitialize, with something like:
String fallback[] = {
*Text.translations: #override \
cKeyS:no-op(r)\n\
cKeyR:no-op(r)\n\
mKeyI:no-op(r)\n\
cKeyG:no-op()\n\
cKeyC:no-op()\n\
KeyEscape:no-op()\n\
KeyTab: no-op()\n\
KeyReturn:no-op(),
NULL
};
Then, when calling XtAppInitialize, the translation table will only be set
to the first line *Text.translations: #override cKeyS: no-op(r).
So, I believe XrmPutLineResource should parse the entire string, not just
until the first newline.
Does somebody see any problems if XrmPutLineResource be changed to do it?
Maybe it is required a new function, to make sure nothing breaks, but that
would require also changing Xt, to use such new function.
If that is done, the fallback resources can even be specified in a single
string...
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XrmPutLineResource for resources with newlines
[resending message, sent to wrong address]
I believe there is a problem in that case, for example, if I create a
fallback string list to call XtAppInitialize, with something like:
String fallback[] = {
*Text.translations: #override \
cKeyS: no-op(r)\n\
cKeyR: no-op(r)\n\
mKeyI: no-op(r)\n\
cKeyG: no-op()\n\
cKeyC: no-op()\n\
KeyEscape: no-op()\n\
KeyTab:no-op()\n\
KeyReturn: no-op(),
NULL
};
Then, when calling XtAppInitialize, the translation table will only be set
to the first line *Text.translations: #override cKeyS: no-op(r).
So, I believe XrmPutLineResource should parse the entire string, not just
until the first newline.
Does somebody see any problems if XrmPutLineResource be changed to do it?
Maybe it is required a new function, to make sure nothing breaks, but that
would require also changing Xt, to use such new function.
If that is done, the fallback resources can even be specified in a single
string...
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Error using X
Quoting [EMAIL PROTECTED]:
Hi,
I don't know too much about motif, but, as it is close to Xaw, the first
problem I see is that you should create the label widget with
XtCreateManagedWidget, or call XtManageChild before calling XtRealize
on the toplevel widget.
You can try a Xaw version, replacing the line:
#include Xm/Label.h
by
#include X11/Xaw/Label.h
and
wc = xmLabelWidgetClass;
by
wc = labelWidgetClass;
and create wlabel using XtCreateManagedWidget, than, link it as
gcc -o mytest x.c -I/usr/X11R6/include -L/usr/X11R6/lib -lXaw -lXt -lX11
also, instead of setting i to 0, try
i = XtNumber(args);
The program below workis fine in Unix, but I get a BadWindow error
when
running on Linux RedHat 6.2.
Could you help me?
Regards
Giovanni Colombo
ENEL.HYDRO
Business Unit Polo Idraulico e Strutturale
Via Pozzobonelli, 6 - 20162 Milano (Italy)
Tel: +39 02 7224.3649
Fax: +39 02 7224.3550
Mailto:[EMAIL PROTECTED]
---
#include stdio.h
#include X11/Xlib.h
#include X11/Intrinsic.h
#include X11/StringDefs.h
#include Xm/Label.h
Arg args[] = {
XtNlabel, (XtArgVal) Stuff,
};
main(argc, argv)
int argc;
char **argv;
{
Widget toplevel, wlabel;
WidgetClass wc;
int i;
toplevel = XtInitialize(argv[0], my-widget, NULL, 0, argc, argv);
wc = xmLabelWidgetClass;
i=0;
wlabel = XtCreateWidget(mylabel,
wc,
toplevel,
args,
i);
fprintf(stderr, status of creating label widget %d\n, wlabel);
XtRealizeWidget(toplevel);
XtMainLoop();
}
*Compiled linked using gcc version 3.0:
gcc -o mytest mytest.c /usr/X11R6/lib/libXt.so.6
/usr/X11R6/lib/libXm.so.2.1 -L/usr/X11R6/lib -lX11
*Executing, got the error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 19 (X_DeleteProperty)
Resource id in failed request: 0x0
Serial number of failed request: 92
Current serial number in output stream: 98
---
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Informations request (development team)
Quoting Georgina O. Economou [EMAIL PROTECTED]: Hello all: I'll start with a classic: congratulations for the great work. As a developer of CaixaMagica, the first Portuguese Linux distribution I would like to request some informations regarding the XFree project which is not available in www.xfree.org and would be extremely useful for our work (installing procedure for example). We guess that people in the other distros might have these knowledge but still couldn't find any related resources. We lack the necessary information to answer the following questions: i) Since framebuffer based X servers should run on every Vesa 2.0 compatible card, where can one find a list of such cards ? I believe any card that was manufacturated from around 1994 should be at least vesa 1.2. ii) How do we compare XF86_FBDev 3.3.6 with XFree 4.1 server using the fbdev driver which is available according the documentation found on www.xfree.org ? You may which to use the vesa driver to support also vesa 1.2 cards, or build Xvesa, from the TinyX sources, for the installer. Which one has better support ? What other reasoning can influence the decision ? The vesa driver and Xvesa will run on a larger amount of computers. In some very special cases, only fbdev servers will work. But to be really safe, you should also think about cases where only a vga 16 colors will work, and even some cases where only plain text modes would. iii) What XFree86 drivers have XVideo extension implementation by now? The support classification in the driver status document is not detailed engouth (accelerated/non-accelerated). The XVideo extension is very important. I am planning to add the interface for it. It won't make running xawtv (or any other such program) faster, but would provide the extension. Besides this one can build a list of XFree 4.1 supported cards by visiting every link in the driver status document, but it would be useful if you could publish a plain list just as you did for XFree 3.3.6. Keep up the good work Best regards Gustavo Homem -- _ |Paulo Trezentos ([EMAIL PROTECTED]) |http://paulo.trezentos.gul.pt |ADETTI/RSI (IS/IT Research and Development) |FP: 1B13 55A2 5045 2271 BA66 762B B2AE 7EC0 E4B3 0AB7 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Fell free to reply to me in portuguese. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
