Re: [Xpert] V_BIOS woes

[Egbert Eich]

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

Re: [Xpert]Why ps mouse hangs the kbd

[Egbert Eich]

P.R. Patil writes:
 > Dear All,
 >   If ps mouse is not connected to the pc then it hangs the kbd. 
 > Can any one solve the problem?Thanks and Regds,

This is not the fault of the Xserver.
It is partly the fault of the archaic
hardware design:
When you open the PS/2 mouse device
without a mouse being connected the
chipset will generate a fault data byte
after a long timeout period. Since
this data byte doesn't get serviced
(appearantly no interrupt is generated)
the keyboard/mouse controller doesn't 
generate any interrupt for any further 
events. If at all the kernel needs to
handle this. 
The funny thing is: if you access the
keyboard thru an ioctl (ie when terminating
X or by setting the keyboard rate) the
fault package is serviced and the keyboard
starts working again.
If at all this problem needs to be handled
in the kernel.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: -fPIC issue

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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
 

Re: [Xpert]xfree86 libint10 in non-x86 environments

[Egbert Eich]

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.

[Egbert Eich]

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]!! Correction for i810 driver !!

[Egbert Eich]

I think I finally found the time to look at this.
The diff below now makes sure we only touch the
OVRACT registers when the CRT timings are used
ie. if TV/LCD is off or bit 28 (use VGA Mode) is 1.

Please apply this to a version of the i810 driver
from CVS head and test it thoroughly.

Regards,
Egbert.


Sottek, Matthew J writes:
 > I'll try to summarize.
 > 
 > The OVRACT register controls how the overlay lines up with the TV/LCD
 > output.
 > This alignment needs to be calculated based on the horizontal timings being
 > used on the TV.
 > 
 > On an i810/i815 the video bios will program the timings for the TV
 > controller
 > if it is used as the primary output device. The CRT timings are then
 > centered
 > in the TV timings which allows XFree to display on the TV using one, fixed,
 > TV resolution that was chosen by the vbios.
 > 
 > Since this mechanism was designed for compatibility with VGA, DOS etc, the
 > vbios is not programming the OVRACT register... this register was being set
 > in Set Mode which made it work for at least one TV controller in at least
 > one mode.
 > 
 > If we base the OVRACT register programming on the sync timings set by the
 > vbios you can probably make it work for everyone.
 > 
 > If the TV is active:
 >Regs 0x6-0x60023 control the timings in use by the GMCH is bit 28
 > in lcdtv_c is 0 (This is usually the case). The CRTC timings are
 > centered in these values if bit 29 is 1 (usual case)
 >OVRACT needs to be programmed off the TV regs if they are in use.
 > If the TV is not active
 >CRTC regs control the timings
 >OVRACT needs to be programmed off the CRTC regs
 > 
 > For an LCD the vbios may or may not be using the LCD/TV timings depending
 > on the capabilities of the LCD device. I suggest checking bit 28 of
 > lcdtv_c to make sure that the TV regs are in use. The centering probably
 > doesn't matter because the end timings are still those in the TV regs.
 > 
 > At this point, if this works for both of you, I suggest committing it and
 > asking for lots of testing. You will have a lot of permutations of
 > LCD encoders, LCD displays, and TV encoders that may all behave
 > differently. Only widespread testing will indicate if it is an
 > improvement.
 > 
 > Egbert,
 >   Wherever you end up putting this you can probably replace any other
 > programming of OVRACT. Just make sure that if you switch away or change
 > modes for any reason that you read the timings again. A stand alone TV
 > driver could have changed them.
 > 
 > 
 >  -Matt
 > 
 > 
 > 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) &&
 > (~lcdtv_c & 0x2000) &&
 > (tv_htotal)) {
 >i810Reg->OverlayActiveStart = (temp>>16) - 31; 
 >i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
 >  } else {
 >i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
 >i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
 >  }
 > 
 > 
 > -Original Message-
 > From: Egbert Eich [mailto:eich@;XFree86.Org]
 > Sent: Wednesday, October 16, 2002 5:44 AM
 > To: [EMAIL PROTECTED]
 > Cc: Sebastien BASTARD
 > Subject: 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(0x600

Re: [Xpert]Patch for the Xlib i18n code

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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]!! Correction for i810 driver !!

[Egbert Eich]

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 = (temp>>16) - 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

[Egbert Eich]

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 !!

[Egbert Eich]

Sottek, Matthew J writes:
 > Actually...
 >   I am not sure that reg 0x6 will be set in all cases. I may only be
 > programmed if there is a TVout controller present in the system. Doing
 > it this way is safer. Maybe someone looking for a task can make a diff out
 > of this and submit it to the patches list?

