[Xpert]X Server on W2K.
On Thursday 06 December 2001 11:09, Attila Szomor wrote: Hi All, We would like to use Kylix on SuSE Linux, but our programmers have W2KP computers. Can you recommend any X Server Software on Windows which can cooperate with XFree on Linux. vncclient and vncserver are pretty cool ;) Yes they are. You might want to use a local X server though, even so. Hummingbird's eXceed wasn't bad a few years ago, but I note now that XFree86 itself builds and runs under CygWin32 now, even the server (clients and libs have done so for years). See: http://sources.redhat.com/cygwin I need to frob Windowmaker in a few more places, but otherwise I can simulate my laptop pretty well :) Cheers, AS Hi All, Thanks yours answers !!! I tried VNC and XOnNet on yesterday, they working well with standard X-Applications, but unfortunatly do not work with Kylix. I will try the CygWin on today. Best Regards, Attila. From Error Message seem to incompatible value used by Kylix or Wine. on XOnNet-XTerm kylix@suse:~ Generating font matrix. Please wait... X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 45 (X_OpenFont) Value in failed request: 0x3400061 Serial number of failed request: 313 Current serial number in output stream: 314 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Capturing video from X
hello Miles, I checked the xfree site http://XFree86.Org/4.1.0/manindex1.html and some others I found on google.com but none of them mentioned xmon and xrecord, I could not find it on red hat.com either. i found doclib.org - /Linux/XFree86-Current/source/X333src-1 ... xc/lib/Xtst/Xtstos2.def /Linux/XFree86-Current/source/X333src-1/xc/lib/Xtst/XRecord.c /Linux/XFree86-Current/source/X333src-1/xc/lib/Xtst/XTest.c /Linux/XFree86 ... http://www.doclib.org/Linux/XFree86-Current/source/X333src-1/ but that was not what i thought i was in the end If you know of a URL to find these programs or a newer solution I would like to see it please. Regards JG Miles O'Neal wrote: It's been a long time, so I don't know whether they are still around (they don't seem to come with Red Hat, anyway) but there used to eb a couple of programs called xmon and xrecord. You might see if they have been upgraded to a current release... -Miles Hypermedia Research Centre Sanyo RD Headquarters, Tokyo http://www.sanyo.co.jp/R_and_D/3dm/ Tel: +81 (0)3 5803 3566 Fax: +81 (0)3 5803 3640 E-post: [EMAIL PROTECTED] Please use open standard file formats for attachments ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]to dri or not to dri
I've been told that not enabling dri allows you to use more mem for 2d, speeding it up if you're using all your mem. But what about E's use of canvas in E17. It uses OpenGL to hardware accel certain things. Would this still be hardware accelled without dri? on a 32MB card does 2d memory really become an issue at any time? does DRI do any speed accel to 2d at all outside of OpenGL? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Capturing video from X
Hello, I have just checked and it seems this is not the right tool to make a video from X. Could you recomend a prgram that can generate a video output from X ? even in vector format as long as I can play it back. JG Dr Andrew C Aitchison wrote: On Fri, 7 Dec 2001, J Grant wrote: hello Miles, I checked the xfree site http://XFree86.Org/4.1.0/manindex1.html and some others I found on google.com but none of them mentioned xmon and xrecord, I could not find it on red hat.com either. If you know of a URL to find these programs or a newer solution I would like to see it please. http://www.x.org/contrib/devel_tools/xmon.1.5.6.tar.gz seems to be the xmon you are looking for. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna -- Hypermedia Research Centre Sanyo RD Headquarters, Tokyo http://www.sanyo.co.jp/R_and_D/3dm/ Tel: +81 (0)3 5803 3566 Fax: +81 (0)3 5803 3640 E-post: [EMAIL PROTECTED] Please use open standard file formats for attachments ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]info need abt Upper/Lower layers in VGA cards
Hi, I want to know abt some deatils of VGA cards like Upper/Lower layers, I am new to this graphics area *is it commen in all VGA cards or this type of layers are available only specific cards. *where can I find this type of information???, point me some web links... * Is it possible to program to use Upper (or) Lower layers aloen. -Bala- __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Help with CyberBladeXPAi1 (Trident) on a Toshiba 1800-814 laptop
Olivier Fourdan writes: Egbert If trident works it is better as it is accelerated. Vesa uses the BIOS and allows mode switching - but it is unacceled. It may still have quirks. fbdev is so simple it should always work - but unaccelerated. I think I may have found something interesting (thus I copy the list ;-) 1) Using Vesa driver works. 2) Passing vga=790 or vga=791 or even vga=792 at linux kernel and using Trident driver *works* but it's very slooow, a lot slower that Vesa driver, in 24bpp and 16bpp -I didn't try 8bpp- Yes, there is no acceleration. We don't get the docs from trident to implement it. Accel in the XP chipset has just changed enough that the accel support for the earlier chips dosn't work any more. 3) Never use vga=xxx and Vesa XFree driver all together. It seems to be dangerous for the LCD display (use either normal textmode with XFree Vesa driver or fb text mode with XFree trident driver, but *not* fb text mode and Vesa driver !) This is surprising! What's puzzling me is why the trident driver with vga=xxx is so slow. I include my XF86Config file so you can check and see by yourself (note that I define all 3 devices, vesa, trident and fbdev and select the one I want by uncommenting the right line in the screen section) For some reason the driver didn't attempt to register mtrr ranges. I'm investigating. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS630 and LCD
Stuart Young writes: At 07:01 PM 6/12/01 +0100, Egbert Eich wrote: I've looked at it - you only offer binary drivers. However I think I know what you do. Your patch is pretty similar to the VESAFbHack patch posted a while ago. The VesaFBHack patch, which was my little effort at re-implementing the patch posted to this list by Kirill Konyagin (back in July 2001), may have been based on the same work as Rene, or Rene's work was based upon it. I simply put it into a form that allowed the user to easily enable/disable it. It also meant that if it was fixed, a config file change was not really necessary (something I was looking at, as I was investigating rolling these out into a production environment, and the less changes in the future, the better). Right. Your patch was OK. I'm thinking about adding it for 4.2. I doubt that I will be able to implement the BIOS initialization stuff. For the SiS to fully work with int10 I may have to modify some stuff in there code. I won't do that before 4.2 comes out. I'm thinking of something different: sis_bios.c is converted BIOS code anyway. Since we have the int10 infrastructure we can use it to run the real BIOS and eliminate much of the code in sis_bios.c. You might find that a lot of the code in the XFree driver is now the same as that in the Linux Kernel FrameBuffer for the SiS630 chip, so some common development here could be a definite advantage. I suggested this a long time ago. The problem was that kernel code was under GPL while ours was under an MIT style license. Something I have noticed as a difference between the VesaFB and SiSFB drivers in the Linux kernel, is that the VesaFB driver does it's init as absolutely early as it can, as the routines to change resolution have to be performed (afaik) in real mode, not in protected or virtual modes. AFAIK there is a way now to change VESA video modes on the fly. I tryed to get docu from sis - even considering signing a NDA - but suddenly the email thread with them stopped ... ? - They so not seem to be interested in getting the chip to work properly under Linux ... :-( I would certainly love to have better docs for the graphics part of the 630 than there are in the 630 datasheet. I got very little response from SiS, to very similar or the same queries (re: docs, NDA, sample code, etc). The company I work for wants to use a machine made by Clevo (a Taiwanese company) as a Point of Sale terminal (it's a desktop with an LCD screen, and very small footprint), but with the current problems we have with the SiS630 chipset (if not resolved soon), we will simply have to turn down the product as another good idea, bad implementation. Pity really, as the cost was reasonable, and the options on the product were ideal for our market. The problems can be resolved very quickly by using the video BIOS. The problem is we are past feature freeze for the 4.2 and I don't want to make modification to int10 code at this late stage. Int10 is quite touchy. If I get something wrong I'll have to take the blame. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Corrected: Odd problem with Xfree 4.1.0 and Trident TGUI 9680
Mac Cody writes: Egbert Eich wrote: This looks like a problem with some 2D Accel functions. Try to disable accel altogether by setting Option NoAccel in the device section and see if it goes away. Egbert. That was one of the first things I tried last night, but it didn't have an affect. I uncommented the entry in my XF86Config file so it read: Option NoAccel I didn't state either true or false since the XF86Config man page indicated that the above was equivalent to Option NoAccel false. No, that's OK. Any other suggestions? If the problem also appears with noaccel then everything drawn to the screen including the original root window pattern should show this 'enlargement' behavior. Is this correct? Right off hand I have no idea what the problem may be. Alan, do you have any idea? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]to dri or not to dri
On Fri, 2001-12-07 at 09:46, safemode wrote: I've been told that not enabling dri allows you to use more mem for 2d, That's true for the current static buffer allocation scheme. AFAIK it is planned to make it dynamic eventually, no idea about when though. speeding it up if you're using all your mem. But what about E's use of canvas in E17. It uses OpenGL to hardware accel certain things. Would this still be hardware accelled without dri? Hardly. It can use X11 primitives but that looks rather ugly in the demos I've seen. on a 32MB card does 2d memory really become an issue at any time? The log should contain detailed information about how much memory is reserved for what. In particular, a diff between logs with and without DRI is rather interesting. does DRI do any speed accel to 2d at all outside of OpenGL? Basically, 2D acceleration should be about the same with or without DRI. It looks like it's exactly the same for the mga driver. The r128 and radeon drivers have slightly worse 2D acceleration with DRI enabled, I might change that unless someone beats me to it. Don't know about other drivers. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS630 and LCD
Braunstein Alfredo writes: Did you have the same setup on the old version? How much video memory do you have? Could you please send the entire log file? If you have a log file from the old version (were 3D worked) could you please send this one, too? Regards, Egbert. Hi there. Here I attach full logs of 2 running sessions. 'log.cvs' and 'log.vesafbhack'. The setup is exactly the same for the two of them except for sis_drv.o and booting with or without the vesa fb, respectively. First case is sis_drv.o from latest CVS. The other one is that one using the VESA fb hack. I'm using Xfree CVS from 3-4 weeks ago. Note that I've only updated Egbert changes on the sis/ directory and nothing else; I am on a slow link at home. If you consider that it's definitely worth trying, I am willing to do a full CVS update. On the first case, (vesa framebufer), 3D accel seems to work. I say seems because Mesa demos work. I think Hw accel is being used because the gears in 'gears' have some glitches, like bad poligon superpositions, which I would find strange in a software-only renderer, But I may be wrong. How can I check for sure that Hw acceleration is being used? On the other case I get a 'not enough video mem' error, like I've said in a previous mail, when I run any Mesa demo. I've tried changing the video memory to 8Mb, 16Mb and 32Mb with no success. I'm currently using 8Mb for both tests (as you can see from the logs). Other differences: On the first case I get a strange xterm cursor, like: # # # # # # # # instead of a rectangle. On the second case it is gone (ok). Also I've observed a corrupted first line of the screen, but after a full reinstall It seems to have gone for both cases. This is the (I think) relevant differences between both logs: 16c16 (==) Log file: /var/log/XFree86.0.log, Time: Fri Dec 7 13:31:58 2001 --- (==) Log file: /var/log/XFree86.0.log, Time: Fri Dec 7 13:34:48 2001 82c82 compiled for 4.1.0, module version = 0.6.0 --- compiled for 4.1.99.1, module version = 0.6.0 208a212 (II) SIS(0): Mode # 0x4a 211,212c215,216 (II) SIS(0): [drm] added 4096 byte SAREA at 0xd08c8000 (II) SIS(0): [drm] mapped SAREA 0xd08c8000 to 0x40028000 --- (II) SIS(0): [drm] added 8192 byte SAREA at 0xd00c7000 (II) SIS(0): [drm] mapped SAREA 0xd00c7000 to 0x40028000 247,248d250 cursor_addr value: 0 cursor_addr value: 23 250c252 (II) SIS(0): [drm] unmapping 4096 bytes of SAREA 0xd08c8000 at 0x40028000 --- (II) SIS(0): [drm] unmapping 8192 bytes of SAREA 0xd00c7000 at 0x40028000 I hope that this reports can help you! If you need me to do any other test, just tell me. log.lastcvs.gz Description: Binary data log.vesafbhack.gz Description: Binary data
Re: [Xpert]Corrected: Odd problem with Xfree 4.1.0 and Trident TGUI 9680
Egbert Eich wrote: Mac Cody writes: Egbert Eich wrote: This looks like a problem with some 2D Accel functions. Try to disable accel altogether by setting Option NoAccel in the device section and see if it goes away. Egbert. That was one of the first things I tried last night, but it didn't have an affect. I uncommented the entry in my XF86Config file so it read: Option NoAccel I didn't state either true or false since the XF86Config man page indicated that the above was equivalent to Option NoAccel false. ---This should actually be true--^ No, that's OK. Any other suggestions? If the problem also appears with noaccel then everything drawn to the screen including the original root window pattern should show this 'enlargement' behavior. Is this correct? The original root window pattern and the mouse look correct. That is the odd thing about this problem. Right off hand I have no idea what the problem may be. Alan, do you have any idea? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Mac ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Corrected: Odd problem with Xfree 4.1.0 and Trident TGUI 9680
Alan Hourihane wrote: On Fri, Dec 07, 2001 at 12:05:00PM +0100, Egbert Eich wrote: Mac Cody writes: Egbert Eich wrote: This looks like a problem with some 2D Accel functions. Try to disable accel altogether by setting Option NoAccel in the device section and see if it goes away. Egbert. That was one of the first things I tried last night, but it didn't have an affect. I uncommented the entry in my XF86Config file so it read: Option NoAccel I didn't state either true or false since the XF86Config man page indicated that the above was equivalent to Option NoAccel false. No, that's OK. Any other suggestions? If the problem also appears with noaccel then everything drawn to the screen including the original root window pattern should show this 'enlargement' behavior. Is this correct? Right off hand I have no idea what the problem may be. Alan, do you have any idea? None. A screenshot would be useful. I'll work on that and send it out later today. Thinking about that, though, what utility should I use to obtain it? Should I use xwd or something else? Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert thanks, Mac ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Corrected: Odd problem with Xfree 4.1.0 and Trident TGUI 9680
On Fri, Dec 07, 2001 at 10:03:12AM -0600, Mac Cody wrote: I'll work on that and send it out later today. Thinking about that, though, what utility should I use to obtain it? Should I use xwd or something else? Whatever works to show what your seeing. Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]tdfx_driver.c and video BIOS settings
I've been having problems for a while with my Voodoo3 2000PCI and XFree86 (what I thought was overheating: http://www.xfree86.org/pipermail/xpert/2001-August/010690.html ) Having searched through tdfx_driver.c in CVS, and looked at the voodoo3_spec pdf, I'm pretty sure the problem is due to the memory delay settings. The defaults given for the DRAMINIT1 register in the 3dfx specs seem to differ from those in the actual BIOS if the following info is correct: http://www.v3info.de/english/html/memdocs.shtml Specifically Bit13 (sg_clk_nodelay) is clear, not set as in tdfx_driver, and depending on the BIOS, various delays are imposed on reading from the SGRAM (set by bits 19-16). The oflop_del_adj bits differ too. I've a V3-2000PCI, BIOS 2.15.06, btw. It's entirely possible I haven't got a clue about any of this but couldn't the BIOS value for DRAMINIT1 be left unchanged unless some XF86Config setting says otherwise? The we've never had a problem with them [V3/V5] comment in the source made me smile. The lack of any fan near my V3 probably just exacerbates any marginal memory access settings; the hard lockup only occurs in a program which uses nearly 100% of texture memory and has very low CPU overhead (84fps in 1024x768) - and never a problem in Win98. Please tell me if I'm wrong; I'm not sure who's currently working on this driver, Simon Harvey Whittle Lab., Cambridge, UK. System: 366MHz Celeron, Voodoo3 2000PCI, 96MB RAM, Linux Kernel 2.4.13 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx_driver.c and video BIOS settings
On Fri, Dec 07, 2001 at 05:27:06PM +, Simon Harvey wrote: I've been having problems for a while with my Voodoo3 2000PCI and XFree86 (what I thought was overheating: http://www.xfree86.org/pipermail/xpert/2001-August/010690.html ) Having searched through tdfx_driver.c in CVS, and looked at the voodoo3_spec pdf, I'm pretty sure the problem is due to the memory delay settings. The defaults given for the DRAMINIT1 register in the 3dfx specs seem to differ from those in the actual BIOS if the following info is correct: http://www.v3info.de/english/html/memdocs.shtml Specifically Bit13 (sg_clk_nodelay) is clear, not set as in tdfx_driver, and depending on the BIOS, various delays are imposed on reading from the SGRAM (set by bits 19-16). The oflop_del_adj bits differ too. I've a V3-2000PCI, BIOS 2.15.06, btw. It's entirely possible I haven't got a clue about any of this but couldn't the BIOS value for DRAMINIT1 be left unchanged unless some XF86Config setting says otherwise? The we've never had a problem with them [V3/V5] comment in the source made me smile. The lack of any fan near my V3 probably just exacerbates any marginal memory access settings; the hard lockup only occurs in a program which uses nearly 100% of texture memory and has very low CPU overhead (84fps in 1024x768) - and never a problem in Win98. Please tell me if I'm wrong; I'm not sure who's currently working on this driver, Simon, This is already fixed in CVS, either use that or wait for 4.2.0. Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx_driver.c and video BIOS settings
On Fri, Dec 07, 2001 at 05:27:06PM +, Simon Harvey wrote: I've been having problems for a while with my Voodoo3 2000PCI and XFree86 (what I thought was overheating: http://www.xfree86.org/pipermail/xpert/2001-August/010690.html ) Having searched through tdfx_driver.c in CVS, and looked at the voodoo3_spec pdf, I'm pretty sure the problem is due to the memory delay settings. The defaults given for the DRAMINIT1 register in the 3dfx specs seem to differ from those in the actual BIOS if the following info is correct: http://www.v3info.de/english/html/memdocs.shtml Specifically Bit13 (sg_clk_nodelay) is clear, not set as in tdfx_driver, and depending on the BIOS, various delays are imposed on reading from the SGRAM (set by bits 19-16). The oflop_del_adj bits differ too. I've a V3-2000PCI, BIOS 2.15.06, btw. It's entirely possible I haven't got a clue about any of this but couldn't the BIOS value for DRAMINIT1 be left unchanged unless some XF86Config setting says otherwise? The we've never had a problem with them [V3/V5] comment in the source made me smile. The lack of any fan near my V3 probably just exacerbates any marginal memory access settings; the hard lockup only occurs in a program which uses nearly 100% of texture memory and has very low CPU overhead (84fps in 1024x768) - and never a problem in Win98. Please tell me if I'm wrong; I'm not sure who's currently working on this driver, Ooops. Noticed you've got a V3 and not a Banshee. If you change that ifdef to PCI_CHIP_VOODOO3 does it help your problem ? Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx_driver.c and video BIOS settings
On Fri, 7 Dec 2001, Alan Hourihane wrote: On Fri, Dec 07, 2001 at 05:27:06PM +, Simon Harvey wrote: Having searched through tdfx_driver.c in CVS, and looked at the voodoo3_spec pdf, I'm pretty sure the problem is due to the memory delay settings. Specifically Bit13 (sg_clk_nodelay) is clear, not set as in tdfx_driver, and depending on the BIOS, various delays are imposed on reading from the SGRAM (set by bits 19-16). The oflop_del_adj bits differ too. I've a V3-2000PCI, BIOS 2.15.06, btw. Ooops. Noticed you've got a V3 and not a Banshee. If you change that ifdef to PCI_CHIP_VOODOO3 does it help your problem ? Alan. Not sure where you mean. I've been looking at http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_driver.c?rev=1.86content-type=text/x-cvsweb-markup Around line 498 the DRAMINIT1 register is written to for anything other than a Banshee. I guess I could change this and try again, but I've never bothered a full compile of XFree86 on my Celeron; linux kernel takes long enough. I emailed Daryll Strauss too, the original author, and just got: -- Quote -- The problem is that each vendor used different DRAM in their boards. The actual 3dfx code, would take the value for these registers from the Windows registry. So, every hardware vendor had different values they determined and set from software. Leaving them entirely alone from the BIOS doesn't work, because not all vendors set them correctly in the BIOS. (That never worked on my cards). We tried picking the least common denominator type of number, but even that wasn't successful because setting it too high would break some boards and setting it too low others. About the only option anyone could come up with was to have a database of manufacturers and decide what values to use for each one. Mike Harris (at Red Hat) started to do that by collecting feedback from users, but I don't think he got much input and hasn't had time to implement what he did get. It's just a mess. -- EndQuote -- Do you know if this is still the case? If so I guess the only solution is cooling... ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Basically: xmfmk, imake and/or make after cvs co?
Hi, Should be the most simple of questions, but for the life of me, I can't figure it out : I have downloaded xfree68 into the xc directory with `cvs co xc` successfully (head - 10 minutes ago). Now how should I build it? With the GNU packages you run ./configure, but there is no such thing here. I read INSTALL-X.org, and there there are Easy build instructions. The first step seems to be to do something to site.def. Site.def attempts to include host.def , and I tried to copy the one from the programs/./bindist/Linux-ix86/, but then it ended up needing verison.def. I also tried 'cp site.sample site.def' and combinations of linux.cf also. Then the first command line I encounter is make World. But the xc/Makefile has no target called World, so regardless what I do to site.def, this will never work with make at this point. I now _know_ I'm missing something vital. The Complicated build instructions start with talking about downloading .tar files. I assume the I need the head revision to get support for my ATI Radeon Mobility card on my non-linux-compliant laptop. (The whole idea), so I have no tar files. I assume they contain the same as the xc CVS module. The first command line mentioned is still make World, so it won't work since World is still not in Makefile. I noticed the Imakefile (I've never used imake) and the imake FAQ said never to run imake directly but run xmkmf instead. xmkmf kept complaining about not finding Imake.tmpl, and this is only found in the config/cf directory, so I tried running xmkmf there. That didn't work either as it ended up needing version.def. I have no idea what to put in it, so I tried 'touch version.def'. Now xmkmf finishes, but World is still not in Makefile, nor in ../../Makefile. What am I doing wrong? The whole purpose of imake (according to the FAQ) is that it should make it real easy. What have I overlooked? Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Basically: xmfmk, imake and/or make after cvs co?
At 01:21 PM 12/7/01, you wrote: Hi, Should be the most simple of questions, but for the life of me, I can't figure it out : I have downloaded xfree68 into the xc directory with `cvs co xc` successfully (head - 10 minutes ago). Now how should I build it? All I do to compile it in redhat is to checkout xc then run make World then make install. This has worked every time for me without problems. -- Mark Lane Hard Data Ltd. mailto:[EMAIL PROTECTED] Telephone: 01-780-456-9771 FAX: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada T5X 1Y3 http://www.harddata.com/ -- Ask me about our Dual Processor Athlon DDR RAM Systems! -- --Or the New DDR Alpha Systems -- BEGIN:VCARD VERSION:2.1 N:Lane;Mark FN:Mark Lane ORG:Hard Data Ltd. TITLE:Sales TEL;WORK;BUSINESS:780-456-9771 TEL;WORK;VOICE:780-456-9771 TEL;WORK;FAX:780-456-9772 ADR;WORK:;;11060 - 166 Avenue;Edmonton;AB;T5X1Y3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:11060-166 Avenue=0D=0AEdmonton, AB T5X1Y3=0D=0ACanada URL;WORK:http://www.harddata.com EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010222T231737Z END:VCARD
Re: [Xpert]Xinerama questions...
On Fri, 7 Dec 2001, Mike Belangia wrote: Sorry if this is the wrong place to ask about this, but I was sent here from #xfree86 on openNet...Anyway, I just configured my x-server for xinerama, and it only partialy works. The first monitor still performs fine, but the second monitor only has the gray-default-no-window-manager screen but has a application dock in the upper left corner. The mouse also will not move to that monitor. If you could direct me to the appropriate source of aid I would be thrilled. Sounds like you're not running in Xinerama to me. That's just normal multihead without a window manager managing the second head. What does xdpyinfo say? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]single-button mouse + altgr emulating button 3
Hi - I have a problem with a single-button mouse on an integrated USB keyboard. Normal button 1 clicks are fine. When you hold down altgr and click, you get button 3, which is fine too. However, if you follow the sequence: - hold down altgr - click and hold mouse button - release altgr - release mouse button From watching xev, I do not get a button 3 (or even button 1!) release event. The system thinks button3 is held down until the next altgr + click. This button 3 reporting even happens when Buttons is set to 1 in the Inputdevice section. I can tell from debug by printf in input/mouse.c and common/xf86Xinput.c that it's not the hardware - it's always button 1 that is being reported. After that, I'm kind of at a loss - I'm not sure how to follow where this click is being interpreted into button 3. Don't see anything in the keymap or digging though xkb, etc. This is a system using 4.0.1. Does anyone know where to point me? Thanks. I would mainly like to know where this right button emulation happens in the code, or if this problem is something fixed/changed in newer releases. Thanks... -Edwin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: When is 4.1.1 (or what will it be?) is scheduled?
Mark Vojkovich wrote:
4.2.0 is supposed to be this month, but it will likely slip
into next year (because it always slips).
What about updating http://www.xfree86.org/ ?
4.1.0 is a new full release of XFree86. The next full release
will be 4.2.0, which is scheduled for mid-late November 2001.
If necessary, updates to 4.1.0 will be released before then.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niterói-RJ BR)
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ati radeon ve dvi / 6bit dac ?
howdy. i'm using the head of the cvs source tree's version of the radeon driver. the analog port uses 8-bit dacs, but the dvi port only outputs data in 6-bit mode, ir-respective of settings. i suspect this is a bug in the driver. under dimdoz, with the official ati radeon driver, i get all bits, so its not a hardware limitation. any help would be appreciated. further, i can drive both an analog and digital monitor simulatneously, and see that the digital is only in 6-bit mode under XFree86, while the analog port is indeed in 8-bit mode (24-bit depth invocation of XFree86) thanks, -elh ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Installing xfree86 4.1.99.1 and problems with Radeon Mobility M6 (LY) Chip
I have a Compaq 1700 notebook with a Radeon Mobility AGP 4x M6 (LY) video chip. I have installed Red Hat Linux 7.2 with XFree86 Version 4.1.0 (Red Hat Linux release: 4.1.0-3) and so far I have been unable to make it work. Based on what I have read I understand that I shouldn't have any problem if I use Xfree86 Ver.4.1.99.1. So, my question is in fact some small ones: - Is it true that with xfree86 Version 4.1.99.1 I would be able to work with the Radeon Mobility AGP 4x M6 (LY) video chip? - If this is the case, how can I download it? ( the ftp server only shows ver. 4.1.0.). - How I install it? - How I configure my video chip? (is it automatically recognized? is there any trick involved?). Thank you very much in advance for the help, Andres ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Basically: xmfmk, imake and/or make after cvs co?
Ohh, no, this is so embarrassing. For some reason the xc/Makefile got botched. rm Makefile ; cvs update Makefile fixed it and I'm now compiling. I must have seen an Imakefile and then typed "imake", which overwrites the Makefile - leaving me hopelessly lost. Or, more likely since we're close to christmas, it must be the elves messing around with my Linux box On behalf of the elves, I apologize for the noise on the list. It compiles fine, I'm sure. Peter (P.S.:I apologize ifthis posting doesn't appear correctly in the thread - didn't find a nice reply-to link)
[Xpert]MGA G4xx AGP doesn't get soft booted when secondary card ...
I tried installing a G450 AGP in place of my Rage Pro in my desktop machine at work recently, and was unable to get a picture from the Matrox card. It appeared from the server log that the driver couldn't find the BIOS on the card. I'm unable to make this the primary card as the BIOS in the machine doesn't offer a choice of where to boot VGA from; it's always the PCI card that comes up as primary video. A bit of poking around in the code showed the driver was not actually reading the BIOS, but it wasn't too obvious why; there was (and still is) a comment: Warning! This code currently does not detect a video BIOS It looks as though the code has changed a little since I tried this, but the comment is still there. Is this a limitation of the hardware or could I (or someone who has documentation) repair this? Would it be as simple as changing a few constants to suit the G4xx cards -- is the BIOS signature in a different place, or a little different? I'm not averse to experimenting. Can anyone point me in the right direction? I'm eager to get this to work as the ATI card struggles a little at 1600x1200x32@85 ;o) although it beats some other similar-aged cards I've tried hollow. -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include stddiscl.h ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][patch] Mach64 tv-out
Ahh, wonderful - thanks ! Vladimir Dergachev On Fri, 7 Dec 2001, Leif Delgass wrote: I've adapted the experimental tvout code for Radeon/r128 in gatos cvs to Mach64 and I'm atttaching the patch (can be applied to atimode.c in ati.2 or the mach64 DRI branch). It works for me, but it has the same problem of garbling the text console and mode switching with Ctl-Atl-+/- doesn't work correctly. However, I did have success with enabling tv-out even if it's not plugged in and detected by the BIOS at boot. This uses card BIOS functions specific to Rage LT Pro (which is what I have), Rage XL, and Rage Mobility (mach64 variety), but only if one of these chips is detected. Since the VBE functions are called for each mode switch, I can switch between my laptop LCD and TV by switching to a console, plugging in or unplugging the TV cable, and switching back to X. I changed the code from Radeon to recognize a display width of 800 (rather than 832), so I can use 640x480, 800x600 and 1024x768 without specifying custom modelines. However, it should also work with custom modelines as long as they use 640, 800, or 1024 width and 15, 16, or 32 bpp. This patch is of course rough and experimental, and I've only tested it on my setup, so the usual caveats apply -- your tv/monitor might blow up, etc. ;) Peter, since you worked on the r128 patch, can you take a look at this? -- Leif Delgass http://www.retinalburn.net ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
