Re: [Xpert] V_BIOS woes
Thomas Winischhofer writes: Adam Goode wrote: One last thing I noticed: Sometimes XFree86 prints this: (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x and sometimes this: (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03b0, hwp-PIOOffset is 0x (For the Radeon, hwp-IOBase is sometimes 0x03d0 and sometimes 0x03b0.) The SiS is always 0x03d0. Does this mean anything? At first I thought the Radeon was at was 0x03b0 when it failed, but it turned out that it can be 0x03b0 even when it works (and 0x03d0 when it fails). 0x3b0 is the IOBase for monochrome mode, 0x3d0 for color mode. The fact that the ati driver chooses the monochrome base might have something to do with reading an incorrect MISC register (which is responsible for choosing either color or mono). Yes, this is quite likely when the ATi Card isn't posted correctly. If the card is secondary and the Xserver cannot find the BIOS this is quite likely. Perhaps I am mislead myself, but shouldn't this setup require RAC (which is not being used according to the log)? Hm, not necessarily. Depends on how the resources are registered. The real question is why isn't the BIOS found? I fixed a PCIROM read problem in the ATi Radeon driver a while ago, this fix should be in CVS, though. I don't have the log so I cannot check if this says something about the nature of the BIOS problems. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: -fPIC issue
Jakub Jelinek writes: With the exception of Mesa stuff .a XFree86 libraries which are not shipped as shared libs too (.so + .a) aren't performance critical either, and using non-fpic code in them has some bad consequences: Yes, most of these libraries aren't performance critical. They don't do much more than providing a C interface to the underlying request. 1) it means the whole shared libs which link in even one tiny XFree86 non-fpic .a lib are DT_TEXTREL, which means bigger overhead when loading them and more unshareable pages. 2) they have more relocations, meaning more time spent in the dynamic linker on startup. 3) if there are any symbol lookup conflicts, it means those libraries aren't prelink(8)able, which can mean e.g. that all of KDE cannot be prelinked [1]. Yes, that's an issue I've learned about today, too. Thank you for bringing it up here. I was told prelinking may reduce kde application startup time by about 30 to 40 percent. This is definitely an aspect to keep in mind. So IMHO the default XFree86 behaviour, tweakable through imake macros, should be that .a libs which come with a corresponding .so should be -fno-pic while .a libs which don't have a corresponding .so should be -fpic. (Below is a patch I wrote months ago for this). So far I only marked those libraries that were identified by toolkits groups as targets of possible encasulation to be build with -fpic. Currently it is easy enough make ia32 build with pic. Just add a: #define StaticNeedsPicForShared YES to config/cf/hosts.def. Before we decide to add PIC to more/all .a files without corresponding .so we should see if there are arguments against this. As for Mesa, IMHO even libGL.so should be compiled with -fpic, I have some patches which should optimize the performance critical places in there, will test and benchmark them in the following days (had no 3D hardware until recently so couldn't do testing nor measurements) and post them afterwards. [1] ftp://people.redhat.com/jakub/prelink/ Have you raised this issue on the MESA/DRI mailing list? Once you have your benchmarks ready you should do so. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]-fPIC issue
Several times in the past we have seen requests to build libraries with the -fPIC flag for which XFree86 doesn't supply shared versions. These requests have always been turned down so far for two reasons: 1. XFree86 wants to discourage anyone from turning the static libraries into shared ones. These libraries are still under development and thus their API subject to change. XFree86 wants to ensure the APIs can still be modified without having to worry about providing backward compatibility. This would no longer be possible if the libraries were shared. 2. Position independent code (PIC) performs somewhat lower than non-PIC. PIC requires one CPU register to hold offset information. Thus this register is no longer available to the code itself. Recently I have been approached by the KDE project about this issue again. 1. In order to provide the functionality of these libraries thru the context of their API KDE fully wraps this libraries' APIs. Thus any call from a KDE application to these libraries is done thru functions provided by a shared library of this toolkit. Direct calls of the XFree86 libs are not permitted. However to do so the XFree86 libraries need to be linked into the shared libs these projects provide. 2. The ABI of the currently most widely used platform (IA32) does not require objects to be position independent when being linked into shared libraries. This is not true however for some platforms like IA64, PPC, x86-64 or AXP. To make toolkits like KDE work on these distribution vendors have added more or less nasty kludges to their XFree86 build configuration to either create shared versions of all XFree86 libraries or create a PIC version of these. As most GUI toolkits were developed on IA32 this problem has never been realized until these toolkits were ported to other platforms. Reviewing these arguments I arrived at the following conclusion: A. PIC .a libraries themselves are not usable as shared libs. B. The performance issue matters significantly only on IA32. All platforms that require PIC objects to build shared libraries have a sufficiently large number of CPU registers that performance penalties are negligible. C. A fully encapsulated XFree86 library API doesn't place any more burden on XFree86 to provide any more backward compatibility than statically linked libraries. I therefore propose the following procedure: A. Identify all XFree86 libraries whose may be encapsulated by toolkits shared libraries without being shared themselves. B. Compile libraries identified in 1. with -fPIC on platforms that require position independent code for shared libraries. C. Always require a full encapsulation of the API when a static XFree86 library is added to a shared toolkit library. Thus: a. Toolkit designs that need to expose any part of this ABI are considered broken. b. Applications that reference any part of this ABI bypassing the toolkit are considered broken. I would like to get feedback from the community on this. After talking this over with David I have implemented and committed it to the XFree86 CVS. However David suggested to discuss this in public. Should any serious objections arise We can still modify/remove it before 4.3 comes out. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 libint10 in non-x86 environments
John Dennis writes: John Dennis writes: John I'm trying to fix some bugs with XFree86 drivers in an Itanium John (ia64) environment. ... Egbert I don't think you need to do too much for ia64. It works Egbert on all ia64 systems I have tested so far. Unfortunately I have an example where it does not, see below. Egbert However Itaniums usually do have x86 BIOS cards. Not on the 2nd generation ia64 boxes from HP. First generation supported x86 BIOS, but HP decided to eliminate x86 BIOS emulation for the 2nd generation, in part as I understand from a paper Porting Drivers to HP ZX1 by Grant Grundler of HP, to force adoption of EFI (Extensible Firmware Interface). Interesting. Every once a while somebody comes up with something new. At least I have a HP box which has a x86 BIOS. Possibly because it is from the '1st generation' of machines. John ... is there some alternate mechanism for configuration in John these environments that XFree86 supports or intends to John support (e.g. EFI?). Egbert Possibly. If you can give us some information on EFI. I'm probably the wrong person to fill you in on EFI, I've only been just learning about it as I try to track down this problem. FWIW, in the paper by Grundler he states all the IO card vendors that supply HP have committed to providing such a driver (EFI) and I know they are delivering or have delivered. Egbert There are very few architectures where we build a stub Egbert libint10. These are mostly architectures that have an Egbert OpenFirmware approach. We expect libint10 to work on all Egbert other architectures. see below Egbert Maybe you can give us some insight into what problems you Egbert are running into with libint10 on ia64? O.K. here is the issue. I'm trying to make XFree86 with ATI drivers run on both Intel and HP ia64 boxes with hopefully a common xfree86 binary package shared between them. The Intel boxes support x86 BIOS, the HP's do not. HP's proposed solution was to remove libint10.a from the modules directory so that the ATI driver init code would not find the library and load it, and initialize it. This is because xf86InitInt10 touches some address that is not valid and causes a machine check (or at least that is my current understanding, I'm still trying to nail down exactly where the fault is occurring). I've run into exactly the same issue on my box. You don't have to eliminate the entire libint10. The problem are Lock/UnlockLegacyVGA(). I've submitted a solution for this problem to CVS. You need to put an #ifndef __ia64__ ... #endif around the line which accesses address 0x46e8 (and possibly 0x102 - I don't remember). This will not get you off the hook completely as the ATi drivers probes for some Mach variants will make the box machine check, too. I've talked to Marc Aurele about this. He proposed to add information about host bridges to the Xserver where we can keep information on which address ranges on the PCI bus can be probed savely. So far I think he is still waiting for the necessary information by HP. My quick-n-dirty work around was to '#ifdef __ia64__'-out all probing for 'legacy' HW in the ATi driver. This however will not be in the CVS. Yes, I've seen some of HP's hacks for XFree86. All I've seem was not usable for XFree86. The lack of libint10 does not seem to cause problems for the ATI radeon drivers which is what HP ships. The ATi driver reads information from the BIOS. On some versions of the linux kernel the BIOS image that was created when the system was initialized by the firmware was busted. This required some reposting to get a clean BIOS image. I believe this kernel problem has been fixed now. However, the ATI rage drivers do not deal well with the lack of libint10 and seems to set really bogus video timings as a result (there are other bugs I've fixed where the rage driver will crash if libint10 is not present). In fact in the rage driver only part of the code checks for the existence of libint10 and other parts of the code blithely assumes it's existence. This is a bug. On the Intel ia64 boxes libint10 does work and is necessary for the ATI rage driver to come up correctly. I've got it to work on my HP box, too. Therefore we have a situation where on two boxes that are architecturally identical (or at least really really close) and depending on the installed video card libint10 has to be present or absent or really bad things happen. The solution proposed by Marc will solve this problem. I'm not a fan of the idea of not installing libint10 on ia64 to solve this problem, its a hack solution and is not general and it makes coming up with a common binary package for ia64 problematic and what happens if someone switches the video card? Right. Well, libint10 should work for all
Re: [Xpert]xfree86 libint10 in non-x86 environments
John Dennis writes: I'm trying to fix some bugs with XFree86 drivers in an Itanium (ia64) environment. Many of the drivers seem to have a strong dependency on libint10 for configuration, especially for getting monitor configuration information via DDC/VBE which depends on int10. I don't think you need to do too much for ia64. It works on all ia64 systems I have tested so far. I'll admit libint10 is one area of the XFree86 server I'm less familar with, although I have spent some time reading the source, but I've still got some questions. 1) It there an expectation that libint10 should work in a non-x86 environment? As far as I can tell at this point libint10 is completely dependent on an x86 BIOS being implemented, is that true? Yes, and yes. However Itaniums usually do have x86 BIOS cards. 2) If one removes libint10 it seems like some of the drivers are incapable of automatically configuring the monitor and getting their initial clock timings correct (yes, this can be hardcoded in the config file but thats not a very supportable solution). If libint10 is not expected to work without an x86 BIOS present then is there some alternate mechanism for configuration in these environments that XFree86 supports or intends to support (e.g. EFI?). Possibly. If you can give us some information on EFI. 3) In the XFree86 source tree I see only a handful of scattered checks for int10 support. Some drivers seem to rely on the module libint10.a not being present in lib/modules. But this seems like a weak test since a working libint10 varies even within architectures. Is this just a new problem area I'm stumbling on or is there some cohesive way to deal with this I'm missing? There are very few architectures where we build a stub libint10. These are mostly architectures that have an OpenFirmware approach. We expect libint10 to work on all other architectures. 4) Can someone point me to documentation on video BIOS that might help me understand some of what is going on in libint10? So far all I've found is the int 10 interface for user code, but not what is going on under the covers. www.vesa.org seemed the obvious place to look but I didn't find anything in the public area. I don't know of a single documentation. We collected our knowledge from the PCI BIOS specs, VESA BIOS specs, dosemu and experience. Maybe you can give us some insight into what problems you are running into with libint10 on ia64? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Support for the VLB bus.
I don't see what special support is required for VLB bus. It should work like an ISA Bus system as long as you are not trying to get a VLB/PCI motherboard to work. We have no knowledge of VLB-PCI bridges therefore it is not unlikely that you run into trouble with these systems. That you cannot get the S3 Trio32 to work under 4.2. is more likely due to the fact that this chip isn't supported by 4.2. Egbert. Shaul Karl writes: Hello, It is my understanding that 4.2.1 does not support the VLB bus. Am I correct? Are there other people who would be interested in having this bus supported? Is there work in progress to have this bus supported? Can I help by testing what was being done so far? Are there any pointers for reading material for a beginner who want to get his VLB card supported? How difficult it would be to import the VLB supporting code from 3.3.6 to 4.2.1? My hardware is an S3 Trio32 VLB card: Miro CRYSTAL 12sd. The card works well with 3.3.6 but not with 4.2.1. The platform is i386 Linux 2.4.19. I can post the output of X when it starts if this is of interest to someone. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Patch for the Xlib i18n code
Olivier Chapuis writes: On Mon, Oct 21, 2002 at 03:14:47PM +0200, Egbert Eich wrote: I have some more patches for omGeneric.c. So I will take care of your fixes. Thanks. Thanks to have applied my patch! Just one note without real importance, my name is Chapuis and not Chapius :o) OK. I have altered your patch a little bit: 1. I've restructured your patch of lcFile.c a little bit. 2. in omGeneric.c we don't need to free xlfd_name because it doesn't get allocated by parse_fontdata() when we pass NULL as the font_data_return argument. In all cases but C_PRIMARY we don't care about this information. Otherwise your fixes were OK. Thanks! Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
Michel =?ISO-8859-1?Q?D=E4nzer?= writes: However I still don't see where BM might get disabled explicitely when it had been enabled when the server was first started. Does it matter? Anything could disable BM while we're switched away... It was posted that this happened while X was active. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx soft-boot hang revisited
Bo Brinkman writes: So I suppose I should add some more breaks to be certain it is really the xf86ExecX86int10() call that is causing the hang, and not something that happens later? I'm not sure what to try next, since the BASEROM value doesn't look silly. If you diff the 2 files, you will notice that not too much changes...but then I don't know how to read the scanpci output, so... :) Yes, that would be nice. Do a breakpoint immediately after the xf86ExecX86int10() function so you can see if it comes back from POSTing. At least we are now sure it was not the routine that reads the PCI BIOS. This had been run successful when you reached the breakpoint. When you are at the breakpoint you could examine the log for something strange. Did you say your system locks up completely so that you cannot even get on it remotely? If so, did the same setup ever work under an earlier version of XFree86? Regards, Egbert. -- pci bus 0x cardnum 0x0a function 0x00: vendor 0x121a device 0x0005 3dfx Interactive Voodoo3 CardVendor 0x121a card 0x0036 (3dfx Interactive Voodoo3 2000) STATUS0x8090 COMMAND 0x CLASS 0x03 0x00 0x00 REVISION 0x01 BASE0 0xc400 addr 0xc400 MEM BASE1 0xca08 addr 0xca00 MEM PREFETCHABLE BASE2 0xb001 addr 0xb000 I/O BASEROM 0xc9ff addr 0xc9ff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x05 BYTE_00x01 BYTE_1 0x00 BYTE_2 0x8073de8 BYTE_3 0x pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x121a device 0x0005 3dfx Interactive Voodoo3 CardVendor 0x121a card 0x003a (3dfx Interactive Voodoo3 3000) STATUS0x80b0 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0x01 BASE0 0xc600 addr 0xc600 MEM BASE1 0xce08 addr 0xce00 MEM PREFETCHABLE BASE2 0xd801 addr 0xd800 I/O BASEROM 0xcdff addr 0xcdff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_00x01 BYTE_1 0x00 BYTE_2 0x8074bc8 BYTE_3 0x pci bus 0x cardnum 0x0a function 0x00: vendor 0x121a device 0x0005 3dfx Interactive Voodoo3 CardVendor 0x121a card 0x0036 (3dfx Interactive Voodoo3 2000) STATUS0x8090 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0x01 BASE0 0xc400 addr 0xc400 MEM BASE1 0xca08 addr 0xca00 MEM PREFETCHABLE BASE2 0xb001 addr 0xb000 I/O BASEROM 0xc9ff addr 0xc9ff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x05 BYTE_00x01 BYTE_1 0x00 BYTE_2 0x8073de8 BYTE_3 0x pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x121a device 0x0005 3dfx Interactive Voodoo3 CardVendor 0x121a card 0x003a (3dfx Interactive Voodoo3 3000) STATUS0x80b0 COMMAND 0x CLASS 0x03 0x00 0x00 REVISION 0x01 BASE0 0xc600 addr 0xc600 MEM BASE1 0xce08 addr 0xce00 MEM PREFETCHABLE BASE2 0xd801 addr 0xd800 I/O BASEROM 0xcdff addr 0xcdff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_00x01 BYTE_1 0x00 BYTE_2 0x8074bc8 BYTE_3 0x ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx soft-boot hang revisited
Bo Brinkman writes: Egbert Eich wrote: Sorry if I'm being an idiot, but could you give me a bit more of a hint about where I should stop the execution? Is this in the TDFXProbe code or in the int10 module? I didn't find any comments in either place that made it totally obvious to me that the BIOS is about to be POSTed. ;) I can't seem to make the module-aware gdb work either, but I'll just add a call to one of the dummy break functions in the appropriate place, since I don't really need to dig around in gdb. Yes, that's the simplest way to do it. You should break in os-support/linux/int10/linux.c somwhere before xf86ExecX86int10() gets called. FWIW, it looks like we are actually getting a SIGFPE, which is not what I expected... This looks like the BIOS is doing something strange. You should find out if this happens when a card is posted or when another BIOS function is called. Also note that before X ever runs, this is what scanpci -v gives for this card: pci bus 0x cardnum 0x0a function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x0036 (3Dfx Interactive, Inc. Voodoo3) STATUS0x8090 COMMAND 0x CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc400 addr 0xc400 MEM BASE1 0xca08 addr 0xca00 MEM PREFETCHABLE BASE2 0xb001 addr 0xb000 I/O BASEROM 0xc9ff addr 0xc9ff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x05 BYTE_00x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 Notice that BASEROM doesn't look crazy like it used to... It used to be left set to 0x. I assume that something has changed in the kernel which causes the BASEROM to be set in this way, because 0x is the default value, and I assume it would stay there unless intentionally changed. Here is the scanpci -v output for the primary card, for comparison (Note that it is an AGP card). The BASEROM value looks OK. pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x003a (3Dfx Interactive, Inc. Voodoo3 AGP) STATUS0x80b0 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc600 addr 0xc600 MEM BASE1 0xce08 addr 0xce00 MEM PREFETCHABLE BASE2 0xd801 addr 0xd800 I/O BASEROM 0xcdff addr 0xcdff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_00x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 I will post complete scanpci -v info once I figure out where to put my breakpoint to generate the other info that Egbert wanted. OK, that would be great, thanks. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]!! Correction for i810 driver !!
Hi Matthew,
thanks for following up on this.
Sottek, Matthew J writes:
Egbert,
Actually... I'm thinking there is a problem with this way too. We need
another if in there. i.e.
if((tv is on) (vbios left a set of TV timings for us)) {
use TV regs;
} else {
use crt regs;
}
Otherwise we might end up using the TV timings even when the display is not
on
the TV (depending on what the vbios does when using CRT in a system that has
a TV controller).
Yes, I suspected something like this.
Check the LCDTV_C register (offset 0x60018) bit 31. If it is set then
the TV is in use. So try this one:
File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
Somewhere near line 1522
unsigned int lcdtv_c=0;
unsigned int tv_htotal=0;
/* OVRACT Register */
lcdtv_c = INREG(0x60018);
tv_htotal = INREG(0x6);
if((lcdtv_c 0x8000) (tv_htotal)) {
i810Reg-OverlayActiveStart = (temp16) - 31;
i810Reg-OverlayActiveEnd = (temp 0x3ff) - 31;
} else {
i810Reg-OverlayActiveStart = mode-CrtcHTotal - 32;
i810Reg-OverlayActiveEnd = mode-CrtcHDisplay - 32;
}
We may need more changes than that.
It is still not clear to me if the change in
the OverlayActiveStart and OverlayActiveEnd settings
will do on an LCD.
In the end we are just reducing the ActiveStart and
ActiveEnd registers by 31. I don't see why we need to
do this.
Also we read out the values in SetMode. When this function
gets called the values of these regsiters may not be the
original ones set by the BIOS any more as SetMode()
may be called several times.
We need to grab the value in PreInit() - or if the
BIOS may change them behind our back - save and compare
the value we have set and refresh it in case it has
changed.
However I won't implement this until I understand better
why we have to touch these values in the first place.
Sebastien, could you please check what happens when these
these values are left the way the BIOS set them?
Regards,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]tdfx soft-boot hang revisited
Bo Brinkman writes: Several months ago I mentioned that tdfx soft-boot problems seem to have re-appeared. I haven't had time until now to poke around into it. The current behavior (linux kernel 2.4.18-10, XFree86 4.2.0-8 through 10/12/2002 CVS) is that whenever I try to softboot either my Voodoo3 2000 or Voodoo3 3000, the entire OS goes down. We used to have this problem due to improper PCI code (see the archives). No log file ever gets saved, but when I start X remotely, this is what I get: Unfortunately this is completely useless. Please send a scanpci -v output prior to starting X and one just before the BIOS is POSTed. To do that you need to put a breakpoint into the code and run it inside gdb. See xc/programs/Xserver/hw/xfree86/DebuggingHints in the sources for details. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Using the chips XFree86 driver on a PowerBook3400 (almost there.)
Michael Stephen Hanni writes: G'day Egbert, The funny thing is that using either cursor I get this behavior. I'll look into this, maybe I did something that made the hardware cursor be used regardless of the option setting. Hmm, that's funny. It is possible that the cursor Image is goffed before. You usually have a foreground and a background mask. If one of the masks is goofed you get this behavior regardless if you use sw or hw cursor. BTW, I'm working off CVS HEAD. Oh, I haven't really touched this but XVideo is still fscked. I'm getting BadAllocs all over the place. Please see my last email about this. Yeah, what you said sounds absolutely correct. I've disabled the CHIPSVideoInit/Reset in my build. You should not have to. I assume you do that to force your application to do a fallback to SW rendering. This however should always happen if Xv signals an error. I had to mess around with the aperture, but I think I've got the aperture and the MMIOBase setup correctly now. By dropping a slightly modified ct_BltHiQV.h from the last Xpmac tarball into the latest XFree86 source everything works nicely. If you send me the patch I'll check this. I'll do this when I get back to the other side (i.e. Linux). Beware this ct_BltHiQV.h has some interesting looking asm code to accomplish the ct* macros. I'm pretty sure this is powerpc specific so it may not be something you would want to put into the official source. However, the bonus of this is that I had to make very few changes to the driver as it currently stands, plus I got all the accelerated functions for free -- save for the aforementioned WritePixmap. I will take a look. We can (however it is discouraged) use #ifdef __powerpc__ . Anyhow, I'll clean it up and send it to you tonight. Thanks! I'm using this modified chips driver as my default X setup and I haven't noticed anything broken or unusual. It seems to be snappier and smoother than the FBDev driver I had been using, but that may just be the placebo effect at work. I'll run some x11perf tests and check it out. OK, great! Thanks, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Write Combining Range issue on Savage
Matteo Giani writes: Hi all. I know this has probably been asked a million times, I just couldn't find a clear answer. I apologize in advance for this... As I read on usenet, it is a known issue that xfree86 4.2.0 tries to split the framebuffer into tiny regions and setup hundreds of write combining ranges on savages with shared memory. Sadly, I ran into this issue just tonight when my apt upgraded X to 4.2.1 (it used to work on 4.1.0). I was just wondering if anyone has come up with a workaround/fix for it. Sorry if this has been asked just too many times... Best regards. It is very surprising that this still happens. I've reworked the mtrr code to try its best to avoid this. Please send me the relevant part of your log file. In principle the driver should make sure that the condition (framebuffer start address size == 0) is met as the CPU has this requirement for the ranges. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Using the chips XFree86 driver on a PowerBook3400 (almost there.)
Michael Stephen Hanni writes: Howdy. Well I've got it all to work save for the WritePixmap acceleration as it makes use of some fun MoveDataFromCPU/MoveDWORDS magic. With WritePixmap active there is a small box of color distortion around the mouse cursor. I'm sure the MoveDataFromCPU function is assuming little endian data, but I don't know exactly what I'm looking at. Are you using SW Cursor? Otherwise WritePixmap shouldn't affect the Cursor. Oh, I haven't really touched this but XVideo is still fscked. I'm getting BadAllocs all over the place. Please see my last email about this. I had to mess around with the aperture, but I think I've got the aperture and the MMIOBase setup correctly now. By dropping a slightly modified ct_BltHiQV.h from the last Xpmac tarball into the latest XFree86 source everything works nicely. If you send me the patch I'll check this. As for the hardware cursor, you will have to swap the image of the cursor. See the hw cursor support for radeon (or r128) and apply similair necessary the big endian bits. Ah, got ya. I'm going to run some more tests and then I'll upload a patch somewhere for general consumption. Maybe, just maybe, there are other people that use this chip on a big endian machine. Please send the patch this way. As I'm the CT maintainer. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Cirrus CLGD5430 woes...2nd try
Oliver Schurr writes: Oliver Schurr wrote: Hi Xperts I have a Cirrus CLGD 5430 1MB card, (alpine card) that works perfectly in X 3.3.2.3 for the last 5 years and I can get 800x600x16bit without any problems. Monitor settings 31.5-64.3 KHz, 50-100 Hz BUT, not in X 4.2.1! I tried everything I could think of... frequencies, referesh rates, and I even put the ModeLines from the XF86Config into the new XF86Confg-4 file and it still can't do 800x600x16bit resolutions. I did compile X4.2.1 from sources here and that gave no problems at all. For what it's worth, the 8 bit depth works just as well in X 4.2.1 as it did in X 3.3.2.3, so no problems there. Here's a piece from the X4 log file. (II) CIRRUS: driver for Cirrus chipsets: CLGD5430, CLGD5434-4, CLGD5434-8, CLGD5436, CLGD5446, CLGD5480, CL-GD5462, CL-GD5464, CL-GD5464BD, CL-GD5465, CL-GD7548 (II) Primary Device is: PCI 00:04:0 (--) Chipset CLGD5430 found (II) Loading sub module cirrus_alpine (II) LoadModule: cirrus_alpine (II) Loading /opt/X11R6/lib/modules/drivers/cirrus_alpine.o (II) Module cirrus_alpine: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 Further down I also get some errors from the CIRRUS autodetection like (II) CIRRUS(0): initializing int10 (II) CIRRUS(0): Primary V_BIOS segment is: 0xc000 (++) CIRRUS(0): Depth 16, (--) framebuffer bpp 16 (==) CIRRUS(0): RGB weight 565 (==) CIRRUS(0): Default visual is TrueColor (**) CIRRUS(0): Option MMIO true (==) CIRRUS(0): Using SW cursor (--) CIRRUS(0): Linear framebuffer at 0xE000 (EE) CIRRUS(0): No valid MMIO address in PCI config space (--) CIRRUS(0): Not Using MMIO (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /opt/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.5 (II) Loading sub module ddc (II) LoadModule: ddc (II) Loading /opt/X11R6/lib/modules/libddc.a (II) Module ddc: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (EE) CIRRUS(0): I2C initialization failed (==) CIRRUS(0): Using gamma correction (1.0, 1.0, 1.0) (--) CIRRUS(0): Memory Config reg 1 is 0x15 (--) CIRRUS(0): VideoRAM: 1024 kByte (==) CIRRUS(0): Min pixel clock is 12 MHz (--) CIRRUS(0): Max pixel clock is 50 MHz (II) CIRRUS(0): Monitor0: Using hsync range of 31.50-64.30 kHz (II) CIRRUS(0): Monitor0: Using vrefresh range of 50.00-100.00 Hz (II) CIRRUS(0): Clock range: 12.00 to 50.00 MHz MMIO did work just fine in X 3.3.2.3 and was clearly detected when I piped the output of startx into a file. And I don't know about that i2c stuff. Is there something inherently wrong/unsupported in the cirrus/cirrus-alpine drivers in X 4.2.1 that previously was supported in X 3.x? Any ideas what I can do to get 800x600x16bit resolution in X 4.2.1? Are there any tweaks in the .cf files in the source code that enable more/other features in the cirrus/cirrus-alpine drivers that enable those capabillities? Thanks a lot folks. Please explain in more detail: ... still can't do 800x600x16bit resolutions. Also include a *full* log file of an attempted 800x600x16bit start. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Intercepting keyboard events from within video driver?
Thomas Winischhofer writes: Thanks Mark, Alex, Xavier, Branden. Mark Vojkovich wrote: On Mon, 30 Sep 2002, Thomas Winischhofer wrote: The hardware I am developing for has two CRT controllers (actually it's [...] registers. However, involving the BIOS is definitely not desired.) Those key presses often never get passed the BIOS. They won't even get to the X-server. That's the way they work on the recent laptops that I've had experience with. No software outside of the BIOS knows about it. I know. That's the problem. This key combination causes a *complete* machine lock-up here and on many others. And the idea also was to keep the BIOS from messing around with the registers (eg. while Xv is active, etc). I have seen (literally *seen*, felt like 10 years ago in my assembler era) many SiS BIOSes causing the strangest effects (mouse cursor jumps around wildly in the first left 32 pixels of the screen, xv is totally skrewed up, etc). And the final - and most important - reason is that the BIOS drives the video bridge in slave mode (don't bother...) and this would end up in a catastophe in dual head mode. So, I thought of another qd solution: In the good, old CTRL-ALT-KP_Plus/Minus-manner why not intercept eg. CTRL-ALT-KP_Multiply and cycle through all possible output devices (LCD, TV and - theoretically - secondary VGA, that is)? Can this be done from within a video driver? I looked though the input related code but could not find a solution. I suspect that it's not possible for the video driver to intercept key presses. To hear that from Mark makes it sound quite final.. :( But then, sorry, if I'm annoying: Remember, what I want is not necessarily a secure or standard compliant solution; the target user group is a few people who know what they're doing. What about installing a wakuphandler (or wrapping the old one), wrapping some xkb resource or something like that? No, the Xserver will never see these keys being pressed. Neither does the kernel. Usually these key kombinations involve the Fn-key. Some hardware in the keyboard controller detects this and issues a system management interrupt. Therefore neither X nor the kernel get scheduled before the fatal code has been executed. I have never tried this but it may be possible to tweak the kernel so that you get a chance to intercept the system management interrupt. As far as I know there is support for such things in ACPI. Also there must be a way for the windows driver to deal with these situations. Alex Deucher wrote: you could create a little cli app like s3switch for savage based cards that will switch the output between tv and crt2. then map the keyboard shortcut to run that cli app using your window manager, etc. This would result in writing a server extension. Otherwise an application outside the server won't be able to communicate with the driver, if I'm not mistaken... (And the driver not only NEEDS to know about the change, it is also the driver which is to PERFORM it; setting up LCD or TV on SiS chipsets is ca 500k source code since the driver supports 8 chipsets with each 4 possible video bridges and so far ca. 60 different panel types) - if anybody knows better, feel free to object! I have an extension in mind which can be used to control device specific features. Drivers can register properties that can be set, applications can query the property list, the value type, ranges and current value. I've planned this as an extension to the xf86misc extension which allows to control certain keyboard and mouse features but which isnt extensible. Once you have this extension you can write applications that catch certain key events and use the extension to change device properites. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rendition v2x00
Phil T writes: Hi, I'm fixing the acceleration in the rendition driver and I need some info on the STATUS register - flags, masks etc. I'm polling it in the Sync function in XAA for idle status. Any help? To the maintainer of the rendition driver: I have fixed some of the bugs in the initialization and acceleration code, i could send you my code if you are interested. I probably was the last one who touched the Rendition driver to make it usable at least unaccelerated. I did all my work without access to any documentation. I doubt that anyone has any docs. So you may need to do some experimenting. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
Bill Soudan writes: On Wed, 25 Sep 2002, Sottek, Matthew J wrote: No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. I've posted a few example pics of the corruption I see: http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted menubar http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of corruption The corrupted regions are 14x22, with the exception of the one above 'hours'. Each region is a well-formed horizontal gradient (!). If the pitch was off while blitting from pixmap cache to framebuffer, wouldn't the corruption just be garbage? And a width of 14 seems like a really odd size for a blit to me. Maybe the problem then isn't with the blit from the pixmap cache to the framebuffer, but it's that the pixmap cache itself is getting corrupted? Jeff's memory management patch is looking fairly attractive. The XAA code uses ScreenToScreenCopy to create a background pixmap in offscreen memory out of the elemantary tile. In KDE the backgrounds of the menu bars are created this way. When a menu bar needs to be redrawn XAA simply copies a portion from this offscreen pixmap into the framebuffer. Now the problem: The i810 blit engine seems to be broken in that it cannot copy a portion of the framebuffer right to the right of itself if the width of this area is in a certain range. I found that out by trial and error as Intel appearantly doesn't provide errata sheets. I've attempted to make a fix for this which I will soon commit to CVS. I don't know it it catches all cases however the KDE desktop on my test machine appears to be uncorrupted now. Your milage may vary. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Crash in xkbcomp during build [CVS]
I don't see where free() gets called from _XlcLocaleDirName(). Please build the library with debug option (call 'makeg' instead of 'make'). Regards, Egbert. Biswapesh Chattopadhyay writes: Hi all M/c: RedHat 7.3/kernel 2.4.18-10/P41.8/512MB/i845 I'm trying to build XFree86 CVS (updated today morning) and getting the following error: --- . make[5]: Entering directory `/usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbols' rm -f symbols.dir LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/xkbcomp -lfhlpR -o symbols.dir '*' make[5]: *** [symbols.dir] Segmentation fault make[5]: *** Deleting file `symbols.dir' make[5]: Leaving directory `/usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbols' make[4]: *** [all] Error 2 -- Using GDB, I'm getting a weird backtrace (mem corruption ?) -- TECHSHELF:/usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbolsLD_LIBRARY_PATH=../../../exports/lib gdb ../../../exports/bin/xkbcomp /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distrib /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)ute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) set args -lfhlpR -o symbols.dir '*' (gdb) run Starting program: /usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbols/../../../exports/bin/xkbcomp -lfhlpR -o symbols.dir '*' Program received signal SIGSEGV, Segmentation fault. 0x4207ac55 in free () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207ac55 in free () from /lib/i686/libc.so.6 #1 0x4008efd9 in _XlcLocaleDirName () from ../../../exports/lib/libX11.so.6 #2 0x40088f29 in _XlcDynamicLoad () from ../../../exports/lib/libX11.so.6 #3 0x4006c6ca in _XOpenLC () from ../../../exports/lib/libX11.so.6 #4 0x4006c819 in _XrmInitParseInfo () from ../../../exports/lib/libX11.so.6 #5 0x400568f4 in NewDatabase () from ../../../exports/lib/libX11.so.6 #6 0x400588d5 in XrmGetFileDatabase () from ../../../exports/lib/libX11.so.6 /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) #7 0x4004fb4a in _XInitKeysymDB () from ../../../exports/lib/libX11.so.6 #8 0x4004fcb2 in XStringToKeysym () from ../../../exports/lib/libX11.so.6 #9 0x080646d9 in LookupKeysym () #10 0x080638b6 in yyparse () #11 0x080649f3 in XKBParseFile () #12 0x08062b92 in GenerateListing () #13 0x0804b560 in main () #14 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) --- Dynamic linking seems to be OK.. - TECHSHELF:/usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbolsLD_LIBRARY_PATH=../../../exports/lib ldd ../../../exports/bin/xkbcomp libXext.so.6 = ../../../exports/lib/libXext.so.6 (0x40014000) libX11.so.6 = ../../../exports/lib/libX11.so.6 (0x40022000) libc.so.6 = /lib/i686/libc.so.6 (0x4200) libdl.so.2 = /lib/libdl.so.2 (0x4010d000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) TECHSHELF:/usr/src/redhat/BUILD/XFree86-4.2.5/xc/programs/xkbcomp/symbols Any pointers ? Thanks in advance. Rgds, Biswa. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Patch for RAC in s3 driver?
Gcc k6 testing account writes: Ave people. I tried to use a s3 trio with a riva tnt2 ultra in a multi-head configuration with XFree86 CVS code of today (28 aug) ,and unfortunately it doesn't work. Searching the xpert list I saw that this is a known problem. In the thread at www.xfree86.org/pipermail/xpert/2002-July/018976.html Egbert Eich mentions a patch for the s3 driver so that it will do resource registration right. My question is: Is that patch already in CVS? If so,it doesn't work for the combo s3 trio primary,riva tnt-ultra secondary. No, not at the moment. Sorry. I'm way to busy to commit all my patches at the moment. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]blurry fonts: XF86 4.2.0 / FreeBSD 4.6
[EMAIL PROTECTED] writes: If your freetype is compiled without hinting, then you get blurry fonts... Also, you need high quality hinted fonts for best results... - Jim Just a not about quality hinted fonts: M$ has removed the TT WebFonts from their server. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]write_mem_barrier()
Mark Vojkovich writes: On Thu, 15 Aug 2002, Egbert Eich wrote: Can any two register writes get written out of order? They can, however this may depend on their address order. If the address order is ascending you may be lucky. I never went into this really deeply. If so, then the fences in the nv driver are misplaced and insufficient. For each primitive, the last register in the sequence is what initiates the drawing. If the setup writes were not commited before the kickoff write, things will be wrong. Yes, that's the way it is done on a lot of chipsets. Do you see any problems on a specific architecture? I know that Jay Estabrook has done a lot of otpimization for the Alpha - he may tell you more about the rules where fence instructions need to be placed. But again this may be architecture dependend. Well, here's the deal. Color expansion doesn't work reliably on PowerPC with the nv driver and there doesn't seem to be any reason for it other than architectural issues. Have you tried adding some more fences? We may have to add architecture specific fence macros :-(( I could try both Alpha and PPC as I can get access to both platforms however I don't have time right now. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]write_mem_barrier()
Mark Vojkovich writes: To me the application of write_mem_barrier() to drivers like the nv driver seems almost haphazard. Can someone explain what the criteria is for placing these? These marcos are required only for weak ordering architectures like Alpha and expand to nothing on architectures that don't have this property. Ia32 is one of them. Generally you want to issue them to make sure all data has been written to the bus before executing the next instruction. You want to do that before you read data from a register which may depend on data written to another register previously. Also you want to issue it before you write to a register that starts an operation that depends on data written to other registers and you want to issue this instruction afterwards to make sure the operation actually gets initiated. That's the theory - generally it takes some experiments. We even don't know yet if all weak ordering architectures behave exactly the same ie. if they require the fences at the same place. If you use the MMIO_OUT macros you don't need to worry about setting fences as these are fenced already. Fencing any write is suboptimal however therefore drivers should be tuned to use the MMIO_ON macros and fence explicitely. As far as I remember I started to add support for non fenced writes to the nv. Jay Estabrook fixed some problems and did a lot more tuning for the Alpha. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XF86_SVGA server
David Bateman writes: According to Carlos Luna [EMAIL PROTECTED] (on 07/16/02): Howdy folks! I've installed RedHat 7.2 (Linux 2.4.7) onto a PC-104 embedded board. It has a ChipsTechnologies CT69000 graphics controller on board. Installed is GNome. When I start it up, Gnome has problems and I end up it text mode. The problems report a fatal server error: Signal 11 Without the log of the output from the Xserver this information is not that useful. I believe this still is the problem we had with the 4.1.0 driver. The fix would be to upgrade to 4.2. Unfortunately plain 4.2. has the problem that silken mouse cannot be disabled. Therefore one may have to disable the HW Cursor for all CTs on 4.2. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SM 710 VESA BIOS
David W. Chapman Jr. writes: Under FreeBSD 5.0-current using XFree86 4.2.0 I get the following errors if I let the driver use the VESA BIOS. I can successfully run X windows if I tell the driver not to use the VESA BIOS. Is this a problem with the driver or my video bios. Below is the error message when I try to start X when its using the VESA BIOS. Any help would be appreciated. Your BIOS doesn't support the VESA Standard appearantly. This triggers a bunch of bugs in the driver. I've looked over it and fixed them. Unfortunately I cannot send you my precompiled driver as it is build with the CVS head and won't run on your box any more. If you don't need BIOS support I'd suggest to leave it off to get around these problems. But thanks for reporting the problem, though. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SM 710 VESA BIOS
David W. Chapman Jr. writes: So the next release of XFree86 will fix these problems or will it automatically disable the BIOS for this card? No, it will use the BIOS but not the VESA extensions. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]The S3 driver doesn't work in multi card mode
Rutka patrick writes: Xperts, When i try to start my s3 trio 64 and geforce MX (the first version) together (not xinerama but in multicard mode) the screen wich is attached with my S3 is black (the boot is made correctly, but after is black screen). I try the NV/NVIDIA driver it's the same . With the vesa driver for the s3 and (NV/NVIDIA) for my geforce the result is useful. Only the S3 doesn't work on my computer in multi card mode, Why ? This is a known problem. The S3 driver doesn't do resource registration right nor does it set up the RAC flags correctly. I have a fix for this which I will check in one of these days. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Endless loop in pciSetBusAccess
Dr Andrew C Aitchison writes: I've just been looking at a colleague's Dell Latitude C610, using a Radeon Mobility 6 LY. With Friday's CVS built X got stuck with a blank screen during startup, hogging the CPU. I tracked the problem down to pciSetBusAccess, where it got stuck in a loop. This patch allows the server to detect and abort the loop, allowing the server to start, although switching back to the console shows corrupt text fonts (I see other reports of console problems with this chip, so that may or may not be related). I've attached the lspci -nv output in case that contributed to the confusing pci information. The two devices 2:1:0 and 2:1:1 seem to be cardbus bridges with improperly configured secondary bus numbers. I have seen this problem before. I will have a look how we can fix this. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident bug
kiss the sun and walk on air writes: Thanks for trying :) Perhaps we can try pushing the value beyond the spec? Or is there possibly something in the modeline that could be tweaked? Well I found a bug in my code - however this shouldn't have affected the -2 case. No, unfortunately one cannot extend the range as the adjacent bits all have a meaning. I'm just trying to help brainstorm. Before I installed linux on this machine windows 2000 had a perfect 1400x1050 display, so its possible, somehow. Yes, definitely. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident bug
kiss the sun and walk on air writes: Agreed. A positive value exacerbates the the problem. The ability to go farther in the negative direction is needed to find the best value. OK. Well like I've said already. I added this using some older manuals taking some educated guesses. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident bug
Alan Hourihane writes: Just checked, and it's still the same for the XP series. Well, then I'm out of ideas. I'd need a box with a 1400 wide display for testing. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident bug
Norman Walsh writes: / Alan Hourihane [EMAIL PROTECTED] was heard to say: | That driver is up now. Please test it. Might one gently inquire if this version supports the manual override for that pixel-shift bug? It is not a bug. Or at least not in the driver. It is the BIOS that's doing things wrong. Yes, the option is in there, now. It is called FpDelay and can have the range -2 to 5. Please let us know which values work for you best. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Xpert digest, Vol 1 #1930 - 2 msgs
Olivier Fourdan writes: Sorry, but... Nope, it's worst. Is it purely Xvideo stuff that's broken now ? Yes, the rest is fine as far as I can tell. I obviously cannot take a snapshot of what I get (because all I get on the screenshot is the chromakey). I may try taking a picture with my digital camera if you want. I was hoping to fix your problem. Now it got worse. I don't see anything in the changed code that would make it worse for you. Could you please try if you get the same problem if you play a video that is less than 384 pixels wide? Unfortunately I introduced a bug there. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident bug
Norman Walsh writes: -2 works best, but it's not enough. If those are pixel values, I think something like -12 would work better. According to my trident data books - which aren't on CyberBlades XP, Ai etc - the range goes from -2 to 5. Maybe that's different on the newer chips. Alan, do you have more informations on that? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]LocalClient extensions vs. ssh
Joe Krahn writes: Aside from LocalClient returning false, DGA requests should fail, right? LocalClient() returns TRUE therefore DGA doesn't fail. Trying GL over the tunnel correctly gives an error message and reverts to indirect rendering. That's different. With direct rendering the client library connects directly to the hw. It does not rely on the sever to fail. I don't know much about DGA, but my understanding is that it has a lot of issues because it is sort of a big hack (but useful), and the real solution is to replace it with real protocols like XVideo and a similar capture extension. This is not limited to DGA. Other extensions that depend on being run locally have the same problem if they rely on the sever's LocalClient() implementation. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]DGA keyboard state vs. Xkb
There is a long standing issue with DGA and xkb: When handling the keyboard from inside DGA it tries to keep the core keyboard state in sync. This is sufficient if no xkb extension is active. If the xkb extension is active however its internal state can get out of sync with unpredictable results if the core state has changed between start and exit of DGA mode. I worked around this by simply not updating the core state while inside of DGA if the xkb extension is active. Is there any deeper reason why DGA keeps the core keyboard state up to date or is this rather cosmetic? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]LocalClient extensions vs. ssh
When running X request thru a ssh tunnel LocalClient() returns true as the sshd connects to the Xserver from the same machine. This leads to unpredictable results and even system crashes if an application that can only run locally is started on a remote system. If for example an application wants to address the framebuffer directly thru DGA it will try to map the framebuffer on the machine it is started on not the one where the Xserver lives on. Even though this requires root privileges I do consider this to be a problem that should be adressed. Any ideas? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]NumLock config option
In version 3 we used to have a config option to turn on numLock on server startup. This option still exists but only produces a warning that it is obsolete. Was this option sacrificed because it didn't mix well with the xkb extension or is there now a better way to turn on numLock at startup time (other than running a client from one of the startup scripts of course)? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CT 69030 locks ups w/ XFree86 4.2.0 w/ RH 7.3
Clark Manuel writes: I'm seeing a specific lock up issue shortly after running startx with a PIII based system using the CT 69030 video controller. From scanning the prior XFree archives, this does not appear to be a new issue, but I see no reference to anyone seeing these issues with the 4.2.x release (only 4.0.x). I can avoid the lock up's by setting the option 'noaccel' but this GREATLY affects the video performance (it's unacceptable to say the least). I gather that I may be looking for a solution in the wrong place and if anyone can point me in the correct direction, I'd be most appreciative. Thanks in advance for any guidance. Do to a little bug in 4.2.0 silken mouse cannot be disabled. The lockup occurs when the hw cursor gets updated while the blitter is waiting for data. You may use Option noaccel to work around this. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XIE and PEX5?
Mike A. Harris writes: Both XIE and PEX are obsolete, and XFree86 now disables them by default. If you need either extension, or their libraries, you need to edit host.def et al. and manually re-enable them. The only problem that we've had reported to us here at Red Hat so far due to XFree86 disabling these two items, has been an older version of Mozilla needing XIE. Any mozilla from the last year or so, no longer requires XIE. As far as I know Mozilla never called any XIE functions even in the older versions. The libXIE was just included in the list of libs to link against. It could be removed. Appearantly noone uses XIE at the moment. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident CyberbladeXP @ 1400x1050
kiss the sun and walk on air writes: On Tue, Jun 04, 2002 at 12:33:54PM -0700, Paul Chris Sri wrote: Sorry, I haven't heard anything either. I'm also using a Tecra 8200 running RedHat 7.2 with X 4.2.0 with the same pixel shift issue. Last word from Egbert Eich was that it would be fixed if there were enough people experiencing problems http://www.xfree86.org/pipermail/xpert/2002-April/016658.html -pete (Also with a Tecra 8200 and the issue :) Can't you guys be a little more patient? I have made a fix where you can set the shift as an option by hand. You can then email me the range of values which works for you. I will collect the values take the one with the largest intersect and hard code it in the driver. This patch will be submitted once I find time. It won't happen this week for sure. I'm on a large show doing a XFree86 booth. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X server/PC Card conflict?
Paul Vojta writes: Folks: I've been experiencing the following problem when using recent versions of the X server while also connecting to a network via a PC Card NIC. The X server itself runs correctly, but after shutdown it seems to hang the console driver until I eject the PC Card (PCMCIA). A typical sequence of events is: 1. I insert the card and connect to the network 2. I start up the X server using startx 3. I use the X server for a while. 4. I shut down the X server 5. Shutdown appears to be normal. However, either immediately or soon after shutdown, the kernel's keyboard or console driver hangs until I eject the PC Card. Sometimes I get a few seconds of normal behavior before the problem occurs; for example, sometimes I succeed in logging out before things act up. 6. I eject the PC Card. Often I get the message: eth0: interrupts dropped! 7. Some of my keystrokes then appear on the screen (and get acted on); things go normally from then on. I think that it's the console driver rather than the keyboard driver, because if I type date while things appear to be hung, it prints an older time after I eject the PC Card. Thanks for pointing that out. A recent patch I've made introduces a bug in the handling of PCCards. I have a fix for it already which will be comitted soon. Please not that the current CVS head is a developers version. It may not be considered stable enough for your daily work. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]chips_drv problem
[EMAIL PROTECTED] writes: I have a problem with a Digital HiNote Ultra II notebook internal trackball mouse running RedHat 7.2 (chips_drv.o driver CT 65548 Video). If I use the internal trackball X freezes, at this stage the machine continues running, if I ssh into the machine and send a SIGUSR1 to the X process xdm dies and starts back up again. However if I plug in a serial or PS/2 mouse everything works correctly. Has anybody seen this before / know of a fix. I believe there is a problem with the video driver, due to the fact that I have tried this on a Toshiba Sattelite Pro 410CDT (same CT 65548) video card and the same thing happens. Your assumption is wrong: as you said yourself everything works well with an external mouse. This strongly suggests that there is a problem with mouse handling. I've seen several reports however I have not been able to reproduce this problem muself yet. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]horizontal rain on CyberBladeXP/DSTN/Ai1, latest CVS 'trident' driver
Matt Behrens writes: I've been getting horizontal rain on my CyberBladeXP/DSTN/Ai1 ever since the unaccelerated driver first worked. It is very noticeable when using Xv (the color key will rain all around the window), and also much more noticeable when accelerated things are happening such as an xterm updating very rapidly. It's not quite so noticeable when running unaccelerated. It's also much more visible on a CRT than on the LCD. Any suggestions? I've got a Satellite 1805-S254. I'm currently using the CVS driver copied into and compiled inside a 4.2.0 source tree, but this happens even with a complete CVS build. This sometimes happens when using 24bpp. I made a fix for it. The fix should be in the current CVS head. If nothing helps try to increase the memory clock, reduce the pixel clock and the color depth. If this still doesn't help - well, Trident chips are always a gamble. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 version 4.2.0 and SiS 6326 compatibility: asking again
Dick Lewis writes: NOTE: THIS IS MY SECOND ATTEMPT TO POST THIS MESSAGE (THE PREVIOUS BEING APR. 5) AM I DOING SOMETHING WRONG HERE? OR JUST BEING IMPATIENT? Note: writing in all capital letters means yelling. Yelling is considered impolite. I've been successfully using an older XFree86 version (3.3.6) with an SiS 6326 video card (on Mandrake 8.0). Recently I downloaded and installed XFree86 4.2.0. Running XFree86 -configure produced verbose error messages; startx worked (after a fashion) but I couldn't get KDE to run. If you care for an answer you ought to be more precise. Maybe noone has understood your explanation, therefore you did not receive an answer. If you got startx to work X may not be the one to blame. Does XFree 4.2.0 require a *new* driver specifically for this card? If so, How can I obtain that driver? If it's in one of the tarballs I downloaded, how do I install it? The driver is part of the XFree86 4.2.0 package. Beyond that, what light can anyone shed on getting KDE (or icewm) to run with XFree 4.2.0? This is the wrong list. You ought to ask the KDE folks or Mandrake support. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Trident CyberbladeXP @ 1400x1050
Excellent! Thanks! I just tried it on my laptop (toshiba tecra 8200) with a 1400x1050 screen, and the display is shifted by 5 pixels or so to the left. ie the first 5 columns of pixels that should appear at the left of the screen appear at the far right hand side. This is using the binary you provided. We could probably do something about this. However I would like to conduct a poll: Could anyone who is using 1400x1050 please drop me a note telling: a. What exact model of machine you have. b. If you see this shift problem. Should it appear that all of you have this problem I will hardcode the fix in the driver. Thanks, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]siliconmotion driver changes and questions
lurwas writes: Did you driver changes get into the official XFfree86 tree? Did you manage to get full playback rate, when watching DVD's and/or DivX? Cheers, Richard On Wed, 2001-11-14 at 17:45, Corvin Zahn wrote: Hi, back again, and a huge posting: After a long and fruitless conversation with the people at silicon motion I decided to look for the bugs and needed extensions myself. I've committed all the changes Corvin emailed me prior to the release of 4.2. These changes all went into 4.2.0. Corvin hasn't sent any patches since. Yesterday I committed some fixes for the SMI driver. Among other things I eliminated the wait for retrace between video frames. Therefore the video should play faster now. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]getting X to work on a toshiba satellite 210cs
The ct65550 does have a very low pixel clock limit. It's possible to exceed this limit using hand selected clock values - but we don't do this in the driver. You need to make your own modeline for 800x600 using a pixel clock not exceeding the 35 MHz. You can use 35.00 800 840 968 1056 600 601 605 628 which is the 60Hz modeline with a lower pixel clock. Egbert. Frank Van Damme writes: Hello list I am trying to get a friends toshiba satellite 210CS (which is a pentium 120/48 ram aamof) to work with linux. I installed debian gnu/linux on it and I am trying to get X to work. The graphics card seems to be a chips and technologies ct65550, the lcd monitor should be able to do 800*600. I tried both X version 4 (xfree server) and the svga server from 3.3.6 at no avail. The error I get with the svga server is: SVGA: clock for mode 800*600 is too high for the configured hardware. Limit is 35.464 MHz fatal server error: no valid modes found. I am using this config file: http://www.die-kettners.de/linux/xf86-1.htm For X 4, I assembled my own config file which only works in a 640x480 resolution. The config file is below, as well as the server output. I hope someone can help me out on this. CONFIG Section ServerLayout Identifier Default Layout Screen Default Screen 0 0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse InputDeviceGeneric Mouse EndSection Section Files FontPath unix/:7100 FontPath /usr/lib/X11/fonts/misc FontPath /usr/lib/X11/fonts/cyrillic FontPath /usr/lib/X11/fonts/100dpi/:unscaled FontPath /usr/lib/X11/fonts/75dpi/:unscaled FontPath /usr/lib/X11/fonts/Type1 FontPath /usr/lib/X11/fonts/Speedo FontPath /usr/lib/X11/fonts/100dpi FontPath /usr/lib/X11/fonts/75dpi EndSection Section Module Load GLcore Load bitmap Load dbe Load ddc Load dri Load extmod Load freetype Load glx Load int10 Load pex5 Load record Load speedo Load type1 Load vbe Load xie EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc101 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/psaux Option Protocol PS/2 Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEvents true Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Monitor Identifier Generic Monitor HorizSync31.5 - 58.5 VertRefresh 50.0 - 90.0 Option DPMS EndSection Section Device Identifier Generic Video Card Driver chips ChipSet ct65550 CardChips Technologies CT65550 EndSection Section Screen Identifier Default Screen Device Generic Video Card MonitorGeneric Monitor DefaultDepth 16 SubSection Display Depth 1 Modes1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section DRI Mode 0666 EndSection ERRORS: This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 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
Re: [Xpert]Asus portable with Silicon Motion Lynx 3DM
Mark Vojkovich writes: On Sun, 31 Mar 2002, Vladimir Dergachev wrote: Egbert, if you can program the registers outside of the retrace without hardware gliches, I think you should just do that. Polling for the retrace in the server should not be done for stuff like this. These apps are typically cpu intensive so they are competing with the server for CPU. That means the server might not even be scheduled during the retrace a good deal of the time. I suspect the server spends its entire slice spinning most of the time. Right, I didn't program this. I don't like to put any of this busy waiting into drivers if I can help it. Especially during DVD playback this will waste so much CPU time. This will certainly not increase quality of the playback. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: signal 4 kills X
Vladimir Dergachev writes: Are you sure that is the correct log ? First of all XFree86 version is 4.1.0.1 - way old. Secondly, it says right there: VESA(0) Initializing int10. I cannot fetch the log until Tuesday. Therefore I would have preferred to have it as email. Does it say anything about unresolved symbols? Where does it crash exactly? Does somebody care to send me the lines just before the crash? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]8-bit pseudocolor overlays
Dr Andrew C Aitchison writes: Option Overlay is sufficient on my Millennium and my G550, OK, I've checked the code, looks like you are right. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Asus portable with Silicon Motion Lynx 3DM
Mark Vojkovich writes: Looking at the code for the siliconmotion driver in the tree, I'm not surprised. It looks like the driver is polling until the retrace everytime it has to put a frame. I would expect that to eat up more CPU than just doing all the video in software. You should probably try it without Xv, if that's being used now. Or somebody should fix the drivers. OK, I will look into this next week. I guess this retrace waiting was done to prevent shearing. Only very few chipsets support some kind of double buffering with automatic buffer switching on retrace. On all others we need to poll the chip to detect a retrace. Mark, do you have any new idea how to solve this problem? I guess a solution would be to have some limited kernel support to handle interrupts. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: signal 4 kills X
Mark Vojkovich writes: On Sun, 31 Mar 2002, martin f krafft wrote: also sprach Mark Vojkovich [EMAIL PROTECTED] [2002.03.31.0336 +0200]: You have to turn them on in your shell. That's the limit coredumpsize in tcsh. I think it was ulimit -c in bash. See your shell's man page. i set ulimit -c 1048576 (1Gb) and reproduced the error, but there was no core file generated... probably because the binaries i am using don't include debugging symbols. correct? You should still get a core. How useful the core would be would depend how many symbols were present. The core may not be useful at all if it crashed in a module. It would probably be better to pick up the module aware gdb and run X inside this module. But maybe we should wait a while until the debian XFree8 4.2 update comes out (Brandon?). Martin has emailed the logfile so I was able to take a look at it. As it looks like it happened while the server had been running for a while already. There was absolutely no indication of an unresolved symbol. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]8-bit pseudocolor overlays
Dr Andrew C Aitchison writes: Once you get the card installed, run X -configure this will give you a sample config file (which may need tweaking, especially for mouse support). In the Device section there will be a line #Option Overlay remove the # to enable the feature. Err, you need to have a line Option Overlay 8,24 or Option Overlay 24,8 to enable this feature. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: signal 4 kills X
Mark Vojkovich writes: That still doesn't explain why it crashes. Did you run gdb on the core dump to get a backtrace? At this point we don't even know where it's crashing at. All we know is that the server tried to execute non-executable code. It is not unlikely that there is a symbol missing. We should examine the logfile before we go deeper. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident 1400 display accelerated ?
Alan Hourihane writes: Work has been busy, and I've just not had time to clean up the code and commit it. Hopefully with easter weekend coming I'll be able to soon. Same with me. I have everything perpared for the merge but I am quite busy at the moment. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Trident CyberbladeXP @ 1400x1050
I've added preliminary support for the 1400x1050. I'll probably commit my code next week. I had it tested by someone and it seems to work basically. Unfortunately the display seems to be shifted by a few pixels. I will only be able to address this if I have actually access to a system. Regards, Egbert. Paul Chris Sri writes: Hi Alan, Egbert, and all, Just wanted to thank Alan for that new accelerated Trident driver. It is working quite smoothly :) Thanks! And since I'm not sure who to ask about this topic, I'll just throw my question out there. I was wondering about the status of adding the 1400x1050 modeline(s) support for the Trident CyberbladeXP. I've currently got 1280x1024 accelerated thanks to Alan on my Toshiba Tecra 8200 - Trident CyberbladeXP w/16MB RAM on XFree86 4.2.0 RedHat Linux 7.2. If there is anything I can do to help like testing, etc. please let me know. Thanks Much, Paul __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident 9397 on an IBM Thinkpad
Mike Trettel writes: Hello all, I'm experiencing the distorted color problem on a TP770 with the Trident Cyberblade 9397 chipset. I've patched around the problem by using the suggestion made by Alan Hourihane to comment out the XvExtension in the trident_driver.c file, rebuilding the module, and substituting it for the original. It now works fine, but I'm willing to help out in tracking this bug down completely. Meanwhile we were able to pin this down to the SetGamma() function. But even with SetGamma() commented out it has been reported that attempting to play a video would crash the chip hard. We have no idea yet, why this happens. If you want you may help us to track this down. Please take a look at the chipsets video setup which happens in TRIDENTDisplayVideo(). By commenting out some of the code there you may be able to pin this down some more. The video won't display properly any more but first we need to know why it crashes before we can fix it. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CyberBladeXP Driver
Vincent Meyer, MD writes: Hi folks - Just tested Alan's new driver with a Trident 9397DVD in a Gateway laptop - it still does the funky color / texture thing with this driver. Hi Vincent, surprise, surprise. If noone helps us to find the cause the problem won't go away. It is quite unlikely that it just gets fixed by accident. If you have been watching this list you may have noticed that I posted a call for help just yesterday. You were one of the guys who wanted to help me on this. I'm still waiting for your reply. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [XFree86-4.2.0 + i810] crashes with KDE-3.0 beta2
Hi Andris, Thank you for your quick response! Andris Pavenis writes: Tried (started startx locally and attached to X from remote SSH session). Recompiled dispatch.c with debug info, but there were litle use of it as I anyway don't know where pGC-ops-CopyArea points to. Yes, this is the question. I'm not aquainted enough with xaa to to know this. Do you mind to do the test again using a special version of gdb which you can find at: www.dawa.demon.co.uk/xfree-gdb ? If you can't find it there I can email it to you too, if you don't mind huge emails. In order to get these symbols resolved you need start X inside of gdb. Here is what you can do: 1. Put the new gdb in /tmp. 2. Log in from remote, start X inside gdb: /tmp/gdb X 3. start a second remote session, set DISPLAY variable, start an xterm and kde: export DISPLAY=:0; xterm kde (you need the xterm otherwise kde does several server resets) Now you can set the breakpoint and proceed as before. #0 0x080ad223 in xf86Break1 () #1 0x08724bfc in ?? () #2 0x08726aab in ?? () ^^ I need to know this symbol. #1 is I810Sync(). #3 0x080b725f in ProcCopyArea (client=0x8add900) at dispatch.c:1756 Thanks again! Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]S3 ProSavageDDR
Thomas Winischhofer writes: The SiS632_6_ is supported by the SiS driver in 4.2. However, I could not test this. (So I leave this question to you, Egbert!) Last time I checked the 6326 workd well - at least for me. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident CyberBlade driver
Olivier Fourdan writes: There are a couple of issues that remain with this driver on the CyberBladeXPAi1 card, AKA Cyber-Aladdin-T from ALi (1644 northbridge) Hm, you should have spoken up earlier. Now I have returned my test system to Toshiba. On the other hand I didn't se any problems any more when I tested the most recent version of the code. 1) Screen position : On the laptop LCD, the screen is shifted 5 pixels to the right. In other words, there is a 5 black pixels area on the left of the screen and 5 pixels are missing on the right side. This one may be hard to fix without a system to test with. In 24bpp, there are some artifacts left on the screen when moving windows (opaque move). This doesn't show in 16bpp. Can you send a screenshot of an area where you see these artefacts? 2) XVideo problems : There is a line, all screen wide, appearing on top of the XVideo window. This show both in full screen and window playback. In window playback, the line moves along with the top of the window. Again it would be intereseting if this line is visible in a screenshot. More annoying, when using Xine as the video player, when returning from full screen playback, the whole coputer crashes and the LCD turns slowly to white, reminding me of a polarization problem (I guess this is somehow dangerous for the LCD). As far as I can tell, this doesn't show with MPlayer. However, I've been using Xine with other XFree drivers (NVidia) and got no problem. It is possible that Xine uses DGA for fill screen video. Otherwise I don't understand why this can happen. Can you check if this is true? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [XFree86-4.2.0 + i810] crashes with KDE-3.0 beta2
Hi Andris,
Andris Pavenis writes:
On Wednesday 06 February 2002 11:25, Andris Pavenis wrote:
I can reliably crash XFree86-4.2.0 on Pentium III machine with i810
integrated video when KDE-3.0 beta2 (built from CVS) is installed:
KDE-3.0-rc1 now crashes XFree86 on VT switching ALWAYS (for me)
with XFree86-4.2
I810Sync() is called when switched away from X11 (I810LeaveVT() called before
that). It doesn't seem to happen if I'm using Gnome-1.4 and happened much
more seldom with KDE-2.2.2. Tried to add some protection against this (see
patch). It is rather ugly workaround, but it seems to avoid XFree86 lockup at
least in 24bpp mode (without disabling hardware acceleration).
Unfortunately your fix is not targeting the real problem.
We should look further to see why I810Sync() gets called
when X is switched away.
Can you please find out from where I810Sync() is called?
If you don't have the module aware version of dgb you
can do the following:
1. add a call to xf86Break1() to I810Sync() (you can put it
inside the if (I810_in_vt==0) { .. } so it gets only called
at the right place),
2. recompile the driver,
3. log in from remote, start X in gdb, then start KDE.
4. Before you switch consoles you add a breakpoint to
xf86Break1(), then switch consoles. Once you
hit the breakpoint you create a backtrace.
Thanks,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ct65555 and XVideo
Andrei Lahun writes: Hello . Firstly thank you for fixing bug with ct driver , now driver working without modification of source code. But i found that time to time when i whatch video with mplayer/xine and Xvideo, during startup of player CT driver froze Xserver. I looked at diff between 4.1.0 and 4.2.0 and found at least a way to get rid of these problems: + Bool doubleBuffer; + Bool manualDoubleBuffer; + int currentBuffer; } CHIPSPortPrivRec, *CHIPSPortPrivPtr; And doubleBuffer set to TRUE. When i set it to FALSE no more problems with Xvideo and i donot see any performance decrease. Could you please find out where it is hanging in double buffer mode? You need to log in remotely and start X in gdb. You need a special version of gdb which you can find at: www.dawa.demon.co.uk/xfree-gdb Also Xvideo works only in 24 bits , in 16 just mess. Please could someone fix this in CVS or at least answer at this mail. If you know how. We don't. I have spent several days on this without finding a way to fix it. (I am not subscribed to mailing list) regards Andrei Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident 9397DVD on Gateway Solo 9100
Vincent Meyer, MD writes: Hello, Any progress on the driver for the Trident chip in Gateway laptops? I saw some posts where it looked like the cause of the problem was pinpointed, but haven't seen anything in the changelogs. It does work with the 4.1.0 driver to some degree with the 4.2.0 server and related files. What was the problem on yours. Wrong colors? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Various SiS driver items
So it seems some change to the accel code that occured between 4.1.0 and 4.2.0 is overwriting the hardware mouse cursor image in video memory. That's my best guess anyway. Any comments from someone who has worked on the code previously would be greatly appreciated. Look at sis530_accel.c, locate the line: topFB = (pSiS-maxxfbmem = pSiS-FbMapSize - offset) ? change the = to (--) SIS(0): Unofficial driver (16.01.02) by Thomas Winischhofer When looking at the source code for the driver I see: /* TW: ---EGBERT: Remove this before committing !*/ xf86DrvMsg(pScrn-scrnIndex, X_PROBED, Unofficial driver (16.01.02) by Thomas Winischhofer\n); So those lines should probably be removed from sis_driver.c and committed to xf-4_2-branch and head also. Might even be a good idea to have Thomas just not include such string at all. If the purpose is to distinguish between official XFree86 driver releases and non official, it isn't doing well. ;o) Indeed I didn't notice this line in the rush to get this driver out. This can happen - can't it? Another minor issue: With swcursor enabled, and the problem gone, the output of the X server shows: (==) SIS(0): Silken mouse enabled (II) SIS(0): direct rendering disabled (WW) SIS(0): Option swsursor is not used (II) Setting vga for screen 0. (II) Initializing built-in extension MIT-SHM So it says swcursor is used, then later that it isn't used. I couldn't find anywhere in the entire source tree under Xserver with a quick grep that displays the string with the warning, or anything close to it, which was odd. I presume whatever it is, it builds up the string. I looked in the code and found the logic that looks for HWcursoe/SWcursor options is setting HWcursor variable internally and not the swcursor variable. My guess without further examination, is that the driver is only setting the HWcursor variable, and leaving SWcursor variable uninitialized, so when it later prints the various options that are unset - swcursor shows as unset. A patch is attached which attempts to fix that minor issue, but is untested. There is a very simple answer: The driver doesn't know an option swsursor only swcursor. === Another thing I noticed is: (--) SIS(0): Video BIOS version ËVer 1 detected This is a string returned by the BIOS. As this part of the code works well for almost everybody else I suspect that the driver doesn't stick to the VESA conventions. If anybody feels bothered he/she should complain to the BIOS Vendor. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident Cyber 9397 with Xfree86 4.2
Robert hedges writes: This doesn't seem to be it either, this also returned it to the origianl psychedelic behaviour. Robert Hi Robert, I assume the origin of the problem is somewhere in ResetVideo. Can you comment out the entire code in this function and see if this is true? If so please try to narrow it down. During these tests video playback probably won't work. But let us try to get the rest of the chip working first. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident Cyber 9397 with Xfree86 4.2
Robert hedges writes: Apparently, I had not, I must have only restarted X, because things seem to be working fine now. Thanks. I think video has been around in the older driver versions which used to work for you. It is possible that the gamma, contrast, brighness, hue or saturation controls which were implemented later caused your problems. Could you please comment out the lines: tridentSetVideoGamma(pTrident,pPriv-Gamma,pPriv-Brightness); tridentSetVideoContrast(pTrident,pPriv-Contrast); tridentSetVideoParameters(pTrident,pPriv-Brightness,pPriv-Saturation, pPriv-HUE); in TRIDENTResetVideo() and see if the problem goes away, too? Thanks, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]issues with S3 Savage and monitor timings
Curtis, it would be helpful if you send us a log. This gives informations about the modes rejected by the server (and the reason why it was rejected), the modes that actually were set etc. Egbert. Curtis Yarvin writes: I'm having two major problems with a Savage4 Pro+ under Linux x86 2.4.16, XFree86 4.1: (1) About half the time, randomly, the machine crashes when I exit X. Screen is dead, processor halted. (2) XFree86 seems to have a very coarse-grained set of display resolutions it can switch between. Titrating H and V frequencies in XF86Config-4 one by one, at a certain cutoff it seems to switch from 1600x1200 at 60Hz to 1600x1200 at 74Hz. The problem: my monitor (Philips 107P) can only do 1600x1200 at 72Hz. Furthermore, the cutoff point seems to be wrong: eg, when I set the configured values to 90K, 72V, my monitor tells me the out of range signal is 93K, 75V! I feel somehow betrayed. I imagine (1) is a driver issue. I have the latest driver, so, whatever. I thank God - or Stephen Tweedie anyway - for ext3fs :-) But, (2). Is this - a card/driver issue? An XF86 issue? Or even somehow a monitor issue? Your help will receieve no reward but my thanks, but is anticipated in advance :-) Curtis [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing, with regard to viewing DVDs (Trident Ai1)
D. Harley Klein writes: Egbert, If this is a driver issue, is it going to be addressed in the coming CVS updates and/or 4.2 Xfree86 release(s)? I usually fix problems I can reproduce. I don't have any DVD's just a few mpegs I use for testing video. I have never seen tearing and therefore I cannot do much about it. Egbert. On Tue, 18 Dec 2001, Mark Vojkovich wrote: On Tue, 18 Dec 2001, Harley Klein wrote: If my guess is correct with regard to what tearing might be, I see tearing when viewing DVDs with the latest ogle release. I'm using the latest CVS release on my Toshiba Satellite 1805-S204. It has the Trident CyberBlade Ai1 chipset. Is the apparent tearing an issue with the driver in the CVS release or possibly the software? Although this isn't in response to the SiS630 driver, I thought it was a relevant question. It's usually a driver issue. Mark. Thanks, Harley ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Abridged: Total frustration with XFree86 4.1.0!
Mac Cody writes: I'm afraid that is what I may have to do. In fact I'm already preparing to do so (pulling the necessary .tgz files off the Slackware 7.1 CDROM). Tis a pity. XFree86 4.1.0 appears to be faster on my cards than 3.3.6. Hi Mac, the Slacware 7.1 CD should also contain the 3.3.6 sources. It shouldn't be too difficult to just implement interlace support. Why don't you check in the 3.3 code how it is done and add this feature to 4.x? Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Stupid defines?
Several X headers (Xlib.h!) contain the following defines: #define Boolint #define Status int Does anybody see any side effects if we change this to a typedef? This would avoid unpleasant surprises for programmers. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS630 LCD - again (success)
Thomas Winischhofer writes: Just finished compiling CVS version from today (12/12) and ... SiS driver actually WORKS on my laptop (Gericom). No more melting screen! I could not perform intensive testing yet, but at the moment I am running X using the CVS driver without any distortion. Even the rectangle-bug I reported yesterday has disappeared. Thanks Egbert! Well, I'm happy that I made at least some people happy! However, X locks up (freezes) the machine about every third time I am running startx; the screen remains black and I have to power the box down. The times it comes up, it works well. I am not sure about the reason for this but I suppose it's not the sis driver that causes trouble here. The log does not contain anyhing useful. Please try logging in remotely and start X from there. You may also try the new server flag option SyncLog. It fsyncs after every line writtten to the logfile. You may still not be in sync when the box freezes hard. I would like to know were it stopped. Egbert. ___ 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]sis-630/lcd with newest xfree cvs
Andre Werthmann writes: With the old version of the driver the LCD wasn't initialized (it slowly has gone white). I have connected a Monitor to vga out and everything displayed ok there. OK. What happens if you run VESA framebuffer and start the Xserver with SiS driver on top? Please try a mode that has the same resolution and depth as the mode in X. I have not tried 8bpp yet, I'll do soon. OK. Could you please get the exact message (or the log file)? I have written a log file, but at my fault I deleted it while deleting the xc source. I'll compile it again and send you the logfile. OK, thanks! Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS630 and LCD
Rene Rebe writes: For the newer sis chips / bios version we had to disable the mode-switching and let the VESA-framebuffer initialize the chip. - I spend many hours debugging in the stupid sis_bios.[h,c] ... , too. I have a short info page: http://www.tfh-berlin.de/~s712059/sis630/index.html 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. 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. I tryed to get docu from sis - even considering signing a NDA - but suddely the email thread with them stopped ... ? - They so not seem to be interessted in getting they 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. Egbert. -- Egbert Eich XFree86 Core Team SuSE GmbH [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident cyberbladeXPAi1
You are the second one within two days who has problems with this chipset. It is a brand new chipset and support for this has just been added. I am sure that noone of the developers has seen a CyberBladeXPAi1, yet. I don't know if anyone has documentation for this chip yet. The situation may be just as it is for the CyberBladeXPm8/16 chipsets: Trident doesn't allow us to release source code. People should understand: 1. In the eyes of chipset vendors Linux is *not* mainstream. Some (not all!) of them don't consider the extra revenue they can make by providing support to OpenSource projects like XFree86 worth the efford. (And they make revenue despite the fact that they don't support Linux as this case shows us!) 2. Toshiba doesn't consider Linux mainstream enough to bother to support it officially. There have been moves to do so in the past but I haven't heared of them for over two years now. Luckily some of the engineers at Toshiba don't think that way and have provided systems for testing in the past. 3. From 1 and 2 one can gather that hardware vendors don't throw at us any new system they put on the market and provide all documentation necessary to support the stuff begging us to add this support. It is vice versa: We still need to beg for documentation and may be a test system. 4. One should consider this when looking for a new system (especially a laptop): It may be a good idea to look around and see which HW is already known to be supported. Anybody buying the latest and greatest systems with chips that have just been released may have to expect unpleasant surprises. I had this surprise, too - many years ago. That's how I got onto this project. I will try and see if I can get a box like this from Toshiba. Egbert. gabriele castellini writes: Hi there, I have recently bought a Toshiba Satellite 1800-S204 laptop that comes with a `trident cyberbladeXPAi1' card. I installed RedHat 7.0 that came with XFree86-4.0.1 and it did not recognize the card. I upgraded to XFree86-4.1.0 but no improvement. Since I noticed that support for this card was added to the soon to be released XFree86-4.2.0, I downloaded the latest CVS from December 4 and the compiling and installation seemed to be all right. However, by running `XFree86 -configure' I could only get one mode and it is not usable, since I get a small frame in which I seem to recognize the default 'net-style' X background with a ghost-like mouse pointer. Nevertheless the card is correctly identified as one can see from the log-file included below. Does anybody have any idea of what went wrong? Did I make some mistake somewhere or is there any setting that I could change in order to get a usable picture? Hopefully the included log-file may help those who know more about this to understand what is going on. By the way, one more thing, `startx' quit working after installation of the new CVS. After typing it I get the following error message: xauth: error while loading shared libraries: LibXmuu.so.1: cannot open shared object file: No such file or directory. I wonder what that means since the file LibXmuu.so.1 actually exists. Does anybody have any idea of how to fix this? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS630 and LCD
Rune writes: Hi, It's great it works for you!! Any chance you are interested in helping me find out what works, and what doesn't? Can you give me your setup? Mine that doesn't work: Laptop:Uniwill 340S2 resolution:1024x768 framebuffer: VESA modeline: 65.1 1024 1032 1176 1344 768 771 777 806 +hsync +vsync Please be a little more sepcific on what doesn't work means. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Fw: [Xpert]Egbert Eich did you fix alle the LCD problems in the SIS-630?
Rune writes: (sorry about the first post René) in the commit: http://www.xfree86.org/pipermail/cvs-commit/2001-November/003475.html: 536. SiS driver: - Added fix to restore fbdev mode properly on VT switch/exit. - Improved LCD handling on SiS 630. - fixed screen blanking in SiS driver to properly blank LCDs (Egbert Eich). Improved, but by how much? Rune Petersen I don't know myself. It worked on the box I had for testing. It didn't work before. So give it a try. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Multi-head displays - why so difficult?
Sprague, IT3 writes: Certain cards seem to butt heads (Different ATi chipsets especially. Rage ^^ please translate 128's and Radeons hate each other.), and DRI/OpenGL is unreasonably twitchy in multihead setups. To be helpful your reports ought to be more specific. It is possible that DRI and multihead don't work together well for all cards. These issues should be addressed although I expect that this will take time due to the lack of manpower. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Video output on a Trident CyberbladeAi1d
Wischnowsky, Sven writes: Hello With the CVS-development version on a Trident CyberbladeAi1d (in a Acer Travelmate 354e laptop) I'm having a small problem with displaying videos. I've read through the mailing list archive and now got it almost working but not fully. And I had to make some changes to the code in trident_video.c, namely: - changing line 95 to: if (pTrident-Chipset = CYBERBLADEAI1d) You should send a 'diff -u' output or at least a larger code segment as your line 95 may not be my line 95. (so that VID_OFF_SHIFT_4 gets not or'ed in) Yes, that's correct! I found that on a AI1 yesterday, too. - changing the lines 75[56] to: ty1 = dstBox-y1 + pTrident-vsync; ty2 = dstBox-y2 + pTrident-vsync; (i.e. removing the `- 2' and `+ 2') That latter change was wild guessing, obviously, but fixed the problem that I got a line at the bottom of the video output region containing garbled color pixels (looks like the stuff you get when putting an uninitialised pixmap on the screen, pretty randomly, although the pattern looks enough like the line above it to make me think that it's just the last video line displayed with the wrong color information). We cannot remove these as they may affect other chips. Try to find an optimal value for pTrident-vsync. (Please check trident_dac.c where it gets set.) But I also get such a row of garbled pixels on the right of the video region and I wasn't able to find a place where I can fix that. I've frobbed with the variables for the zoom factor and for the positions of the video region but without fixing the problem. You may want to check pTrident-hsync for this. I needed to do a pTrident-hsync -= 7; from the default value for the Ai1. But otherwise video with the current CVS version is working nicely, good work, guys. Thanks! Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident Chipsets Xv support
Chad Kitching writes: Another update on My Twinhead Powerslim 600 with the Cyber9525DVD: I changed the hsync hardcoded adjustment to 0 (it was initally 23) I left the vsync at -2. This will break it for others. We still don't know exactly how to calculate these values exactly. I've done some playing around with my laptop based on a Trident Cyber9525DVD, and I'm beginning to believe that the CRTC values can't be correct. In particular, the CRTC values change from what X sets when I press Fn-F5 to switch displays, and when I plug these values into the LCD[] array, the overlay becomes centered properly (without modifying the h/vsync). I haven't managed to get 640x480 (unstretched) to work with the overlay, since I can't get the trident driver to set the proper values (e.g. the values I set in the LCD array end up being different from what gets programmed into the VGA CRTC registers). The CRTC values I'm getting from my card when I switch video outputs is the same ones that are '#if 0'ed out above the current LCD[] array. The current code doesn't take the horizontal sync skew (CRTC[5]5:6) into account. This might have caused this problem. I fixed this. Now we may have to retune the video skews. I agree, hotkey display switching will most likely mess up the video offsets. The Xserver doesn't get notified when a switch happens therefore we cannot adapt our values. I don't like to read back the CRTC registers on every frame to see if they have changed. Maybe I can add some code to do this every 100 or so frames. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident Chipsets Xv support
Alan Hourihane writes: Egbert - I hope we really don't have to kludge around like this, but if we do, you can check the current video output mode in the BlockHandler and I just did. Had a brown paper bag ready - just in case. use a callback to update values. I did some code which does it every 100 frames. This seems to be very reasonable. But I'll play around a little bit more. BlockHandler is a nice idea, too. Cheers, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Trident Chipsets Xv support
Geoffrey Hausheer writes: On Mon, Sep 24, 2001 at 09:46:19PM +0100, Alan Hourihane wrote: Can I urge people with Trident chips (laptops especially) to get the latest CVS code to test Xv support and provide some feedback. Another update on My Twinhead Powerslim 600 with the Cyber9525DVD: I changed the hsync hardcoded adjustment to 0 (it was initally 23) I left the vsync at -2. This will break it for others. We still don't know exactly how to calculate these values exactly. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trident Cyberblade XP XV support
Im running a Toshiba Tecra 8200 laptop with a trident cyberblade xp gfx card. The card works in Xfree but lacks xv and dga. I saw that there were some unofficial patches and maybe some of them fixed the problem. Could anyone put them in cvs or tell me how to install them. Im running debian sid. I have a patch to get video working on XP but it only displays videos upside down so far :-(( Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