I've checked with the docs and it looks like this patch may be 
correct. I'll test it in my i810 and submit it if I don't see
any side effects.

Thanks to both Sebastien and matt!

Regards,
Egbert.

 > 
 > -Matt
 > 
 > 
 > File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
 >   Somewhere near line 1522
 > 
 > 
 >   unsigned int temp=0;
 > 
 >/* OVRACT Register */
 >temp = INREG(0x6);
 >if(temp) {
 >  i810Reg->OverlayActiveStart = (temp>>16) - 31; 
 >  i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31; 
 >} else {
 >  i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32; 
 >  i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32; 
 >}
 > 
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]tdfx soft-boot hang revisited

[Egbert Eich]

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.)

[Egbert Eich]

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]Re: Using the "chips" XFree86 driver on a PowerBook3400 (almost there.)

[Egbert Eich]

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 C&T maintainer.

Regards,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: Using the "chips" XFree86 driver on a PowerBook 3400 (almostthere.)

[Egbert Eich]

Ani Joshi writes:
 > 
 > It seems you have changed the address space to use the big endian
 > aperture, this is correct.  As for the accel engine, try turning off all
 > acceleration (just #if them out in the driver, no need for several XaaNo*
 > Options), and leave on SolidFills, this is the easiset to debug.  There is
 > a problem with some 65550's and polling of the BR04 register which tends
 > to lockup the engine, you may be running into that.  I would grab the old
 > source from Xpmac (I believe it had c&t accel) and poke around there to
 > see where the engine is initialized and the proper way to BLTWAIT on this
 > chip, its been long since I hacked on the c&t65550 so I don't remember
 > sorry.

At least in the version 4.2 lockups  in the accel engine are caused by
an incorrect handling of silken mouse which cannot be used in
connection with C&T chips.
This problem is known and has been fixed in CVS. A simple workaround
would be to disable the HW cursor.

 > 
 > 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.
 > 
 > 
 > ani
 > 
 > On 8 Oct 2002, Michael Stephen Hanni wrote:
 > 
 > > Hi,
 > >
 > > Being of unsound mind and body I decided to see if the chips driver
 > > could be made to work on my PowerBook 3400. This model of powerbook
 > > includes the ct65550 chipset -- i.e. HiQV -- and has 1 meg of video ram.
 > > >From reading the documentation in the source tree it would appear that
 > > the "chips" driver fully supports this chipset and furthermore sports
 > > full acceleration -- which would really be nice on this older powerbook!
 > > However, in using the driver my powerbook lockedup nicely. After some
 > > trying of various config switches I got the thing to come up by using
 > > the "NoAccel" option. Alas, the colors were hopelessly screwed up, the
 > > video ram wasn't detected correctly, and the hardware cursor was not an
 > > X but rather <>. Suffice it to say, it was not usable.
 > >
 > > After some small hacking I've gotten the colors right (though this may
 > > just be a coincidence) and I've fixed the ram detection problem (I'm
 > > more certain here as it was only a small fix.) Unfortunately I still can
 > > not use the acceleration as it freezes the machine solid. Sometimes the
 > > screen will come up, but it is frozen on arrival (FOA.)
 > >
 > > Other issues:
 > >
 > > 1.) there seems to be a lot of visuals coming up. That is, by using the
 > > fbdev I get 2 TrueColor visuals for this machine, with the chips driver
 > > I get 2 TrueColor and 2 DirectColor.


That's correct. C&T chips have a writable Truecolor palette. So
you can do Direct Color. As for the duplication this is done in
the glx code I belive.

 > >
 > > 2.) XVideo is hosed. When I try to use any program that makes use of
 > > xvideo I get a BadAlloc error reporting there are insufficient
 > > resources.

That's very likely when you only have 1 Meg of videoram.
There isn't sufficient room for the overlay.

Regards,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Write Combining Range issue on Savage

[Egbert Eich]

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
 ( & 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]Cirrus CLGD5430 woes...2nd try

[Egbert Eich]

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?

[Egbert Eich]

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 q&d 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

[Egbert Eich]

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?

[Egbert Eich]

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]How to reinitialize the mouse / KVM problems

[Egbert Eich]

