Re: C++ code in Xfree86?
Hi, 1)for cross compiling, does we need to modify cross.def and save as host.def? No, you have to make a new file host.def where you put in all the configuration define's 2)In Cross.def there is a line #define CplusplusCmd Is there any C++ code in Xfree86-4.2.0 source? we don't have C++ compiler for our target platform. never mind, you wudn't need ++ anywhere (at least my conf never needed) Also kindly provide some document/links on successful porting of Xfree86 to new Hardware platform. http://www.handhelds.org/minihowto/building-x.html -Jassi On Fri, 09 Jan 2004 Suresh Chandra Mannava wrote : Dear Friends, I struck up with cross compile of Xfree86, Here are some queries which I need your generous help. Thanks in Advance. Regards, Suresh. = --- Suresh Chandra Mannava. Research Scholar, V I T, India. mannavaatvit.ac.in Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: memory leak
Hi, So you think is the application, In this case the perl/tk library it's true that perl/tk ( due to is structure ) is comsuming always more memory but if I restart application the memory was normally released (xfree 3.3.6) now if I restart application memory is still busy. there is some tools to analize the xfree memory usage ? to know who is requesting resource and which resorce ? thanks Pierfrancesco Tateo On Tuesday 06 January 2004 04:26 pm, tateopfr wrote: Hi, Xfree86 4.3.0 i use more and more memory ... until 200MB and more my system : Slackware 9.1 - kernel 2.4.22 - 512MB RAM DUAL ATHLON 2200+ - THUNDER 2468 TYAN 2 HD SCSI VIDEO CARD : ATI RAGE XL WITH 8 MB RAM ( ONBOARD ) TOUCH SCREEN ELOTOUCH SERIAL Application developed in perl and perl/tk running 24/24 hour. with : top command I can see the X memory ( RSS ) became always great I download and install the last binary version from : xfree.org/~alanh/drivers/x86 but the problem still exists !! thanks Pierfrancesco Tateo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fbdev rotation problems
On Sat, 2004-01-10 at 23:25, David Dawes wrote:
The 24-bit flags argument to xf86SetDepthBpp() should probably
be:
Support24bppFb | Support32bppFb | SupportConvert32to24 | PreferConvert32to24
Since the actual framebuffer format is passed explicitly, this should
be safe in all cases. It will then default to using 32-bit bpp for
depth 24 pixmaps. It is possible that this change will fix the rotation
problem you are seeing at 24-bit.
It would be better to disable randr only when rotation is enabled.
Have you tried adding it to the else part of the following:
if (!fPtr-rotate)
FBDevDGAInit(pScrn, pScreen);
else {
xf86DrvMsg(scrnIndex, X_INFO, Rotated display, disabling DGA\n);
if (pScrn-bitsPerPixel == 24)
xf86DrvMsg(scrnIndex, X_WARNING, Rotation might be broken in 24 bpp
\n);
}
Applying the changes as you suggested, I have the attached diff. While
this allows correct rotation and (unrotated) 24 bpp, rotated 24 bpp is
still corrupt.
--Jonathan Thambidurai
412c412,413
if (!xf86SetDepthBpp(pScrn, default_depth, default_depth, fbbpp,0))
---
if (!xf86SetDepthBpp(pScrn, default_depth, default_depth, fbbpp,
Support24bppFb | Support32bppFb | SupportConvert32to24 | PreferConvert32to24))
795c796,797
---
xf86DrvMsg(scrnIndex, X_INFO, Enabling Driver rotation, disabling RandR\n);
xf86DisableRandR();
porting xfree86 to new processor platform
Dear Friends, We are porting Xfree86 to India's 32bit processor named Abacus(LITTLE ENDIAN). Already Linux is ported to this platform. here are my queries on porting xfree86 to this platform. We are going to cross-compile xfree86-4.2.0. GCC compiler toolchain is available. After reading the README and BUILD I found I should track the following files in config/cf. 1)Imake.tmpl 2)host.def 3)cross.def 4)linux.cf Should I need to modify any other files? I want to define new processor architecture for X, where should I add? (AbacusArchitecture) is it in Imake.tmpl? Please share your experiences, tips and information on porting Xfree86 to new processor architecture. Thanks in advance. Regards, Suresh = --- Suresh Chandra Mannava. Research Scholar, V I T, India. mannavaatvit.ac.in Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Are you lucky?
http://webajans.com/rab/jessica However i have something for you.. Jessica ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch writes: Hi! Am Samstag, 10.01.04 um 13:40 Uhr schrieb Warren Turkal: Mario Klebsch wrote: But without digging to deep into that question, does freedesktop only provide an alternative xlib or do they offer an alternative to XFree (providing a complete set of libraries (xlib, Xt, Xaw, ...) and the imake based build system? Freedesktop is intending to produce a full set of xlibs. All of the libs we have packaged are built with autotools. We have also broken many of the libs into their own packages so that pieces can be upgraded independently. We have added pkgconfig support to all libs so that autoconf can more easily detect libs and compile flags and link flags needed. I never understood why so many people consider these autotools easier to use than the imake system. Imake (or to be precise, the config files It is not. The reason why people advocate the change simply is that autotools are more widely used and therefore more people are aquainted with them. The vast majority of people know only either one or the other and therefore are not able to judge if such a step would be feasable and what consequences this may have. Unfortunately noone who has knowledge of both systems and advocates the change has ever provided a ... This however is needed to start a fruitful discussion on the issue. - Imake's strong area is the generation of Makefiles: Many Makefiles in X are boilerplate. For those Imake uses macro templates in its config file. The Imakefiles using these macros are very short, the programmer doesn't have to worry about the details of the build this is done once only: when the build macro was created. Adding new macros is simple. In most cases the build macros will already pick the right set of command line parameter definitions so the Imakefile writer doesn't have to worry about these. - autoconf's goal is to query all system/platform dependent parameters dynamically at build time. This makes porting to new platform quite easy: in most cases nothing needs to be changes because all necessary probes are already performed. Imake requires a static configuration for each architecture/ platform/version. It only probes a few system dependent parameters to be able to pick the correct configuration. Porting to a new version/ architecture/platform involves adding a new or extending an existing configuration. - autoconf does not simplify Makefile writing: The required Makefile.in has the same content as the resulting Makefile with system dependent parameters replaced by tags which will be substituted by configure. This is where automake steps in: automake knows how to make build rules for the build targets described in the Makefile.am. It knows about a large number of standard build targets, the generated rule can be controlled by additional arguments as for example extra command line options. These options need to be specified in every Makefile.ac that requires them. Extending automake with new build targets/ build rules doesn't seem to be as easy as it is with Imake. - The number or supported vendors/platforms/systems/architectures have turned the Imake rules and template files in to a giant mess which only a small number of people are still able to handle. Either these files have become more complicated than required (in which case they could be simplified) or I expect that porting over this mess to autotools while keeping intakt every specialty required will be close to impossible. I'd therefore expect that using autotools will always mean a tradeoff when dealing with very special build targets. Recently the suggestion has been made to replace the static configuration files with a dynamic configuration created by autoconf/configure. In fact this idea is not new: I rememer RMS proposing this idea four years ago already. This in fact may perserve the benefits of Imake while it would reduce the system dependent configuration mess and make porting easier. It may also be possible to integrage libtool which would then allow to do away with the system dependent rules and template files for shared libraries building. In principle Imake should also support buidling of individual parts of the X sourcetree provided the config template and rules files as well as the header files are installed somewhere on the system. Unfortunately this did not always work when I checked last. included with X11) knows everything about the local X11 installation, where configure has to guess and far too often guesses wrong. I really do see no benefit in not using the imake system and I must admit that I do not understand why configure does not use an Imakefile to find out all the details needed to compile X11 programs on a given platform. When I did not know the details of how the automatically generated configures work, I often spend hours on getting this
Re: fbdev rotation problems
On Sun, Jan 11, 2004 at 07:26:04AM -0500, Jonathan Thambidurai wrote:
On Sat, 2004-01-10 at 23:25, David Dawes wrote:
The 24-bit flags argument to xf86SetDepthBpp() should probably
be:
Support24bppFb | Support32bppFb | SupportConvert32to24 | PreferConvert32to24
Since the actual framebuffer format is passed explicitly, this should
be safe in all cases. It will then default to using 32-bit bpp for
depth 24 pixmaps. It is possible that this change will fix the rotation
problem you are seeing at 24-bit.
It would be better to disable randr only when rotation is enabled.
Have you tried adding it to the else part of the following:
if (!fPtr-rotate)
FBDevDGAInit(pScrn, pScreen);
else {
xf86DrvMsg(scrnIndex, X_INFO, Rotated display, disabling DGA\n);
if (pScrn-bitsPerPixel == 24)
xf86DrvMsg(scrnIndex, X_WARNING, Rotation might be broken in 24 bpp
\n);
}
Applying the changes as you suggested, I have the attached diff. While
this allows correct rotation and (unrotated) 24 bpp, rotated 24 bpp is
still corrupt.
OK, I guess the generic shadow code doesn't support the packed 24bpp format?
I'll apply your patch -- thanks.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: porting xfree86 to new processor platform
Suresh Chandra Mannava wrote: *snip* here are my queries on porting xfree86 to this platform. We are going to cross-compile xfree86-4.2.0. Why not 4.3 or the release candidate? *snip* wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
reference file for driver specs
hi, id like to ask if theres a file somewhere which contains the list of supported videocard with the corresponding modules, device options etc. I assume that during configuration of video card, linux looks at a reference file containing details of video cards and uses it to configure XF86Config. Id like to ask for the filename of this file (assuming my guess is correct). Thanks for the help -- Joseph Syjuco [EMAIL PROTECTED] Advanced Science and Technology Institute ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: porting xfree86 to new processor platform
here are my queries on porting xfree86 to this platform. We are going to cross-compile xfree86-4.2.0. Why not 4.3 or the release candidate? C Compiler: Based on GCC 2.95.3 Assembler: Based on GNU binutils 2.10.1 Linker: Based on GNU binutils 2.10.1 Disassembler: Based on GNU binutils 2.10.1 Archiver: Based on GNU binutils 2.10.1 Standard C library: GLIBC 2.2.5 Client requested us specifically port Xfree86-4.2.0, If above toolchain supports Xfree86-4.3.0, I will be happy to port that because, I read Xfree86 cross-compile system has been changed after the release of 4.2.0. - Suresh Chandra Mannava = --- Suresh Chandra Mannava. Research Scholar, V I T, India. mannavaatvit.ac.in Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
