[Xpert]startup screen garble
this isn't a big issue or anything, just cosmetics. i'll be using my computer for a presentation of Linux to my class and want it to look as good as possible. when i start X, the first screen i see is a bunch of garble and, if X was started before, a screen of the last seen desktop. is it possible to blank the screen as X is starting? i've looked around but have come up empty handed. jesse blah blah bluh send mail to [EMAIL PROTECTED] pleaze, no mayonaisse. yes, http://fastmail.fm i am at. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]startup screen garble
On Thu, 9 May 2002, 'kolourful odour' wrote: this isn't a big issue or anything, just cosmetics. i'll be using my computer for a presentation of Linux to my class and want it to look as good as possible. when i start X, the first screen i see is a bunch of garble and, if X was started before, a screen of the last seen desktop. is it possible to blank the screen as X is starting? i've looked around but have come up empty handed. jesse The driver should be doing that already. If it's not blanking that is a driver bug. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]4.2.0: undefined reference to atexit() (?!?!?)
|Please refer these messages: | | http://sources.redhat.com/ml/libc-alpha/2001-03/msg00139.html | http://sources.redhat.com/ml/libc-alpha/2001-03/msg00140.html | | This is not a bug of XFree86, perhaps you should upgrade gcc. Hmm I have upgraded gcc -- perhaps incorrectly -- to 3.0.4 and still receive these errors (more so now than before). Does anyone have a small piece of source code that will generate this undefined reference to atexit? thanks. kw. |-- |ISHIKAWA Mutsumi | [EMAIL PROTECTED], [EMAIL PROTECTED], |[EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Re: Voodoo 3 and 4.2.0
On Thu, 9 May 2002, Michael wrote: High resolution video requires a lot of video memory. DRI requires approximately four TIMES that much video memory to work properly. However, people are using insane high resolutions like 1600x1200 and using DRI, then running Wolfenstein 3D, and it crashes. Hmm, gee... I wonder why. Perhaps because the voodoo3 will happily run at these resolutions? Doesn't sound insane to me. Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. I am interested in hearing the opinions of DRI and XFree86 project members on the this particular issue with the tdfx driver. I have a feeling however that the DRI developers favor stability, reliability, and security over driver features, supported resolutions and the like. If someone wants to modify a driver and use it in a known unstable manner, and they're lucky enough to not trigger problem behaviour, or to trigger it infrequently enough that it doesn't bother them, that is their perogative. But it is not acceptable IMHO to knowingly ship a driver which crashes, and for which the reason for the crash can be easily fixed or worked around by detecting problem configurations and disabling features known to be unstable. If someone wants to see this problem fixed in a better way than just being worked around by disabling the known problematic configuration, then it is a good project for someone to work on as a personal itch to scratch, and to ensure that the tdfx drivers continue to function and to access as many features of the hardware as possible. Unmaintained drivers eventually become non-working drivers, and eventually become completely disabled drivers. As hardware becomes older, and nobody is funding development of the code, there is less and less incentive to fix bugs in the code, when there are fixed amount of human resources available, and newer drivers for more modern hardware have their own fare share of bugs needing fixing. It makes the most sense to spend resources first on the modern hardware, and much lower priority on the older hardware. It is in these situations when the open source development community needs to step in and scratch their personal itch by hacking on code and contributing it. Not unlike the Linux kernel's own developmental processes. Fortunately, due to the good work that the DRI guys, and others have done in the past on the tdfx drivers, they are in fairly good shape now. This one problem is the only major problem that pops up now that I can think of on Voodoo 3/Banshee hardware. If someone is interested in solving this for real, let me know, and I will put the Voodoo 3 specs up and provide a URL to them. Also, it would be a good idea to join the #dri-devel meetings on irc.openprojects.net on Mondays at 4pm EST to discuss how one might go about finding/fixing the problem. I'm sure that Daryll Strauss, and others who have worked on this code before, will be glad to help out anyone interested by providing pointers. But until such bugs are truely fixed, stability trumps whiz-bang. -- 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 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Question regarding bit depth and Arc/Info
--- Mark Vojkovich [EMAIL PROTECTED] wrote: On Wed, 8 May 2002, Eric Jorgensen wrote: What about getting it to work in 24 bits? Is there a way to get the behavior from version 3.3.6 in current versions? I'm suspicious about that. HP never supported 24bpp XImages. If anything, I would expect it to work now, and not before. I think the advertising of 24bpp formats in XFree86 3.3.6 was a huge mistake. What problems do you get trying to run it in depth 24? When I try to run it in 24 bit mode, the colors are all wrong, that is, within Arc/Info raster image colors are distorted. Colors otherwise are normal. I took the video card out of the old working machine and put it in the new non-working machine. I've attached the XFree86 log files from when the X server starts up. If someone could please look at these and tell me what I need to set in the new -4 config file to emulate the behavior of the previous version in 24 bit mode, I would be incredibly appreciative. If not, word on why Xfree86 version 4 won't do what version 3 did would suffice. Thanks! Eric __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com XFree86.0.log.new Description: XFree86.0.log.new X.orig.log Description: X.orig.log
[Xpert]Geode questions...
Hello! I am having problems with a National Semi Geode based system and would need some help / advice in regards to display issues: I am trying to convert a Geode based embedded web browsing device to Linux. There are two points of funkyness: 1. The CRT display will only allow 1024x768 @ 72Hz to be displayed (meaning I can't see anything unless I have X running at that res/freq) and 2. the display is rotated by 90 degrees CCW. The dilemma is that I can configure X 3.3.6 using the SVGA server and I actually see something but I can't rotate the screen. If I use X 4.x.x I could rotate the screen but somehow none of the drivers work for the Geode. I have gone through the archives and found several postings in regards to the Geode but none offered a solution for my particular setup. I guess there are several possibilities that would help me move forward: - Somebody has modified the X 4.x.x Cyrix MediaGX driver to work with the Geode and is willing to share that driver ;-)... that would be way optimal... - Somebody has modified the X 3.3.6 SVGA driver to rotate the display and is willing to share that driver ;-)... that would also be way optimal... - Somebody could give me some pointers on how to modify the X 3.3.6 SVGA driver to rotate the display and I'd give it a shot even though I have never played around with the guts of X ;-) - Somebody could give me some pointers on how to modify the X 4.x.x Cyrix driver to support the Geode and I'd give it a shot even though I still have never played around with the guts of X ;-) Thanks a lot in advance for any type of feedback... and sorry for the lengthy message! Later, Patrick ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Question regarding bit depth and Arc/Info
On Thu, 9 May 2002, Eric Jorgensen wrote: --- Mark Vojkovich [EMAIL PROTECTED] wrote: On Wed, 8 May 2002, Eric Jorgensen wrote: What about getting it to work in 24 bits? Is there a way to get the behavior from version 3.3.6 in current versions? I'm suspicious about that. HP never supported 24bpp XImages. If anything, I would expect it to work now, and not before. I think the advertising of 24bpp formats in XFree86 3.3.6 was a huge mistake. What problems do you get trying to run it in depth 24? When I try to run it in 24 bit mode, the colors are all wrong, that is, within Arc/Info raster image colors are distorted. Colors otherwise are normal. I took the video card out of the old working machine and put it in the new non-working machine. I've attached the XFree86 log files from when the X server starts up. If someone could please look at these and tell me what I need to set in the new -4 config file to emulate the behavior of the previous version in 24 bit mode, I would be incredibly appreciative. If not, word on why Xfree86 version 4 won't do what version 3 did would suffice. I believe no other X-server in the world offered packed 24bpp XImages. Even in XFree86 3, they were only supported on hardware that supported packed 24bpp framebuffers. Many did not, including NVIDIA hardware. Drivers for NVIDIA hardware would not have offered packed 24bpp XImages in XFree86 3. An app that expected 24bpp XImage in depth 24 would not have worked in any X-server except for XFree86 3, and even then, only on some hardware. Such an app would be broken by definition for making such an assuption. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: Re: Voodoo 3 and 4.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 #if Mike A. Harris On Thu, 9 May 2002, Michael wrote: High resolution video requires a lot of video memory. DRI requires approximately four TIMES that much video memory to work properly. However, people are using insane high resolutions like 1600x1200 and using DRI, then running Wolfenstein 3D, and it crashes. Hmm, gee... I wonder why. Perhaps because the voodoo3 will happily run at these resolutions? Doesn't sound insane to me. But until such bugs are truely fixed, stability trumps whiz-bang. Absolutely fine with me, as an owner of a Voodoo3. Rik - -- http://rikkus.info -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE82uZf6rehpl6X9l0RAloTAJ9UCzBbb4vVeYnb9Z5w41rs3dE8awCcCHO4 xzDkEweAoUTbT65PIdWjlqg= =OuWy -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]4.2.0: undefined reference to atexit() (?!?!?)
OK, it finally worked. Here's what happened: -- I had a gcc 2.95.3 install that was done using plain vanilla, unpatched source straight from ftp.gnu.org -- I had built glibc 2.2.5 using this plain vanilla gcc 2.95.3 install -- This led to all the undefined crap Solution: -- obtain vanilla gcc 2.95.3 source from GNU site -- obtain gcc patch from LFS (ftp.linuxfromscratch.org) and apply -- rebuild/reinstall gcc -- rebuild/reinstall glibc -- build X 4.2.0 and everyone is happy. Thanks to all those who provided useful feedback! One last question: is this gcc problem fixed in gcc 3.0.x? I'd assume it is but to test this assumption would require a rebuild of gcc and glibc again. :) Regards, kw. |-Original Message- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf |Of Keith Warno |Sent: 09 May 2002, Thursday 15:12 |To: [EMAIL PROTECTED] |Subject: RE: [Xpert]4.2.0: undefined reference to atexit() (?!?!?) | | ||Please refer these messages: || || http://sources.redhat.com/ml/libc-alpha/2001-03/msg00139.html || http://sources.redhat.com/ml/libc-alpha/2001-03/msg00140.html || || This is not a bug of XFree86, perhaps you should upgrade gcc. | |Hmm I have upgraded gcc -- perhaps incorrectly -- to 3.0.4 and |still receive |these errors (more so now than before). | |Does anyone have a small piece of source code that will generate this |undefined reference to atexit? | |thanks. |kw. | ||-- ||ISHIKAWA Mutsumi || [EMAIL PROTECTED], [EMAIL PROTECTED], ||[EMAIL PROTECTED] | |___ |Xpert mailing list |[EMAIL PROTECTED] |http://XFree86.Org/mailman/listinfo/xpert | ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xwindows hangs at shutdown
I have a Dell Latitude C610 laptop running an ATI Radeon Mobility graphics card (which I know is unsupported at this time but supposed to run fine under VesaFB) with a 1.2 GHz Pentium 4. I'm using the Pentium optimized 2.4.10 kernel with SuSE 7.3, KDE2 and xfree86 4.1.0. It boots up just fine and goes into kde with no problems. When I go to log out of kde it acts up. Sometimes it will log out just fine and some times it completely freezes up right after I hit OK at the confirmation box. When it does log out fine it brings me back to the login screen and if I try to shutdown it will hang there instead. However if I click reboot instead of shutdown it works fine. I have also tried using ctrl-alt-F4, logging in as root and shutting down the system from there. Sometimes it just freezes after I type in shutdown -h now, and sometimes it will freeze at The system will be halted immediately. However if I type in reboot it will work fine. This is from a fresh install. I have not altered anything beyond setting the resolution to 1024x768x16, using VesaFB. This seems to be only when using X. If I start up and just use the old black command line interface than it will shutdown just fine. Is this just a simple case of an unsupported graphics card or is there something I might be missing? I'm fairly new to Linux so I don't know if there is a log anywhere that I can look at to see what it's doing. Also, a totally unrelated issue, maybe... The touch pad only works under Linux if the mouse is plugged in, but it works fine under Windows with or without the mouse. Ideas? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: Re: Voodoo 3 and 4.2.0
On Thursday 09 May 2002 10:12 pm, Mike A. Harris wrote: Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. Not as obsolete as you think. Untill a few months ago I ran a voodoo3 3000 for playing quake which is bearable @ 920*7something. Still it would make no sense to run it @1600*1200 (no question) so you're using OR dri, OR desktop@1600*1200. Conclusion: no problem at all. Frank -- homepage: www.student.kuleuven.ac.be/~m9917684 jabber (=IM): [EMAIL PROTECTED] No part of this copyright message may be reproduced, read or seen, dead or alive or by any means, including but not limited to telepathy without the benevolence of the author. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]3Dfx Voodoo 3, Banshee, Voodoo 1/2, and Voodoo Rush technicalspecifications
Anyone who might be interested on enhancing the XFree86 tdfx video driver, for 2D or 3D, or other functionality, will likely require the technical specs for the cards. The specs for all of these cards can be found in PDF format at the URL below. http://www.medex.hu/~danthe/tdfx/ Hopefully this information will be useful for some would be X hackers out there who have the hardware and would like to enhance support and/or fix bugs. I thought by providing links to the docs, it might help one get further along. Hope someone finds them useful. -- 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 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Re: Re: Voodoo 3 and 4.2.0
On Thu, 9 May 2002, Frank Van Damme wrote: Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. Not as obsolete as you think. Untill a few months ago I ran a voodoo3 3000 That depends on your definition of obsolete. Obsolete does not mean non-existant, nor not-in-use-anymore. Obsolete, means that the company that manufactures the product no longer supports it. In the case of the Voodoo hardware, it means that the company that used to manufacture the hardware does not exist anymore. Since they do not exist, there is no interest in anyone funding the development of this technology. As such, it is considered obsolete. That doesn't mean that you should throw away the hardware, nor that someone who has a personal interest in hacking on the drivers should not do so. I encourage anyone who is interested in hacking on the tdfx drivers to add support or fix bugs to go ahead and do so, and if I can help out in some way, I'll certainly try to answer any questions I can if I'm familiar with the particular area of inquiry. I'm sure any other developers would also be willing to help someone interested in hacking on X. Just keep in mind that while this is all perfectly good working hardware, that it is ultimately several generations old now compared to modern hardware, and that it is considered obsolete. for playing quake which is bearable @ 920*7something. Still it would make no sense to run it @1600*1200 (no question) so you're using OR dri, OR desktop@1600*1200. Conclusion: no problem at all. I agree with that. But some people out there do want to use 1600x1200 on such hardware that is 3 or more generations old. If the drivers were reprogrammed to actually work under those constraints, I believe the 3D would be so slow that software GL would not be much slower. Nonetheless, people want to do it if they can. As a general guideline of what is realistically possible with such hardware, one might try Windows, and see what 3D video modes are available on these cards in Windows while running a 3D game. Whatever windows can do with the 3Dfx drivers, it is theoretically possible that X can do also. However in addition to the problems in the current driver, there is an additional problem that XFree86 can't reclaim video memory used by 2D. Unless this has changed and slipped by me recently. I think if someone were to fix the drivers, that 1280x1024 might be possible, but I doubt much beyond that could run stable in 3D. -- 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 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]L10n or I18n Txt Funs
On Sat, 4 May 2002, Chuck Slivkoff wrote: Bharathi S wrote: Mapping Multi KeyStrocks to Single Glyph. If i press 'B' followed by 'A' then C shuld apper on the screen. 1. It is possiple to do with XModMap or @Xlib 2. I saw some doc(CH13) in X source code, in that i am reading about l10n and i18n Text functions... ( Preediting Concepts ). Whether this functions implemented in NewX or still in design stage. If the functions are avilable How to use it ? I believe what you are looking for is information on implimenting an Input Method Server. The i18n code that Sun contributed includes an SDK. IMS in available in present X. How to use it ? Whether we have develope useing the new lib functions OR it is possible to make the present aplications to use this lib ? TIA, Bharathi S -- --==| Bharathi S | BSB-364 DONLab | IIT-Madras |==-- Even demand become a joy When the thing comes without annoy. *In Tirukkural of Holy Tamil poet Tiruvalluvar. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