Mark Vojkovich writes:
 > On Thu, 26 Sep 2002, Dave wrote:
 > 
 > > Hi,
 > > 
 > > I think I have found a simple reproducible bug that makes the 
 > > mouse/keyboard handler freak out.  I don't think this has anything to do 
 > > with my particular set up.  I'm using Linux on Intel.  The problem 
 > > occurs with both the XFree86 VESA driver, and also with the closed 
 > > NVidia Linux driver.
 > > 
 > > Start X11 with any driver.  Log in as root.  Look at the date/time.  Add 
 > > 2 hours to the current time with 'date'.  Move the time back to the 
 > > correct time with 'date'.
 > > 
 > > Now the keyboard and mouse will be screwed up.  The keyboard no longer 
 > > auto-repeats.  The mouse sends incorrect click events.
 > > 
 > > xev shows that when I press a mouse key, no event occurs.  When I 
 > > release the key, both events arrive.  I can no longer move windows with 
 > > the mouse (gnome/sawfish).  gpm continues to work in the console.  X11 
 > > auto-repeat no longer works.
 > > 
 > > In my previous post, I thought this had something to do with 
 > > suspend/resume.  But that is simply because on my Inspiron 8200, when I 
 > > come back from a suspend, my clock is wrong by a couple of hours (even 
 > > if I suspend only for 5 seconds).  APM resets the clock, and XFree is hosed.
 > > 
 > > Can anybody else reproduce this problem?  Is it Linux specific?
 > > 
 > 
 >I'd expect that time running backwards would screw up X-server
 > events. 
 > 

I've fixed the time-running-backward problem of gettimeofday()
by letting GetTimeInMillis() only uses deltas. If a delta happens 
to be < 0 I set it to 0.
Fix is in CVS.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Crash in xkbcomp during build [CVS]

[Egbert Eich]

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/symbols>LD_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/symbols>LD_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?

[Egbert Eich]

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]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Egbert Eich]

Carlos O'Donell writes:
 > dri-devel,
 > 
 > Just coming out of the woodwork to post a few ideas...
 > 
 > It would be interesting to see if bus mastering gets disabled
 > on any other PCI devices? 
 > 
 > Anyone have a PCI logic analyzer? :)
 > 
 > Would it be the norm to expect that a VT switch (going through
 > though the BIOS) would cause a BM disable in order to cancel
 > pending transactions (similar to soft reset)? 

A VT switch restores the PCI state to the situation when the 
Xserver was started. Therefore if BM was enabled when X was
started (ie by the BIOS at boot time) it will remain enabled.
Otherwise it will be disabled and will remain disabled until the
driver explicitely reenables it.
At the time this decision was made it sounded like the most reasonable
approach to leave as little as possible behind when terminating/VT 
switching X.


Egbert.



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]blurry fonts: XF86 4.2.0 / FreeBSD 4.6

[Egbert Eich]

[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()

[Egbert Eich]

Mark Vojkovich writes:
 >OK, after speaking with our PPC people here, I realize that
 > the nv driver is grossly misfenced.  I will refence it.
 > 

Err... Maybe you want to add platform specific macros.
We need to investigate this matter more deeply, however 
the exisitng fences did work on the Alpha.

Regards,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]write_mem_barrier()

[Egbert Eich]

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()

[Egbert Eich]

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]XFree86 4.2.0 on a Toshiba Satellite Pro 410CDDT (C&T CT65548)

[Egbert Eich]

=?iso-8859-1?Q?Erik=5FPaulsen=5FSk=E5lerud?= writes:
 > I wonder if anyone knows the solution to this:
 > 
 > http://www.xfree86.org/pipermail/xpert/2002-March/016093.html
 > 
 > I suffer of the same problems with my laptop, but there were no replies to
 > the post mentioned above.
 > 

Hard to tell.
Neither the original poster nor you bothered to send a log file.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Option "nomtrr"

[Egbert Eich]

Mike A. Harris writes:
 > A user has suggested that Option "nomtrr" has solved a problem 
 > for him, and would like me to make this option default for his 
 > card in the Cards database.
 > 
 > I looked through the documentation briefly, and also greped the 
 > source tree.  I see the option in the sources, but not in the 
 > documentation.
 > 
 > Just wondering if I'm not looking in the right spot, or if it's
 > just missing from the docs?
 > 
 > If it is just missing, let me know and I'll update the XF86Config 
 > manpage, and send in a patch.
 > 

It is very likely that this option is undocumented.
It turns off setting Write Combining ranges.

However it would be more interesting to find out why the
problem went away as this option shouldn't hurt usually
as long as MMIO areas are not set WC.

I had a similar problem a while ago with a silicon motion
chip. Although only the 4Meg video memory range was marked WC
the system hung.
Either this ranges still contains MMIO registers which I have
overlooked or we have a kernel problem.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XF86_SVGA server

