Re: SOS....I was frustrated by cross-compiling a TinyX server
Script filesif u need...to build XFree86 are available at.. www.techibus.com/x_build.sh www.techibus.com/cross.def.patch www.techibus.com/host.def www.techibus.com/Imakefile.patch Steps to install 1. Just copy XFree86-source files 1 - 7 .tgz and all these files to a directory. 2. install ur ARM toolchain to /usr/local/arm-linux- follow handhelds.org script file to link symbolically all toolchain_directory/arm-linux/bin ... to toolchain_directory/bin 3. chmod +x x_build.sh 4. EXECUTE the SHELL SCRIPT ( ./x_build.sh) and done... On 6/9/05, Kai.Niu [EMAIL PROTECTED] wrote: Hi ALL: I was so confusing about the cross compiling process about XFree86 package. I encountered such a weird error message like below. Dose anyone know what the cc1 dose imply? I guess cc1 means a symbolic link so gcc. I make a cc1 symbol link to either arm-linux-gcc and native x86 gcc. None of them bring me out of hell. I started compiling as make World CROSSCOMPILEDIR=blablablabla. My host.def file like below: host.def /* $XFree86: xc/config/cf/cross.def,v 1.3 2002/04/04 14:05:33 eich Exp $ */ /* * This file contains redefinitions of some symbols to enable * cross compilation: e.g. paths for include files and paths to * compiler images. It will have to be edited to reflect these * given your local configuration. */ #define KDriveXServer YES #define TinyXServerYES #define CrossCompiling YES #define TouchScreenYES #undef BuildRandR #define BuildRandR YES #define BuildXInputLib YES #define ProjectRoot/root/TinyX/xc #define Freetype2Dir $(TOP)/extras/freetype2 #define Freetype2LibDir$(TOP)/exports/lib #define BuildXTrueType YES #define BuildScreenSaverExtNO #define BuildScreenSaverLibraryNO #define SharedLibXss YES #define ServerXdmcpDefines #define XfbdevServer YES #define HasZlibNO #define HasPNGlib NO *end of host.def*** And I made the necessary modification on cross.def file to present my host cross-toolchain configuration. The error message like below: **error message dump* Building XFree86 version 4.4.0 (29 February 2004). I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Thu Jun 9 06:05:25 EDT 2005 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/root/TinyX/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap rm -f imakemdep_cpp.h make[1]: Leaving directory `/root/TinyX/xc/config/imake' make Makefile.boot make[1]: Entering directory `/root/TinyX/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/root/TinyX/xc/config/imake' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR=/root/usr/local/arm/3.4.1/arm-linux/bin in config/imake cc -o ccimake -DCROSSCOMPILEDIR=\/root/usr/local/arm/3.4.1/arm-linux/bin\ -O -I../../include -I../../imports/x11/include/X11 ccimake.c if [ -n /root/usr/local/arm/3.4.1/arm-linux/bin ] ; then \ /root/usr/local/arm/3.4.1/arm-linux/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; \ else touch imakemdep_cpp.h; fi make[2]: Leaving directory `/root/TinyX/xc/config/imake' make[1]: Leaving directory `/root/TinyX/xc' cc: installation problem, cannot exec `cc1': No such file or directory make[2]: *** [imakemdep_cpp.h] Error 1 make[1]: *** [imake.proto] Error 2 make: *** [World] Error 2 ***end of error msg*** If anyone knows what wrong and how to get rid of those mess. Please tell me! Thx in advanced. And please explain me a little bit about the cc, cc1 and what the cross compiling scheme internally..thank you guys very very much Kai @ 10th, Jun, 2005 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: SOS....I was frustrated by cross-compiling a TinyX server
Hi.. This problem is encountered when u use a script file or spec file to cross compile X Your host is executing the ARM binary...and obviously fails.. To crosscompile - just do the following unpack X4.4.0 sources create host.def and copy to xc/config/cf/ modify cross.def in xc/config/cf to your toolchain path remove xfontsel in xc/programs/Imakefile and then go to xc directory and run $make World CROSSCOMPILEDIR= toolchain bin directory path XCURSORGEN=xcursorgen and subsequently $make install DESTDIR=bla bla bla IF and only if you intend to use spec or scripts.PLEASE READ how to set BOOTSTRAPCFLAGSmost of the stuff mentioned...dosent work.hope someone could tell me which BOOTSTRAPCFLAGS works for X 4.4.0 ARM Cross Compile. Vinod On 6/9/05, Kai.Niu [EMAIL PROTECTED] wrote: Hi ALL: I was so confusing about the cross compiling process about XFree86 package. I encountered such a weird error message like below. Dose anyone know what the cc1 dose imply? I guess cc1 means a symbolic link so gcc. I make a cc1 symbol link to either arm-linux-gcc and native x86 gcc. None of them bring me out of hell. I started compiling as make World CROSSCOMPILEDIR=blablablabla. My host.def file like below: host.def /* $XFree86: xc/config/cf/cross.def,v 1.3 2002/04/04 14:05:33 eich Exp $ */ /* * This file contains redefinitions of some symbols to enable * cross compilation: e.g. paths for include files and paths to * compiler images. It will have to be edited to reflect these * given your local configuration. */ #define KDriveXServer YES #define TinyXServerYES #define CrossCompiling YES #define TouchScreenYES #undef BuildRandR #define BuildRandR YES #define BuildXInputLib YES #define ProjectRoot/root/TinyX/xc #define Freetype2Dir $(TOP)/extras/freetype2 #define Freetype2LibDir$(TOP)/exports/lib #define BuildXTrueType YES #define BuildScreenSaverExtNO #define BuildScreenSaverLibraryNO #define SharedLibXss YES #define ServerXdmcpDefines #define XfbdevServer YES #define HasZlibNO #define HasPNGlib NO *end of host.def*** And I made the necessary modification on cross.def file to present my host cross-toolchain configuration. The error message like below: **error message dump* Building XFree86 version 4.4.0 (29 February 2004). I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Thu Jun 9 06:05:25 EDT 2005 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/root/TinyX/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap rm -f imakemdep_cpp.h make[1]: Leaving directory `/root/TinyX/xc/config/imake' make Makefile.boot make[1]: Entering directory `/root/TinyX/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/root/TinyX/xc/config/imake' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR=/root/usr/local/arm/3.4.1/arm-linux/bin in config/imake cc -o ccimake -DCROSSCOMPILEDIR=\/root/usr/local/arm/3.4.1/arm-linux/bin\ -O -I../../include -I../../imports/x11/include/X11 ccimake.c if [ -n /root/usr/local/arm/3.4.1/arm-linux/bin ] ; then \ /root/usr/local/arm/3.4.1/arm-linux/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; \ else touch imakemdep_cpp.h; fi make[2]: Leaving directory `/root/TinyX/xc/config/imake' make[1]: Leaving directory `/root/TinyX/xc' cc: installation problem, cannot exec `cc1': No such file or directory make[2]: *** [imakemdep_cpp.h] Error 1 make[1]: *** [imake.proto] Error 2 make: *** [World] Error 2 ***end of error msg*** If anyone knows what wrong and how to get rid of those mess. Please tell me! Thx in advanced. And please explain me a little bit about the cc, cc1 and what the cross compiling scheme internally..thank you guys very very much Kai @ 10th, Jun, 2005 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Dose anyone know the detail to cross-compile a TinyX server
Hi U dont need their patch... Just do normal $ make World CROSSCOMPILEDIR=.. with xcursorgen provided by ur host and it works Vinod On 6/8/05, Kai.Niu [EMAIL PROTECTED] wrote: Best regards to all: I am working on cross-compile a TinyX server to a arm-based development board. The cross-compile process failed every time, even I've tweaked the code a lot by myself. I believe some of you cross compiled TinyX package successfully, So could u please tell me the tricks to do that? Thx a lot in advance. By the way, the OZ technology released a patch for 4.40 packages, is that necessary for successfully cross-compiling a TinyX package? Sincerely Kai @ 8/Jun/2005 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Can I get the real address of XvImage-data ????
Dear fellows: Sorry to ask such a stupid problem... I want to get the real address of XvImage-data (not virtual-mm address) so that I can give that address to another hardware... Could I do that?? Joe ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bug in xmodmap?
My xmodmap (Apple 1.0) has the strange feature that Shift+Meta_R behaves the same as Shift+Insert. Here's my xmodmap, that's the best thing I can think of to send as documentation, but please let me know if you have any questions (or suggestions). ! .kinesis.bigpuppy an Xmodmap file geared towards math. ! Sat Sep 13 21:16:58 2003 ! I haven't taken the time to fix the function keys. keycode 8 = a A underscore !** ! Left !** keycode 9 = o O Left !** ! Down !** keycode 10 = e E Down !** ! Right !** keycode 11 = u U Right keycode 12 = d D minus !** ! End !** keycode 13 = i I asciicircum keycode 14 = semicolon colon bracketleft keycode 15 = q Q bracketright keycode 16 = j J braceleft keycode 17 = k K braceright keycode 19 = x X dollar keycode 20 = apostrophe quotedbl grave keycode 21 = comma less BackSpace !** ! Up !** keycode 22 = period greater Up keycode 23 = p P Delete keycode 24 = f F plus keycode 25 = y Y equal keycode 26 = 1 exclam keycode 27 = 2 at keycode 28 = 3 numbersign keycode 29 = 4 dollar keycode 30 = 6 asciicircum keycode 31 = 5 percent Sys_Req ! equal plus keycode 32 = sterling yen yen keycode 33 = 9 parenleft keycode 34 = 7 ampersand ! minus underscore keycode 35 = slash question asciitilde keycode 36 = 8 asterisk keycode 37 = 0 parenright ! bracketleft braceleft keycode 38 = Hyper_R keycode 39 = r R Delete keycode 40 = g G BackSpace keycode 41 = Super_R keycode 42 = c C Up keycode 43 = l L asciicircum !** ! Second space key !** ! Insert is used to _insert_ a pair of matching paretheses keycode 44 = Mode_switch Insert Insert keycode 45 = n N Right keycode 46 = h H Left keycode 47 = backslash bar keycode 48 = t T Down keycode 49 = s S underscore ! .ibook sets this to Meta_R, on the kinesis dev keyboard its slash keycode 50 = eacute keycode 51 = w W braceright keycode 52 = z Z parenright keycode 53 = b B currency keycode 54 = m M braceleft keycode 55 = v V parenleft ! Tab -- rebound to keycode 56 = egrave !** ! First (real) space key !** ! it is better to have space space, because one often types (shift space) keycode 57 = space space currency ! grave asciitilde keycode 58 = Hyper_L !** ! First (real) backspace key !** keycode 59 = BackSpace BackSpace section ! KP-Enter keycode 60 = Return ! Escape keycode 61 = Escape ! ! the upper two tiers of the toprow thumb keys need creative work. ! BUT: note that I am now of the opinion that using the upper and inner ! thumb keys is somewhat ANERGONOMIC. I am now working to ! minimize their use. ! ! ! thumb key labeled F ! Note: this key is allegedly used to get a button three event... keycode 63 = Tab ! Shift keysyms !!! keycode 64 = Shift_L NoSymbol NoSymbol NoSymbol !!! ! Caps Lock (impossible to turn it into a modifier) --! ! even when using a separate keyboard! How silly! ! ! Note, however, that with the Kinesis remapping feature there is ! ! an easy work-around, namely to (re)move the capslock key. ! ! now I have a new key in its place that is set to do Mode_switch. ! ! The following is therefore just a remenant of times gone by. ! !!! keycode 65 = Select Insert ! ! thumb key labeled K
Re: hi
I speak spanish and that seems to say something about your mother, big cow I hope I'm mistaken because that sounds rather rude. By the way, this is the 3rd foreign message I've received in the last week. I made a post about an automatic translation filter that checks the country domain; I'd really like to see it implemented. I've heard of babelfish. What would be the point? Almost all of the foreign language messages to this list are SPAM. In fact, this one would conflict with your recent request to limit profanity. The foreign language messages are OFF-TOPIC and don't belong at all. It would be alot of work to install such a filter, even if one did exist, just for one or two messages a year. When those very rare messages do occur, there are enough people on the list who speak other languages that can either respond or provide a translation if needed. If you see a non- English message on this list, you can safely assume it is SPAM, unless proven otherwise. BTW, this message does reference your mother, but according to it, the big cow is your wife (she's also a whore among other things). I won't go into what it tells you to do to yourself. From: luca bettati [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: hi Date: Fri, 05 Dec 2003 18:39:42 +0100 hai rotto il cazzo: tè, tua madre e quella gran vacca, zoccola, puttana e troia di tua moglie! vatti a farti fottere figlio di PUTTANA ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
I've discussed XINPUT before, tried to fix some things, and realized that the XFree86 XINPUT code needs a complete re-write. It is particularly messed up for non-pointer devices. Jim Gettys took over XFree86 XINPUT, and agreed that a re-write is needed. I put off working on XINPUT until he got started, because he knows much more about X than me. I've been busy doing other things, so I don't know what the recent progress is in updating XINPUT. First, most of the XINPUT protocol isn't too bad, although it is rather simplistic - designed before input devices were smart. Expanding it seems the best approach to me. Problems that would need some changes that are not completely backwards compatible are: 1) Device Controls must be expandable. This means types should be Atoms, not an int enumerator. Since Atoms and ints are the same size, and it is highly unlikely for an Atom to conflict with a single-digit enum, it would allow binary compatibility. 2) Also for device control expandability, control data structures need to be generic char/word/int data, as in XClient message. Since the structures are variable-length unions, this is still compatible with Xlib calls, but needs a server protocol update. 3) Some commands that have global scope should be handled separately for each device connection, such as XSetDeviceMode sending relative or absolute data. A few other comments: The current protocol is also not incompatible with device hot-plugging. We probably need to fit in well with HID. Even though HID is not so great, it is a widely used standard. Device controls should follow Config file semantics. Joe Krahn Rafa Rzepecki wrote: On Thursday 28 of August 2003 17:59, Egbert Eich wrote: Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. A generalized API for passing messages to and from the driver (to userspace and back) would be more than useful. It would serve as a way to implement device-specific features, requiring specialized client support without losing the generic features that all the apps could use. For example I could use this API in communicating battery and RF channel status of my cordless mouse to a client and sending RF channel switching requests. A client-driver communication is neccessary here, because a user would want to know the battery level at any given moment, and also be able to switch the channel whenever xe likes to. Few drivers do such things now, but using weird tricks (vide XLedFeedback in citron or shared memory in synaptics). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
Emmanuel writes:
So in short : where the trivial fixes (more or less like the janitor
ones) should be submitted (for now they are submitted via bugzilla)?
Thanks
Yes.
1. Please create yourself a bugzilla account and log in.
2. You can then use the 'create' function to create a new
submission.
3. Please try to identify as closely as possible the component
the submission is for, add a brief description and use the
'attachment' button to create an attachment containing your
diff.
4. Please don't forget to set the mimetype of the attachment
to 'patch'.
This is importand as it helps to locate those entries that
contain patches.
You can then always search for the entry and find out if
the fix has been submitted already or if somebody has a
comment on your submission.
Of course, there are such advantages to using bugzilla, but the above listed
steps are a lot more overhead for submission of trivial patches than
cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED]
For a very short patch like this:
diff -u -r1.13 xf86MiscExt.c
--- xf86MiscExt.c 3 Apr 2003 16:15:56 - 1.13
+++ xf86MiscExt.c 4 Jun 2003 18:44:04 -
@@ -618,7 +618,7 @@
{
ScrnInfoPtr pScr = xf86Screens[scrnIndex];
-DEBUG_P(MiscExtGetFilePaths);
+DEBUG_P(MiscExtPassMessage);
if (*pScr-HandleMessage == NULL)
return BadImplementation;
a simpler submission method seems more appropriate.
Anyone know anything more about the mythical email interface to bugzilla?
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
[EMAIL PROTECTED] writes: Of course, there are such advantages to using bugzilla, but the above listed steps are a lot more overhead for submission of trivial patches than cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED] For a very short patch like this: Certainly. But this is just too bad: we cannot make it right for everyone. People have been pressing us to provide a bugzilla. Of course sometimes another solution may be better. But now since we have it we should it should be used. Besides I have been advocating a somewhat simpler IF for bug submissions. However we need somebody with experience in tweaking the bugzilla frontend to do this. We already have one volunteed to help. Maybe there will be a lot less overhead in the future. Hopefully. I guess I'm just sharing your frustration. As you've been saying there were lots of advocates for bugzilla that indicated a willingness to help, but that hasn't happened (at least so far). Along with that, in that most recent round of bugzilla advocacy, one of the advertised benefits was email access, but it hasn't happened. I've used at least three other bug/trouble ticket tracking systems that had at least some functions available via email and they've been much nicer to work with because of it. Anyway, since Marc committed that small patch embedded in my last message, well under an hour after I sent it, it seems this list is a very efficient email interface to the XFree86 patch submission system ;^) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Input driver communication with calibration application?
Driver communication in the XINPUT protocol is very incomplete, and even less complete in XFree86. The only way to do it now within the XINPUT protocol is to mis-use an existing Feedback control. But, most feedback controls are not yet implemented in 4.x. THe only way I have found to work is to encapsulate data in XChangeDeviceControl messages. For example, if valuator 0 is zero, then valuator 1 contains data to append to an internal data buffer, which could be a plain text string ending in NUL. You could then parse that string for simple parameter/value] pairs. Joe Krahn Burt Bicksler wrote: Hi, I'm working with a touch screen driver in XFree86 4.0.x.. and I have need to communicate with the touch screen driver from an X application that is used for calibration. Specifically I want to be able to turn off existing calibration, and then give the driver updated configuration after the user is finished. What is the best way to perform this type of communication with an XInput driver from an X application? Thanks, Burt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SunRay driver for XFree86
On Fri, Jan 31, 2003 at 11:57:36AM +, Markus Kuhn wrote: Performance-wise the most interesting option is probabaly to drive it directly from an X server (as Sun does), That shouldn't be too difficult. Take the Xvfb sources and teach to send the screen contents to the SunRay in regular intervals. When that works you optimize the SunRay display update step by step. I'd suggest implementing things like xf4vnc does (see xf4vnc.sourceforge.net). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