[Egbert Eich]

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 Chips&Technologies 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
C&Ts on 4.2.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]SM 710 VESA BIOS

[Egbert Eich]

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]SM 710 VESA BIOS

[Egbert Eich]

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]The S3 driver doesn't work in multi card mode

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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]Re: Xpert digest, Vol 1 #1930 - 2 msgs

[Egbert Eich]

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

[Egbert Eich]

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]LocalClient extensions vs. ssh

[Egbert Eich]

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]NumLock config option

[Egbert Eich]

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

[Xpert]LocalClient extensions vs. ssh

[Egbert Eich]

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]DGA keyboard state vs. Xkb

[Egbert Eich]

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

Re: [Xpert]Re: XIE and PEX5?

[Egbert Eich]

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]C&T 69030 locks ups w/ XFree86 4.2.0 w/ RH 7.3

[Egbert Eich]

Clark Manuel writes:
 > I'm seeing a specific lock up issue shortly after running "startx" with a
 > PIII based system using the C&T 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]Trident CyberbladeXP @ 1400x1050

[Egbert Eich]

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?

[Egbert Eich]

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

[Egbert Eich]

[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 C&T 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 C&T 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]Troubles in cross compile land...

[Egbert Eich]

Jim,

it is 12.30 at night here now. I'll look at the problem tomorrow.

Regards,
Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]horizontal rain on CyberBladeXP/DSTN/Ai1, latest CVS 'trident' driver

[Egbert Eich]

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

[Egbert Eich]

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]siliconmotion driver changes and questions

[Egbert Eich]

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]Re: Trident CyberbladeXP @ 1400x1050

[Egbert Eich]

 > 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]getting X to work on a toshiba satellite 210cs

[Egbert Eich]

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
 >  InputDevice"Generic Keyboard"
 >  InputDevice"Configured Mouse"
 >  InputDevice"Generic 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"
 >  Card"Chips & Technologies CT65550"
 > EndSection
 > 
 > Section "Screen"
 >  Identifier "Default Screen"
 >  Device "Generic Video Card"
 >  Monitor"Generic Monitor"
 >  DefaultDepth 16
 >  SubSection "Display"
 >  Depth 1
 >  Modes"1152x864" "1024x768" "800x600" "640x480"
 >  EndSubSection
 >  SubSection "Display"
 >  Depth 4
 >  Modes"1152x864" "1024x768" "800x600" "640x480"
 >  EndSubSection
 >  SubSection "Display"
 >  Depth 8
 >  Modes"1152x864" "1024x768" "800x600" "640x480"
 >  EndSubSection
 >  SubSection "Display"
 >  Depth 15
 >  Modes"1152x864" "1024x768" "800x600" "640x480"
 >  EndSubSection
 >  SubSection "Display"
 >  Depth 16
 >  Modes"800x600" "640x480"
 >  EndSubSection
 >  SubSection "Display"
 >  Depth 24
 >  Modes"1152x864" "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 t

Re: [Xpert]Asus portable with Silicon Motion Lynx 3DM

[Egbert Eich]

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

[Egbert Eich]

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]Asus portable with Silicon Motion Lynx 3DM

[Egbert Eich]

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]8-bit pseudocolor overlays

[Egbert Eich]

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]Re: signal 4 kills X

[Egbert Eich]

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]Re: signal 4 kills X

[Egbert Eich]

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]8-bit pseudocolor overlays

[Egbert Eich]

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]Trident 1400 display accelerated ?

[Egbert Eich]

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

Re: [Xpert]HWcursor+ XFree4.2 + G550 + DVI (HAL TRUE)

[Egbert Eich]

Laure-Amelie Couturie writes:
 > As nonody answer me, I look for the solution in the mga driver source
 > code. I patch mga-driver.c (version Xfree4.2 and version matrox2.0).
 > Everything seems to work fine for my configuration (matrox G550):
 > it work in HAL mode (dvi flat screen), nice HWcursor, good performance
 > and no more SIG11 when exiting.
 > 
 > I only add one line in mga_driver.c:
 > switch (pMga->Chipset) {
 > case PCI_CHIP_MGA1064:
 > case PCI_CHIP_MGAG100:
 > case PCI_CHIP_MGAG100_PCI:
 > case PCI_CHIP_MGAG200:
 > case PCI_CHIP_MGAG200_PCI:
 > case PCI_CHIP_MGAG400:
 > 
 > source Xfree4.2 :line 2748+case PCI_CHIP_MGAG550:
 > source Matrox2.0:line 2826+case PCI_CHIP_MGAG550:
 > 
 > G550 matrox card was ignored for HWcursor + MGA-HAL. In previous version
 > of mga driver  pMga->Chipset was not test for setting Cursor, so it
 > works for every cards.
 > 
 > I wonder if not setting G550 in this switch-case was a forgetting or if
 > it was intentional because of a specific problem with G550?
 > 

Hi Laure-Amelie,

Thanks a lot for finding this!

This line seems to be left out accidently when support for 
the G550 was added. 
This part of the code had to be added solely to work around 
bugs in HALlib. It has proven to be easier to do such workarounds 
than trying to get Matrox to fix their blackbox. 
You will find several of them scattered around the driver.

Regards,
Egbert.



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Trident CyberbladeXP @ 1400x1050

[Egbert Eich]

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

[Egbert Eich]

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]xfree 4.1 compilation problems

[Egbert Eich]

Mark Vojkovich writes:
 > 
 >I didn't think cross compiling worked.  For instance, some
 > of the things in the tree need to get build for PC (Imake and
 > makedepend) but most of the binaries need to get built for PPC.
 > I didn't think all that stuff was sorted out.
 > 

I will soon commit my cross compiling changes. With those in place
it should be straight forward.
At the moment I don't have the time to do the merge.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: CyberBladeXP Driver

[Egbert Eich]

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

[Xpert]Trident 9397 Color Distortion Problem

[Egbert Eich]

A while ago several people have posted reports about
color distortion with the Trident 9397. 
Alan and I followed up on these reports and we had it 
debugged half ways when the person who helped us debugging 
suddenly disappeared. 

Neither Alan nor I have access to a 9397 therefore we have 
to rely on somebody else to help us.
Also we don't think that if we spare our time to follow
up on people's reports we ask to much if we request to 
do some simple tests for us.

Therefore anyone seeing this problem is 
invited to help us tracking it down.

Egbert.



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]S3 ProSavageDDR

[Egbert Eich]

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]Re: [XFree86-4.2.0 + i810] crashes with KDE-3.0 beta2

[Egbert Eich]

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]Re: [XFree86-4.2.0 + i810] crashes with KDE-3.0 beta2

[Egbert Eich]

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]Trident CyberBlade driver

[Egbert Eich]

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]XFree 4.2.0 on Chips C&T 69000, noaccel

[Egbert Eich]

Hi David,

I've traced this problem and posted an answer already.
Maybe I hit the wrong button again and it didn't go to the
list. I don't have this email any more. Maybe Mark should repost
it to the Xpert list.
The problem is not C&T driver related and we will see more
of these bug reports in the future.
A patch to xf86Cursor.c broke silken mouse support - or better
to say the feature to disable it. This unfortunately will affect
all C&T chips and all others that don't allow fb access while
blits are active.

Egbert.


David Bateman writes:
 > On Fri, Mar 08, 2002 at 11:24:03AM -0500, Mark van Rossum wrote:
 > > 
 > > Hi,
 > > 
 > > I'm using Xfree86 4.2.0 on a Compaq Armada 3500 (RH 7.2) with a Chips
 > > 69000 video card.
 > > 
 > > This work as long as I use the "noaccel" option.
 > > 
 > > However, without this option, I can start X, but as soon as I do 
 > > something a bit complicated (start netscape) the system locks up hard.
 > > 
 > > In Xfree3.3.6 the noaccel was not needed.
 > > 
 > > Any solutions ?
 > 
 > Can you play with the XaaNoX options to turn off acceleration primitives
 > one by one. I suggest you use all of the options and then turn them back on
 > one by one till you generate the lock-up. This will then allow the problem
 > to be isolated.
 > 
 > Regards
 > David
 > ___
 > Xpert mailing list
 > [EMAIL PROTECTED]
 > http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]ct65555 and XVideo

[Egbert Eich]

Andrei Lahun writes:
 > Hello .
 > Firstly thank you for fixing bug with c&t 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 C&T 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

[Egbert Eich]

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

[Egbert Eich]

 > 
 > 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]Mouse pointer shifted some pixels to the right

[Egbert Eich]

Felipe Massia Pereira writes:

I have seen this problem once so far but was not able to find a fix
for it. The cursor suddenly shifts right and says shifted - even after
restarting X and reinitializing the chip.
The chipset certainly got the correct address for the cursor.
Therefore it is not a bug in X but rather a bug in the chip.

Since I have no idea how to persuade the chip to return to the correct
behavior the only solution for now is disabling HW cursor.

Egbert.


 > Hello *!
 > 
 > The problem: During normal use, the mouse pointer is shifted about 40
 > pixels to the right. My pointer does not reach the left extent of the
 > screen and gets through the left extent, disappearing. When I click it is
 > as if nothing was wrong: I can click the 0 pixel and the 1023 pixel. But
 > the pointer is somehow shifted from the point it really clicks.
 > 
 > Is there a way to fix this? I tried to restart X server, restart gpm (text
 > cursor not affected), but the pointer remains like this until next boot.
 > It's extremely annoying having to boot every 5 minutes of working (that's
 > an optimistic guess of the time it takes to get messed up).
 > 
 > I'm using XFree86-4.2.0, my chipset is a CyberBlade/i7.
 > 
 > I had this problem already with Mandrake 8. Probably it was using server 
 > 4.x. Then I moved to RedHat 7.2 and I was using server 3.xx. But a window
 > move was too slow then I changed the server to 4.2.0 w/ RPMs from RawHide.
 > Now window moves are good! But not the mouse (such a little thing! :).
 > 
 > I'd like to hear/read from someone if there's a command to call and make
 > the pointer shift left by n pixels, what command is this? Or it's a
 > problem with the server? Or someone with the same problem?
 > 
 > Thanks in advance,
 > --
 > Felipe Massia Pereira
 > CS MSc Student @ IC-UNICAMP
 > 
 > ___
 > Xpert mailing list
 > [EMAIL PROTECTED]
 > http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Trident Cyber 9397 with Xfree86 4.2

[Egbert Eich]

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

[Egbert Eich]

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

[Egbert Eich]

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)

[Egbert Eich]

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]Re: SiS630 - the neverending story

[Egbert Eich]

Your BIOS doesn't support 1024x768 with 24bpp.

Egbert.


Giuseppe Sacco writes:
 > Just tried the latest CVS (17 dec 2001) on a SiS630 connected to a
 > normal CRT. X doesn't start at all :-)
 > 
 > Attached there is the log I found in /var/log.
 > 
 > Do you have any hints?
 > 
 > Bye,
 > Giuseppe
 > 
 > 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.99.2 / X Window System
 > (protocol Version 11, revision 0, vendor release 6510)
 > Release Date: xx 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 http://www.XFree86.Org/)
 > Build Operating System: Linux 2.4.16 i686 [ELF] 
 > Module Loader present
 > (==) Log file: "/var/log/XFree86.0.log", Time: Wed Dec 19 14:47:34 2001
 > (==) Using config file: "/etc/X11/XF86Config-4"
 > Markers: (--) probed, (**) from config file, (==) default setting,
 >  (++) from command line, (!!) notice, (II) informational,
 >  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 > (==) ServerLayout "Default Layout"
 > (**) |-->Screen "Monitor" (0)
 > (**) |   |-->Monitor "SyncMaster"
 > (**) |   |-->Device "SiS 630"
 > (**) |-->Input Device "Generic Keyboard"
 > (**) Option "XkbSymbols" "en_US(pc104)+it"
 > (**) XKB: symbols: "en_US(pc104)+it"
 > (**) Option "XkbRules" "xfree86"
 > (**) XKB: rules: "xfree86"
 > (**) Option "XkbModel" "pc104"
 > (**) XKB: model: "pc104"
 > (**) Option "XkbLayout" "us"
 > (**) XKB: layout: "us"
 > (==) Keyboard: CustomKeycode disabled
 > (**) |-->Input Device "Mouse USB"
 > (**) |-->Input Device "TouchPad"
 > (WW) The directory "/usr/lib/X11/fonts/misc" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/100dpi/" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/75dpi/" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/Type1" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/Speedo" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/100dpi" does not exist.
 >  Entry deleted from font path.
 > (WW) The directory "/usr/lib/X11/fonts/75dpi" does not exist.
 >  Entry deleted from font path.
 > (**) FontPath set to "unix/:7100"
 > (==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
 > (==) ModulePath set to "/usr/X11R6/lib/modules"
 > (**) Option "Xinerama" "true"
 > (**) Xinerama: enabled
 > (--) using VT number 7
 > 
 > (II) Open APM successful
 > Couldn't open RGB_DB '/usr/X11R6/lib/X11/rgb'
 > (II) Module ABI versions:
 >  XFree86 ANSI C Emulation: 0.1
 >  XFree86 Video Driver: 0.5
 >  XFree86 XInput driver : 0.3
 >  XFree86 Server Extension : 0.1
 >  XFree86 Font Renderer : 0.3
 > (II) Loader running on linux
 > (II) LoadModule: "bitmap"
 > (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
 > (II) Module bitmap: vendor="The XFree86 Project"
 >  compiled for 4.1.99.2, module version = 1.0.0
 >  Module class: XFree86 Font Renderer
 >  ABI class: XFree86 Font Renderer, version 0.3
 > (II) Loading font Bitmap
 > (II) LoadModule: "pcidata"
 > (II) Loading /usr/X11R6/lib/modules/libpcidata.a
 > (II) Module pcidata: vendor="The XFree86 Project"
 >  compiled for 4.1.99.2, module version = 0.1.0
 >  ABI class: XFree86 Video Driver, version 0.5
 > (II) PCI: Probing config type using method 1
 > (II) PCI: Config type is 1
 > (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
 > (II) PCI: PCI scan (all values are in hex)
 > (II) PCI: 00:00:0: chip 1039,0630 card , rev 11 class 06,00,00 hdr 80
 > (II) PCI: 00:00:1: chip 1039,5513 card 1039,5513 rev d0 class 01,01,80 hdr 80
 > (II) PCI: 00:01:0: chip 1039,0008 card , rev 00 class 06,01,00 hdr 80
 > (II) PCI: 00:01:1: chip 1039,0900 card 1043,1455 rev 80 class 02,00,00 hdr 00
 > (II) PCI: 00:01:2: chip 1039,7001 card 1039,7001 rev 07 class 0c,03,10 hdr 00
 > (II) PCI: 00:01:3: chip 1039,7001 card 1039,7000 rev 07 class 0c,03,10 hdr 00
 > (II) PCI: 00:01:4: chip 1039,7018 card 1043,1453 rev 01 class 04,01,00 hdr 00
 > (II) PCI: 00:01:6: chip 1039,7013 card 1043,1456 rev a0 class 07,03,00 hdr 00
 > (II) PCI: 00:02:0: chip 1039,0001 card , rev 00 class 06,04,00 hdr 01
 > (II) PCI: 00:0a:0: chip 1180,0476 card 4000, rev 80 class 06,07,00 hdr 82
 > (II) PCI: 00:0a:1: chip 1180,0476 card 4800, rev 80 class 06,07,00 hdr 82
 > (II) PCI: 01:00:0: chip 10

Re: [Xpert]Abridged: Total frustration with XFree86 4.1.0!

[Egbert Eich]

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?

[Egbert Eich]

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]Trident cyberbladeXPAi1

[Egbert Eich]

David L. Gehrt writes:
 > Well I have my Toshiba 1805-274 running X with problems.  The problems
 > are that each thing displayed seems to have three flickering bounding
 > boxes like line artifact offset a few pixels to the right of the
 > object. If any one can suggest a fix it would be appreciated.
 > 
 > I have included the output of scanpci, lpsci.  the XF86config file, and
 > the /var/log/XFree86.0.log file from getting X up and running.  I tried
 > a couple of times to grab a screen shot in the hopes it might show the
 > artifacts I am seeing, but they came up clean, to the artifact is a
 > ghost.
 > 

Hm, did you upgrade the driver in the meantime?
I've committed a fix for XPAi1 support on Thursday.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]1400x1050 on Tecra 8200 with 4.1.0

[Egbert Eich]

kiss the sun and walk on air writes:
 > On Wed, Dec 12, 2001 at 05:15:12PM +0100, Christian Neubauer wrote:
 > > i am really desperate after reading maillist archives, FAQs etc. My
 > > Thosiba Tecra 8200 with 1400x1050 display reports to the trident
 > > X-server module that is is a 1280x1050. Probably the server insists in
 > > prefering VESA modes, although the 1400x1050 mode is reported.
 > > 
 > > 1. Does anyone know how to tell xfree not to probe for any display but
 > > specifying a certain resolution
 > 
 > Its not really probing for the display, as much as there is a LCD[]
 > constant defined in the trident_driver.c module which defines all of
 > the LCD modes. 1280x1024 is the largest one in that array.
 > 
 > I briefly tried to modify the array to include 1400x1050 and all I got
 > was a confusing grey screen. I don't know what all the various
 > parameters need to be though.

I can add this mode however I need some informations about it
first. 
The driver won't be able to detect it automatically, though.
We'd have to add an option for this.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]SiS630 LCD - again (success)

[Egbert Eich]

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]Trident cyberbladeXPAi1

[Egbert Eich]

Olivier Fourdan writes:
 > Gabriele,
 > 
 > I have EXACTLY the same problem with a 1800-214 and the same video card.
 > 
 > I did exactly the same (try XFree86 4.10, get the CVS, etc.)  w/out success. 
 >However, I am now able to run X using Vesa over FB in 1024x768 16bpp.
 > 
 > I can contribute my XF86Config if needed. Note that Vesa over FB is far from being a 
 >good solution, because there is no acceleration and the CPU makes all the work. 
 >However, it's better than nothing at all.
 > 
 > To the trident driver Maintainer (Alan Hourihane, I think) :
 > 
 > If someone has an idea about what's wrong with the trident driver, I can help and 
 >test. I can also try to tweak the driver, but I don't know where to start.
 > 
 > I noted, by reading the source, that the driver is expecting SGRAM for the XPAi1 
 >while it uses SDRAM on Toshiba laptops. Does this make any difference ? I seems that 
 >the trident driver is using no accelration and FB when running on a XPAi1. So my next 
 >question is, even if I can make it run with my card, will that make any difference 
 >compared to Vesa ?
 > 

Please guys, be patient.
I'm currently working on this driver.

I now works here (modulo accel). I just need to clean up the patches.
I won't be able to do so today as I'm invited to an X'mas party
and I've got to leave now ;-)
Please also note that I have spent more time answering emails on this
than it took me to figure out what needs to be changed on the Trident
driver.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]SiS630 and LCD

[Egbert Eich]

Thomas Winischhofer writes:
 > Braustein Alfredo wrote:
 > > Other differences: On the first case I get a strange xterm cursor, like: 
 > >
 > > #
 > > #  #
 > > #  #
 > > #  #
 > > # 
 > >
 > > instead of a rectangle.
 > 
 > I noticed that some acceleration function (rectangle...?) in the sis
 > driver seems to cause screen distortion under X:
 > 
 > Under KDE, vertical scroll bars in windowborders, borders of tool-tips
 > and the (+) and (-) in the tree-view of Konqueror (in filemanager mode)
 > show the same symptom:
 > 
 > The top and bottom line of the (black) rectangle is one point to long
 > out to the right. These two dots are never being cleared, so after a
 > while I have a lot of black dots around the screen.
 > 

This problem is fixed. 
If anybody needs the fix please upgrade to current CVS version.

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

[Egbert Eich]

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]SiS630 and LCD

[Egbert Eich]

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]Help with CyberBladeXPAi1 (Trident) on a Toshiba 1800-814 laptop

[Egbert Eich]

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]Trident cyberbladeXPAi1

[Egbert Eich]

Olivier Fourdan writes:
 > Egbert, 
 > 
 > > 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.
 > 
 > Humm, this is exactly what I've done (I'm quite used to Linux, running it 
 >exclusively since 1994).
 > 
 > And, guess what,  if you look at Trident web site (www.tridentmicro.com) and look 
 >for the CyberBladeXPAi1, it's supposed to be "tested and certified on Windows 98, ME, 
 >2000, XP *and* Linux" (Look at the bottom of their page, this is what they say)

I didn't find the XPAi1 listed anywhere - just the XP. And indeed
they say it's supported under Linux. On the other hand they don't
allow us to release OpenSource code derived from their XP specs.

to me this looks awfully like a commercial Xserver vendor has a deal
with them.

 > 
 > Actually, this is why I've choosen that particular laptop ! Crazy, isn't it ?

Yes! But you have been misled.

Well, let's see what we can do.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]SiS630 and LCD

[Egbert Eich]

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]SiS630 and LCD

[Egbert Eich]

Rune Petersen writes:
 > The old drivers made the screen all white, to get it to work  I had to patch
 > the drivers so they didn't setup the LCD, an then use the VESA framebuffer
 > to setup the display.

Guess how I debugged the sis_bios.c code. I enabled the VESA
framebuffer, removed parts of the initialization in sis_bios.c
until I found the code that broke it.
This is a bit tricky. Most initialization functions in sis_bios.c
depend on variables set by the previous functions called. One cannot
just remove them at random but rather work his way up from the bottom.

As I said already: this funtion contains x86 BIOS code converted to C.
This is how this code looks like, too.
 > 
 > I have no experience in this but the VESA framebuffer (as far as I know)
 > uses the BIOS to setup the LCD and that works for me, any chance the same
 > can be done with these drivers?
 > or have I gotten it all wrong?
 > 

No, that's what will happen eventually. I will add code that simply
uses the BIOS to set video modes and make this the default.
sis_bios.c really isn't anything else.

Egbert.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert