Re: WD90C24 Anyone?
On Tue, 2006-11-07 at 16:26 -0800, Tim Roberts wrote: > [EMAIL PROTECTED] wrote: > > I have an old ThinkPad 750P. It uses the WD90C24 chip, which was in > > the old svga driver. > > > > What would it take to port that to the new XFree86 code? I'm not above > > writing assembly code or digging in here, I just don't know where to > > start or how much effort it might take... swatting a fly or eating an > > elephant? > > Holy moly! You have a whopping 1 megabyte of video RAM there. > > Will it work with the VESA fb driver? If not, then you might as well > give up. I have the source code for their old Windows 3.1 driver, and > it is more than 76,000 lines of 16-bit x86 assembler. The blitter > provided virtually no acceleration, so you won't really be giving > anything up to use the fb driver. > I thought I was the last cave man. I used a WD90C30 with the svga driver in 4.4 when I ported the HGA driver. You're either looking at flies or my binoculars flipped over in the last 12 months. Enjoy Lee Olsen [EMAIL PROTECTED] ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Multihead ISA
Egbert Eich wrote:
Lee Olsen writes:
> Hello Egbert;
>
> Egbert Eich wrote:
>
> >Hello Lee,
> >
> >thank you for the patches!
> >
> >Lee Olsen writes:
> >
> > > I have completed my tests with my supply of trailing edge hardware, and
> > > my hercules driver plays
> > > well with X440. There are two attachments, one is a tar file of the
> > > hercules driver source and the other
> > > is unified diffs in the forward direction of changes that let X440 do
> > > multihead ISA.
> >
> >I'd expect that there are very few people who can still test the
> >hercules driver, but if you are willing to do the support this
> >should not be a problem.
> > >
> > > The diffs do three things: separate color and mono resources, disable
> > > vga routing for busses that
> > > don't have routing functions, and let the configure process collect ISA
> > > resource usage like it does
> > > for PCI.
> >
> >I don't understand this. The configure process is not there to collect
> >resources. This is done during xf86ConfigIsaEntity(). This function should
> >not return an allocated ScreenInfo structure if it finds conflicts.
> >Unresolvable ISA resources should really disable both confliciting
> >resources.
> >
> >
> The problem is resource conflicts are fatal. If a vendor specific
> Probe() succeeds, then the vesa and vga
> probes must fail. It might be different if resource conflicts propogated
That's what you want. You probe as long as you found a driver.
The vesa and vga probes are at the end as they are considered
fallbacks only. If you want the vesa driver even if a chipset
driver exists you need to use a config tool.
Also the autoconfiguration will always try to get you the chipset
specific driver.
> back up and became PreInit()
> failures, but that's not the case. The question is how do you know if
> the current Probe() should fail?
The Probe() function should fail if the driver isn't able to identify
a chipset as his. It also fails if another driver has allocated the
(fixed) resources the driver wants.
This should happen on the second pass thru configure.
> The existing code checks to see if any non-PCI devices have been
> configured and if so, forces
> subsequent non-PCI Probe()s to fail. What I'd like to do is use the
Yes.
for (i = 0; i < nDevToConfig; i++)
if (!DevToConfig[i].pVideo)
return NULL;
Does that.
> resource list to tell me if the
> device being Probe()d has been successfully Probe()d by a different
> driver. If so, the current
> Probe() should fail. Since the resources are exclusive, any overlap
> means two drivers
> want the same device. MatchIsaInstances already had the resource data,
> it just needed to use
> AddBusDeviceToConfigure() to make it available to DoConfigure().
Ah, I see.
OK, I understand that. For PCI we do:
for (i = 0; i < nDevToConfig; i++)
if (DevToConfig[i].pVideo &&
(DevToConfig[i].pVideo->bus == pVideo->bus) &&
(DevToConfig[i].pVideo->device == pVideo->device) &&
(DevToConfig[i].pVideo->func == pVideo->func))
return NULL;
For ISA we obviously have no ID to identify the device :-/
so you are using the resources as an identifier. Well,
I guess one can do that.
On the other hand DoConfigure does a second pass thru Probe()
- this time it doesn't set PROBE_DETECT, therefore xf86ConfigIsaEntity()
is called and should do the same thing, namely to check for conflicts
with a previously detected device.
I must admit I forgot the details, maybe there is some other reason
why it doesn't work this way. Have you checked?
At this point, resource conflicts detected within
ConfigIsaEntity/ClaimFixedResources
go directly to FatalError, and pass two cannot return false as it never
regains control:
switch (range.type & ResAccMask) {
case ResExclusive:
if (!xf86ChkConflict(&range, entityIndex)) {
Acc = xf86AddResToList(Acc, &range, entityIndex);
#ifdef REDUCER
} else {
range.type |= ResEstimated;
if (!xf86ChkConflict(&range, entityIndex) &&
!checkConflict(&range, AccReducers, entityIndex,
SETUP, FALSE)) {
range.type &= ~(ResEstimated | ResBios);
AccReducers =
xf86AddResToList(AccReducers, &range, entityIndex);
#endif
} else resError(&range); /* no return */
To stay out of FatalError, the resource check has to be before
Re: Multihead ISA
Hello Egbert; Egbert Eich wrote: Hello Lee, thank you for the patches! Lee Olsen writes: > I have completed my tests with my supply of trailing edge hardware, and > my hercules driver plays > well with X440. There are two attachments, one is a tar file of the > hercules driver source and the other > is unified diffs in the forward direction of changes that let X440 do > multihead ISA. I'd expect that there are very few people who can still test the hercules driver, but if you are willing to do the support this should not be a problem. > > The diffs do three things: separate color and mono resources, disable > vga routing for busses that > don't have routing functions, and let the configure process collect ISA > resource usage like it does > for PCI. I don't understand this. The configure process is not there to collect resources. This is done during xf86ConfigIsaEntity(). This function should not return an allocated ScreenInfo structure if it finds conflicts. Unresolvable ISA resources should really disable both confliciting resources. The problem is resource conflicts are fatal. If a vendor specific Probe() succeeds, then the vesa and vga probes must fail. It might be different if resource conflicts propogated back up and became PreInit() failures, but that's not the case. The question is how do you know if the current Probe() should fail? The existing code checks to see if any non-PCI devices have been configured and if so, forces subsequent non-PCI Probe()s to fail. What I'd like to do is use the resource list to tell me if the device being Probe()d has been successfully Probe()d by a different driver. If so, the current Probe() should fail. Since the resources are exclusive, any overlap means two drivers want the same device. MatchIsaInstances already had the resource data, it just needed to use AddBusDeviceToConfigure() to make it available to DoConfigure(). Do you have a better way to do this? Appearantly you are trying to make the result of configure more reliable. Currently configure only takes the results of Probe() into account and doesn't care about resource management. Configure will only try to detect the devices, it doesn't guarantee that the devices it has found will really work. This will decided when the server is really started. It will pick those devices from the config file and enable them that are capable to run. If no device is the server is going to fail. The automatic configuration mechansim David has designed instead uses the results of PreInit() to make decisions and look for possible fallbacks. This will be a big help. > > Without hardware to test it, you may not want to add the driver to the > source tree, but it would be > nice if the diffs or their functional equivalents did make it. If you'd > rather this went through > bugzilla, I can do that. I didn't see how to upload files on the "Create > bug" page, but that > could be bad eyesight on my part. That's fine. If you want to go thru the bugzilla you can create an attachment to an already created entry to include your diff. Ideally you would not attach them compressed, this makes it easier to review them on line. However this matter is educational so lets discuss it here. I have two issues: 1. The minor issue: You are deleting xf86AddDeviceToConfigure() It looks like that this function is not needed any more. However it may have to be kept for backward compatibility as it is exposed to drivers. We have no information if older binary only drivers use it (although I don't think so). I had not considered third party drivers. It does not need to go away, nor it's reference in loader/xf86sym.c. 2. You are splitting the mono and color resources. This is good, however it may cause problems: VGA devices may be configured to use the monochrome resources. I've seen BIOSes doing that when they find another card with color resources. Therefore we are allocating both sets of resources. We need to think how deal with that. I'd suggest to continue to allocate both mono and color resources for PCI devices as those resources are shared anyway. For ISA devices it is a little bit more difficult. Since we don't know if the device we are probing is the one we are interested in or another one. There are three sets of resource blocks in xf86Bus.c, color, mono, and both. The shorthand defines I pointed at color and mono. The ati driver uses both but does not use the define. In xf86Resources.h: #define RES_SHARED_VGA resVgaSharedColor goes back to the original: #define RES_SHARED_VGA resVgaShared That will allocate both for PCI cards. ISA cards should not be both until we know for sure. You can try an X -configure on the vga alone and see if it adds the hercules head. It may use the memory block without
Multihead ISA
Hello all; I have completed my tests with my supply of trailing edge hardware, and my hercules driver plays well with X440. There are two attachments, one is a tar file of the hercules driver source and the other is unified diffs in the forward direction of changes that let X440 do multihead ISA. The diffs do three things: separate color and mono resources, disable vga routing for busses that don't have routing functions, and let the configure process collect ISA resource usage like it does for PCI. Without hardware to test it, you may not want to add the driver to the source tree, but it would be nice if the diffs or their functional equivalents did make it. If you'd rather this went through bugzilla, I can do that. I didn't see how to upload files on the "Create bug" page, but that could be bad eyesight on my part. Enjoy Lee X440_hercules.tgz Description: GNU Zip compressed data multihead.diffs.gz Description: GNU Zip compressed data
Re: Vesa Driver Probe
David Dawes wrote: On Sun, Mar 28, 2004 at 05:14:39PM -0800, Lee Olsen wrote: Hello all; The vesa driver probe/FindIsaDevice is doing a vga probe, not a vesa one. It should be calling a vbe routine to check for a vesa signature. The Probe() function should not change the hardware state and should be as non-intrusive as possible. When Probe() reports success, it does not mean that the driver's PreInit() will succeed. The vesa driver is not especially unusual in this respect. Why do you need to change this? That is exactly the misunderstanding I suffer from. If X -configure creates a config file, I expect it to work with the hardware just configured. If Probe succeeds and PreInit fails, then the configuration isn't valid. When it's something like the ati driver configuring a screen for a VGA-less 8514 and failing in PreInit, that's not a big deal because it's very likely there's a VGA head supported by another driver. I figured a single-headed configuration shouldn't do this. With the trailing-edge cards I'm testing for vga/mono conflicts generally using the vesa driver, I wanted to eliminate the "No screens found" distraction. Fortunately it's a "want" rather than a "need", and based on Egbert's comments, a bigger can of worms than I want to deal with right now. Since X -configure won't generate a vga device entry, Egbert's ideas about doing vga stuff in the vesa driver might be the right long term solution. At least it brings Probe and PreInit back in sync. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Egbert Eich wrote: Lee Olsen writes: > Egbert Eich wrote: > > > >You mean you want to map the BIOS memory and search it for the signature. > > > > > > > I believe I want to use int10, function 0x4f, subfunction 0, as is done > in VBEExtendedInit. There may be > other, less intrusive ways. OK. In this case we should *assume* that the card is VESA and fail later if this fails - or better yet add a fallback to the lame pre-VESA BIOS video modes that were standardized and only fail if those don't work either. I'll assume later means in Init, when screens and entities are available rather than in Probe. Currently vesa and vga are separate drivers. Since the vesa probe ensures X -configure will never create a vga device entry, perhaps the vesa driver should load the vga stuff as a submodule when faced with a non-vesa vga card. That removes the need for int10 at probe time and addresses X -configure; startx resulting in "No screens found". Or I can throw the card away. The vbeModes thing looks like it should look at the memoryModel before computing depth. Direct color is model 6, and adding the mask sizes is correct. Packed pixel is mode 4 and the masks are meaningless. I chose to use bits per pixel, as that's what the vesa driver uses for selecting its frame buffer functions. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Egbert Eich wrote: Hi Lee, Unfortunately your patch is backwards. Furthermore I'd personally prefer unified over context diffs. Lee Olsen writes: > Hello all; > > The vesa driver's probe only looks for a vga. If you have a real stone > age original vga, you get > "No screens found". The vesa probe needs to look for the vesa signature > in the bios, and that > means libint10.a and libvbe.a must be able to run without referencing > screens or entities, which > they both do. You mean you want to map the BIOS memory and search it for the signature. I believe I want to use int10, function 0x4f, subfunction 0, as is done in VBEExtendedInit. There may be other, less intrusive ways. > > The diffs that follow avoid entity and screen references for indexes > less than zero and behave > as before for positive values.My copy of the vesa driver has some > multihead isa stuff in it, so I have sepent some time thinking about multihead ISA. The only chance for it to work appeared to be if ISA cards are capable of remapping their registers. This is scary as there is no range they can do this savely (except for the 8514 regsters). However I never had any cards with docs that I was able to try it so I gave up on it. Furthermore I would have expected that at boot time both cards would have their default registers VGA enabled which will definitely produce problems during POSTing. Not to speak of the problem that arise if both cards map their ROM into the same range. Therefore I'd expect that this has only a chance to work if you are able to disable the standard VGA registers and BIOS on one card entirely (using jumpers) in which case I don't understand how the VESA driver would be of any help for such a card. Now that I rechecked my vesa driver diffs, you're right. I'm chasing a zoom problem and not doing any multihead stuff there. I don't expect to run multiple isa VGA cards in the same box. I don't see how to remap VGA resources either. I do expect 8514, VGA, and mono to coexist. If there are other isa cards that can disable VGA features like the Graphics Ultra Pro, they can be added to the list. > I'll save that for later. Since these are independent, I'm presenting > them without the multihead > clutter. I'm not sure I got everything, but it tests correctly for pure > isa vga, pure isa vesa, and > pci/agp/no isa. I don't think my bios will let me put an isa video card > in the pci/agp box. > > The two line vbeModes.c change fixes VBEFindSupportedDepths reporting > zero for depths > les than 15. The symptom I saw is a 512k card requesting a depth of 16, > resulting in "No usable > modes." > > Enjoy > Lee > > diff -c helper_exec.c* > *** helper_exec.cMon Mar 29 11:35:02 2004 > --- helper_exec.c.origTue Dec 23 14:32:38 2003 > *** > *** 581,587 > unsigned char* base; > int i; > > ! if (!save && !pInt->BIOSScratch) > return; > > base = xf86MapVidMem(pInt->scrnIndex, VIDMEM_MMIO, 0, pagesize); > --- 581,588 > unsigned char* base; > int i; > > ! if (!xf86IsEntityPrimary(pInt->entityIndex) > ! || (!save && !pInt->BIOSScratch)) > return; I'd say this is not valid. xf86Int10SaveRestoreBIOSVars() copies the physical BIOS variable area to and from the scratch area. This physical area exists only once and belongs to the primary card. The physical BIOS area is set up during posting. Therefore the values are only meaningful for the card that got posted, not any other card. The diffs I provided are a minimal set that allowed the probe to run. This is the kind of feedback I was hoping for. What is the right way to do this? Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Andrew C Aitchison wrote:
On Mon, 29 Mar 2004, Lee Olsen wrote:
The two line vbeModes.c change fixes VBEFindSupportedDepths reporting
zero for depths
les than 15. The symptom I saw is a 512k card requesting a depth of 16,
resulting in "No usable
modes."
diff -bc vbeModes.c*
*** vbeModes.cMon Mar 29 15:24:45 2004
--- vbeModes.c.origThu Nov 6 10:38:14 2003
***
*** 54,61
depth = 1;
}
bpp = mode->BitsPerPixel;
- if (!depth)
- depth = bpp;
VBEFreeModeInfo(mode);
mode = NULL;
switch (depth) {
--- 54,59
End of vbeModes.c changes
I take it that that these diffs are backwards - can you do
diff -bc vbeModes.c.orig vbeModes.c
next time ?
Certainly.
I'm uneasy about this. The lines before are:
if (VBE_MODE_COLOR(mode)) {
depth = mode->RedMaskSize + mode->GreenMaskSize +
mode->BlueMaskSize;
} else {
depth = 1;
}
bpp = mode->BitsPerPixel;
VBEFreeModeInfo(mode);
mode = NULL;
switch (depth) {
so your case must have
VBE_MODE_COLOR(mode)
and
mode->RedMaskSize + mode->GreenMaskSize + mode->BlueMaskSize == 0
Is this valid ?
Are we missing something else, like a difference between direct and
indexed colours ?
It looks to me like direct is handled correctly and indexed is not. I
think I'm fixing that.
All the modes I get in /var/log/XFree86.0.log for bpp <= 8 have zero
for all the mask sizes.
With the code that follows looking like this:
case 1:
return V_DEPTH_1;
case 4:
return V_DEPTH_4;
case 8:
return V_DEPTH_8;
case 15:
return V_DEPTH_15;
case 16:
return V_DEPTH_16;
case 24:
switch (bpp) {
case 24:
return V_DEPTH_24_24;
case 32:
return V_DEPTH_24_32;
}
}
}
if (mode)
VBEFreeModeInfo(mode);
return 0;
And an expected return value of V_DEPTH_8 when bpp is 8, it looked like
a solution. Maybe not THE solution,
but a solution. While we're here, the free is too far down and is
causing a memory leak. It should be before the
switch.
Enjoy
Lee
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Hello all;
The vesa driver's probe only looks for a vga. If you have a real stone
age original vga, you get
"No screens found". The vesa probe needs to look for the vesa signature
in the bios, and that
means libint10.a and libvbe.a must be able to run without referencing
screens or entities, which
they both do.
The diffs that follow avoid entity and screen references for indexes
less than zero and behave
as before for positive values.My copy of the vesa driver has some
multihead isa stuff in it, so
I'll save that for later. Since these are independent, I'm presenting
them without the multihead
clutter. I'm not sure I got everything, but it tests correctly for pure
isa vga, pure isa vesa, and
pci/agp/no isa. I don't think my bios will let me put an isa video card
in the pci/agp box.
The two line vbeModes.c change fixes VBEFindSupportedDepths reporting
zero for depths
les than 15. The symptom I saw is a 512k card requesting a depth of 16,
resulting in "No usable
modes."
Enjoy
Lee
diff -c helper_exec.c*
*** helper_exec.cMon Mar 29 11:35:02 2004
--- helper_exec.c.origTue Dec 23 14:32:38 2003
***
*** 581,587
unsigned char* base;
int i;
! if (!save && !pInt->BIOSScratch)
return;
base = xf86MapVidMem(pInt->scrnIndex, VIDMEM_MMIO, 0, pagesize);
--- 581,588
unsigned char* base;
int i;
! if (!xf86IsEntityPrimary(pInt->entityIndex)
! || (!save && !pInt->BIOSScratch))
return;
base = xf86MapVidMem(pInt->scrnIndex, VIDMEM_MMIO, 0, pagesize);
End of helper_exec.c changes
diff -c generic.c*
*** generic.cMon Mar 29 14:19:58 2004
--- generic.c.origTue Sep 23 19:43:33 2003
***
*** 70,76
void* vbiosMem = 0;
void* options = NULL;
pciVideoPtr pvp;
- ScrnInfoPtr pScrn;
int screen;
legacyVGARec vga;
xf86int10BiosLocation bios;
--- 70,75
***
*** 80,96
CARD32 cs;
#endif
! if (entityIndex >= 0)
! pScrn = xf86FindScreenForEntity(entityIndex);
! else
! pScrn = NULL;
! if (pScrn)
! screen = pScrn->scrnIndex;
! else
! screen = -1;
! if (pScrn)
! options = xf86HandleInt10Options(pScrn,entityIndex);
if (int10skip(options)) {
xfree(options);
--- 79,87
CARD32 cs;
#endif
! screen = (xf86FindScreenForEntity(entityIndex))->scrnIndex;
! options = xf86HandleInt10Options(xf86Screens[screen],entityIndex);
if (int10skip(options)) {
xfree(options);
***
*** 107,116
pInt->scrnIndex = screen;
base = INTPriv(pInt)->base = xnfalloc(SYS_BIOS);
! if (entityIndex >= 0)
! pvp = xf86GetPciInfoForEntity(entityIndex);
! else
! pvp = NULL;
if (pvp) pInt->Tag = ((pciConfigPtr)(pvp->thisCard))->tag;
/*
--- 98,104
pInt->scrnIndex = screen;
base = INTPriv(pInt)->base = xnfalloc(SYS_BIOS);
! pvp = xf86GetPciInfoForEntity(entityIndex);
if (pvp) pInt->Tag = ((pciConfigPtr)(pvp->thisCard))->tag;
/*
***
*** 146,152
xf86int10ParseBiosLocation(options,&bios);
! if ((entityIndex < 0 || xf86IsEntityPrimary(entityIndex))
&& !(initPrimary(options))) {
if (bios.bus == BUS_ISA && bios.location.legacy) {
--- 134,140
xf86int10ParseBiosLocation(options,&bios);
! if (xf86IsEntityPrimary(entityIndex)
&& !(initPrimary(options))) {
if (bios.bus == BUS_ISA && bios.location.legacy) {
***
*** 209,222
} else {
BusType location_type;
- EntityInfoPtr pEnt;
int bios_location = V_BIOS;
int pci_entity;
! if (pInt->entityIndex >= 0)
! pEnt = xf86GetEntityInfo(pInt->entityIndex);
! else
! pEnt = NULL;
reset_int_vect(pInt);
set_return_trap(pInt);
--- 197,206
} else {
BusType location_type;
int bios_location = V_BIOS;
int pci_entity;
! EntityInfoPtr pEnt = xf86GetEntityInfo(pInt->entityIndex);
reset_int_vect(pInt);
set_return_trap(pInt);
***
*** 325,331
xf86DrvMsg(screen, X_CONFIG,"Looking for legacy V_BIOS "
"at 0x%x for %sprimary device\n",
bios.location.legacy,
-entityIndex < 0 ||
xf86IsEntityPrimary(entityIndex) ? "" : "non-");
bios_location = bios.location.legacy;
vbiosMem = (unsigned char *)base + bios_location;
--- 309,314
***
*** 387,394
INTPriv(pInt)->vRam = xf86MapDomainMemory(pInt->scrnIndex,
VIDMEM_MMIO,
pInt->Tag, V_RAM, size);
! if (pInt->scrnIndex >= 0)
! pInt->ioBase = xf86Screens[pInt->scrnIndex]->domainIOBase;
}
static void
--- 370,376
INTPriv(pInt)->vRam = xf86MapDomainMemory(pInt->scrnIndex,
VIDMEM_MMIO,
pInt->Tag,
Re: multihead isa
Hello all;
The ati driver is the only one doing dynamic resource determination and
multiple ClaimFixedResources
calls for a single device. Following that model, I put together a
resource gathering scheme to allow
a single AddBusDeviceToConfig call per card. I tried it out with a VGA
Wonder, Graphics Ultra Pro,
and a Mach64, and the probe lists matched the claims that followed, so I
think I'm close. The changes
are all in atiprobe.c and at the end of this message.
All three cards control the mono resources when configured as color, so
I need a third class of vga
resources (color, mono, both). Ati cards also respond to aliases for the
standard ports, convincing
me to use the ChkConflict routines in xf86Bus.c rather than walking
through the lists myself. The only
external change needed with this is adding xf86AddBusDeviceToConfig in
loader/xf86sym.c, which
should probably be there anyway.
Enjoy
Lee
diff -bc atiprobe.c*
*** atiprobe.cFri Mar 26 12:10:36 2004
--- atiprobe.c.origTue Feb 24 17:19:09 2004
***
*** 1037,1051
static const IOADDRESS Mach64SparseIOBases[] = {0x02ECU, 0x01CCU,
0x01C8U};
CARD8 ProbeFlags[LongPort(SPARSE_IO_BASE) + 1];
- static resRange ATIResources[] = {
- { 0, 0, 0},/* 8514 or Mach64 */
- { 0, 0, 0},/* VGAWonder */
- _VGA_EXCLUSIVE, /* chosen by size */
- _HGA_EXCLUSIVE, /* overwritten later */
- _END
- };
- #defineRES_VGA_OFFSET2
-
unsigned long BIOSBase;
static const CARD8 ATISignature[] = " 761295520";
# define SignatureSize 10
--- 1037,1042
***
*** 2023,2087
#endif /* AVOID_CPIO */
{
- resRange *resPtr;
- int count;
-
ProbeSuccess = TRUE;
! if (pATI->VGAAdapter != ATI_ADAPTER_NONE)
! {
! resPtr =
! (pATI->Chip <= ATI_CHIP_18800_1) ?
! (pATI->SharedVGA ?
! resVgaSparseShared : resVgaSparseExclusive) :
! (pATI->SharedVGA ? resVgaShared : resVgaExclusive);
! for (count = 0; resPtr[count].type != ResEnd; ++count)
! ;
! memcpy(&ATIResources[RES_VGA_OFFSET], resPtr, (count + 1)
* sizeof(resRange));
! resPtr = &ATIResources[RES_VGA_OFFSET];
! }
! else/* no VGA, point to ResEnd */
! resPtr =
&ATIResources[(sizeof(ATIResources)/sizeof(ATIResources[0]))-1];
!
! if (pATI->CPIO_VGAWonder)
! {
! --resPtr;
! if (pATI->SharedVGA)
! resPtr->type = ResShrIoSparse | ResBus;
! else
! resPtr->type = ResExcIoSparse | ResBus;
! resPtr->rBase = pATI->CPIO_VGAWonder;
! if (pATI->Chip <= ATI_CHIP_18800_1)
! resPtr->rMask = 0x03FEU;
! else
! resPtr->rMask = 0xF3FEU;
!
! }
! if (pATI->ChipHasSUBSYS_CNTL == TRUE)
! {
! resRange *res8514 = pATI->SharedAccelerator ?
! res8514Shared : res8514Exclusive;
! --resPtr;
! for (count = 0; res8514[count].type != ResEnd; ++count)
! ;
! memcpy(resPtr, res8514, count * sizeof(resRange));
! }
! if ((pATI->Adapter == ATI_ADAPTER_MACH64) &&
! (pATI->CPIODecoding == SPARSE_IO))
! {
! --resPtr;
! if (pATI->SharedAccelerator)
! resPtr->type = ResShrIoSparse | ResBus;
! else
! resPtr->type = ResExcIoSparse | ResBus;
! resPtr->rBase = pATI->CPIOBase;
! resPtr->rMask = 0x03FCU;
! }
!
!
! pGDev = xf86AddBusDeviceToConfigure(ATI_DRIVER_NAME,
! pATI->PCIInfo ? BUS_PCI: BUS_ISA,
! pATI->PCIInfo ? pATI->PCIInfo : (void *)resPtr,
! ATI_CHIPSET_ATI);
if (pGDev)
{
/* Fill in additional information */
--- 2014,2022
#endif /* AVOID_CPIO */
{
ProbeSuccess = TRUE;
! pGDev = xf86AddDeviceToConfigure(ATI_DRIVER_NAME,
! pATI->PCIInfo, ATI_CHIPSET_ATI);
if (pGDev)
{
/* Fill in additional information */
End of atiprobe.c diffs
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Vesa Driver Probe
Hello all; The vesa driver probe/FindIsaDevice is doing a vga probe, not a vesa one. It should be calling a vbe routine to check for a vesa signature. What makes that hard to do is VBEInit/VBEExtendedInit requires an entityIndex, which is not available during configuration. This gets converted to a ScrnInfoPtr for use in a LoadSubModule call to do the actual probe. If the caller passes a non-NULL Int10 pointer, the LoadSubModule is skipped. That tied with a negative entityIndex might be a workable hack rather than altering the interface. Those that know more about how this works are welcome to find a more elegant solution. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vesa and ati driver problems
Marc Aurele La France wrote: if ((pATI->Adapter != ATI_ADAPTER_VGA) && ((pATI->Adapter != ATI_ADAPTER_8514A) || ((pATI->VGAAdapter != ATI_ADAPTER_VGA) && (pATI->VGAAdapter != ATI_ADAPTER_NONE Changing the second line to test pATI->ChipHasSUBSYS_CNTL will treat mach8 and mach32 as 8514 devices here. Yes, but I don't want it to do that. While you are correct in saying I don't currently support VGA-less adapters, I'd prefer to keep that decision in ATIPreInit(). That works for me as long as there's no separate 8514 driver as there was in 3.x. The third and fourth lines test if the VGA is disabled. It does more than that. This statement appears at a point where ATIProbe() has already collected all adapters it is interested in (including non-ATI VGA and/or 8514 clones), _and_ there is no XF86Config available. The intent of this statement is to prevent the driver from generating device sections for non-ATI adapters. This is independent of whether or not the adapter(s) actually provide(s) VGA. Good point. There's much more to the ativga vs vga decision than I can see with a vga-disabled gup. On a separate front, I don't want you to think that your work on ISA multihead is falling on deaf ears, as I am keenly interested in it. It is just that I currently don't have time to properly (re-)delve into it. I do however wish to be supportive and, towards that end, I'm attaching a hercules driver I wrote back in 1998, which I never integrated (no appropriate hardware). This pre-dates RAC and the xf86Match???Instances() scheme that so greatly complicated ISA multihead and ended up entrenching PCI's "supremacy" into the server. While I doubt this driver was functional even back then, my main purpose with it was to demonstrate how to use mibank to deal with HGA's oddball addressing of video memory. I'll take a look. I have a fully functional xf86Match???Instances() compliant one I wrote against 4.2. about 18 months ago. 4.3 was already out and I was bandwidth limited and not able/willing to get current, so nothing happened with it. As the ati driver is the only one to call AddDeviceToConfigure() directly rather than going through the Match???Instances() routines, I was hoping you were watching. I'm still sorting through sparse resource implications and getting the ati resource maps right. All three of my ati cards (VGA Wonder, GUP, mach64) stomp all over the hercules and the GUP and mach64 lock up when adaptec scsi controllers are present (which my thin client has). I'll have a refined set of proposed changes in the next few days. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: make install and nfs
David Dawes wrote: On Thu, Mar 18, 2004 at 01:36:13PM -0500, David Dawes wrote: On a thin client, one without development tools, it's `Cannot find a rule to build /usr/include/stdio.h' and similar failures during the dependency checks. The only way I see to stop these is for `make install' to not do dependency checks. If I'm blind and there are other choices, that's ok too. OK, for these external dependencies there probably isn't any other option. If nobody else has any input to add on this, we can go ahead with that change. I committed something based on your patch last night. That fixes installing from a read-only built tree for me. Let me know if you find any problems with it. It fails in xc/lib/X11 installing libX11: make[3]: Entering directory `/work/src/redhat/SOURCES/X440A/xc/lib/X11' install -c -m 0755 libX11.so.6.2 /usr/X11R6/lib /bin/sh: -c: line 2: syntax error: unexpected end of file make[3]: *** [install] Error 2 It looks like a fi-less if to me, three or four lines after $(INSTALL). My InstallSharedLibrary rule in lnxLib.rules looks like this: # define InstallSharedLibrary(libname,rev,dest) @@\ install:: @@\ MakeDir($(DESTDIR)dest) @@\ $(INSTALL) $(INSTALLFLAGS) $(INSTBINFLAGS) Concat(lib,libname.so.rev) $(DESTDIR)dest @@\ @SetSonameRev(rev); \ @@\ T=Concat($(DESTDIR)dest/lib,libname.so.$$S); \ @@\ if [ rev != $$S ]; then (set -x; \@@\ $(RM) $$T && $(LN) Concat(lib,libname.so.rev) $$T) @@\ @if $(SOSYMLINK); then (set -x; \ @@\ $(RM) Concat($(DESTDIR)dest/lib,libname.so); \@@\ $(LN) Concat(lib,libname.so.rev) Concat($(DESTDIR)dest/lib,libname.so)); fi With the $(RM) indented, my guess is the `fi' follows that line. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
vesa and ati driver problems
Hello all; A couple of things I found while sorting out multihead isa systems: The vesa driver's probe looks like this: /* VGA has one more read/write attribute register than EGA */ (void) inb(GenericIOBase + VGA_IN_STAT_1_OFFSET); /* Reset flip-flop */ outb(VGA_ATTR_INDEX, 0x14 | 0x20); CurrentValue = inb(VGA_ATTR_DATA_R); outb(VGA_ATTR_DATA_W, CurrentValue ^ 0x0F); outb(VGA_ATTR_INDEX, 0x14 | 0x20); TestValue = inb(VGA_ATTR_DATA_R); outb(VGA_ATTR_DATA_R, CurrentValue); /* Quit now if no VGA is present */ if ((CurrentValue ^ 0x0F) != TestValue) return -1; The last "outb" should be to VGA_ATTR_DATA_W rather than R. Probing without loading the vesa driver will do bad things (foreground = background) to your display. The ati driver does not do what you might expect when it finds a Graphics Ultra Pro with the VGA turned off. Configure sets up a screen and device for ati, but running the server gives the error "VGA is not available through this adapter." Since the README.ati says stand alone 8514 is not supported, the server is right and configure is wrong. The last test for a successful probe in atiprobe.c looks like this: if ((pATI->Adapter != ATI_ADAPTER_VGA) && ((pATI->Adapter != ATI_ADAPTER_8514A) || ((pATI->VGAAdapter != ATI_ADAPTER_VGA) && (pATI->VGAAdapter != ATI_ADAPTER_NONE Changing the second line to test pATI->ChipHasSUBSYS_CNTL will treat mach8 and mach32 as 8514 devices here. The third and fourth lines test if the VGA is disabled. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.4 on trailing edge hardware
Hello all;
While the changes I suggested earlier plus the hga driver allow X -configure
to create a multiheaded isa configuration, it probably isn't a surprise
that it crashes
during initialization. The crash happens at the bottom of setAccess in
xf86Bus.c:
/*
* If device is not under access control it is enabled.
* If it needs bus routing do it here as it isn't bus
* type specific. Any conflicts should be checked at this
* stage
*/
if (!pEnt->access->pAccess
&& (pEnt->entityProp & (state == SETUP ? NEED_VGA_ROUTED_SETUP :
NEED_VGA_ROUTED)))
((BusAccPtr)pEnt->busAcc)->set_f(pEnt->busAcc);
}
The crash happens because pEnt->busAcc is NULL for isa devices. Since
pAccess
is explicitly cleared up above, the question is should there be a test
for pEnt->busAcc
being NULL or should the VGA_ROUTED properties be turned off?
The code that sets the properties is in checkRoutingForScreens (also in
xf86Bus.c)
and looks like this:
vga = pEnt->busAcc;
pEnt->entityProp |= (state == SETUP
? NEED_VGA_ROUTED_SETUP : NEED_VGA_ROUTED);
if (state == OPERATING) {
if (pAcc->val.type & ResMem)
pEnt->entityProp |= NEED_VGA_MEM;
else
pEnt->entityProp |= NEED_VGA_IO;
}
Since I'm dealing with a real, pure isa machine and specifying exclusive
resources, the
concept of routing sounds wrong to me. Testing vga against NULL before
turning on the
VGA_ROUTED properties sounds right to me. With that test added, my
server works for
vesa (orchid fahrenheit) with hga and ati (vga wonder) with hga.
Any thoughts?
Enjoy
Lee
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: make install and nfs
Hello David; One install dependency I missed in my previous report is xc/lib/X11/xlibi18n/Xi18nLib.conf. Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rendition driver bug
Hello all; The rendition driver probe routine is freeing usedChips in the wrong place. It's allocated inside an if xf86GetPciVideoInfo and freed outside the block, so systems without a pci bus free an uninitialized pointer. Here's a diff of the proposed chasnge. Enjoy Lee *** rendition.cThu Mar 18 14:03:27 2004 --- rendition.c.origSat Jan 10 20:03:16 2004 *** *** 354,361 foundScreen=TRUE; } } - xfree(usedChips); } return foundScreen; } --- 354,361 foundScreen=TRUE; } } } + xfree(usedChips); return foundScreen; } ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: make install and nfs
David Dawes wrote: On Wed, Mar 17, 2004 at 06:55:21PM -0800, Lee Olsen wrote: Hello all; I now have a handle on what is going on and why, and some proposed chasnges to fix it. Here's a simplification of the install dependency chain from xc/lib/font/Makefile: install:: lib$(LIBNAME).a lib$(LIBNAME).a : $(SUBDIRS) $(SUBDIRS) : FRC @echo "making all in $(CURRENT_DIR)/[EMAIL PROTECTED]" @$(MAKE) -C $@ $(MFLAGS) $(PARALLELMFLAGS) CDEBUGFLAGS="$(CDEBUGFLAGS)" LDSTRIPFLAGS="$(LDSTRIPFLAGS)" all FRC : Since FRC never exists, it gets remade, forcing $(SUBDIRS) to be remade, echoing "making all in ..." and doing just that. To stop the rebuilding during an install, the dependency chains must be separated. Removing all dependencies on install:: targets does exactly that. What is the rebuilding in $(SUBDIRS) causing to get rebuilt? I see get rebuilt is the symlinks to xc/exports for the font modules. That can be fixed by moving where the link creation is done, so that it isn't a separate all:: target of its own. (I'm testing a patch that does this now.) On a fat client, one that has compilers and development headers and libraries, it's the link creations for libraries (100+) and drivers (30+) and the build.new stuff (1). On a thin client, one without development tools, it's `Cannot find a rule to build /usr/include/stdio.h' and similar failures during the dependency checks. The only way I see to stop these is for `make install' to not do dependency checks. If I'm blind and there are other choices, that's ok too. The links get rebuild in an `all' step after the target they point to is created, so I didn't consider that to be the problem. Only replacing them if they change might be nice. Enjoy Lee
Re: make install and nfs
Hello all; I now have a handle on what is going on and why, and some proposed chasnges to fix it. Here's a simplification of the install dependency chain from xc/lib/font/Makefile: install:: lib$(LIBNAME).a lib$(LIBNAME).a : $(SUBDIRS) $(SUBDIRS) : FRC @echo "making all in $(CURRENT_DIR)/[EMAIL PROTECTED]" @$(MAKE) -C $@ $(MFLAGS) $(PARALLELMFLAGS) CDEBUGFLAGS="$(CDEBUGFLAGS)" LDSTRIPFLAGS="$(LDSTRIPFLAGS)" all FRC : Since FRC never exists, it gets remade, forcing $(SUBDIRS) to be remade, echoing "making all in ..." and doing just that. To stop the rebuilding during an install, the dependency chains must be separated. Removing all dependencies on install:: targets does exactly that. Since these are double colon rules, one might think we are losing the "only execute if a dependency changed" feature associated with the code blocks. Since it appears everything depends on FRC, all installables are always updated and all install fragments are executed every time. Hence, removing the dependency clauses will not alter the execution. Minor changes to the InstallTarget family of rules in Imake.rules cover most situations. I added a new rule, InstallNamedTargetNoDep, and adjusted calls to InstallTarget and InstallNamedTarget appropriately. Unfortunately, since libraries are incvolved, there are minor changes for fifteen platform specific library rule files as well. These are all simple dependency deletions. I'm including diffs for Imake.rules and lnxLib.rules. I am not in a position to test any of the others. If you would prefer I dump this into bugzilla, I can do that. I figured suggesting changes to something as fundamental as Imake.rules might warrant some discussion first. Enjoy Lee *** lnxLib.rulesWed Mar 17 17:36:24 2004 --- lnxLib.rules.origWed Mar 17 18:47:30 2004 *** *** 112,118 */ # ifndef InstallSharedLibrary # defineInstallSharedLibrary(libname,rev,dest)@@\ ! install:: @@\ MakeDir($(DESTDIR)dest)@@\ $(INSTALL) $(INSTALLFLAGS) $(INSTBINFLAGS) Concat(lib,libname.so.rev) $(DESTDIR)dest @@\ @T=`echo Concat($(DESTDIR)dest/lib,libname.so.rev) | sed 's/\.[^\.]*$$//'`;\ --- 112,118 */ # ifndef InstallSharedLibrary # defineInstallSharedLibrary(libname,rev,dest)@@\ ! install:: Concat(lib,libname.so.rev) @@\ MakeDir($(DESTDIR)dest)@@\ $(INSTALL) $(INSTALLFLAGS) $(INSTBINFLAGS) Concat(lib,libname.so.rev) $(DESTDIR)dest @@\ @T=`echo Concat($(DESTDIR)dest/lib,libname.so.rev) | sed 's/\.[^\.]*$$//'`;\ *** *** 131,137 MIN=$$A.$$R # defineInstallSharedLibtoolLibrary(libname,rev,dest)@@\ ! install:: @@\ MakeDir($(DESTDIR)dest)@@\ @set +e; SetRevisions(rev); \@@\ set -xe; \@@\ --- 131,137 MIN=$$A.$$R # defineInstallSharedLibtoolLibrary(libname,rev,dest)@@\ ! install:: Concat(lib,libname.so) @@\ MakeDir($(DESTDIR)dest)@@\ @set +e; SetRevisions(rev); \@@\ set -xe; \@@\ *** *** 660,666 */ # ifndef InstallSharedLibrary # defineInstallSharedLibrary(libname,rev,dest)@@\ ! install:: @@\ MakeDir($(DESTDIR)dest)@@\ @if [ "$(JUMP_IS_HOST)" = YES ]; then \ (T=$(DESTDIR)dest/`echo $(JUMP_SO)|sed 's/\.[^\.]*$$//'`;\ --- 660,666 */ # ifndef InstallSharedLibrary # defineInstallSharedLibrary(libname,rev,dest)@@\ ! install:: $(JUMP_SA) $(JUMP_SO) @@\ MakeDir($(DESTDIR)dest)@@\ @if [ "$(JUMP_IS_HOST)" = YES ]; then \ (T=$(DESTDIR)dest/`echo $(JUMP_SO)|sed 's/\.[^\.]*$$//'`;\ *** Imake.rulesWed Mar 17 17:11:48 2004 --- Imake.rules.origTue Mar 16 18:12:38 2004 *** *** 67,73 * LibraryTargetName(libname) * LibraryTargetNameSuffix(libname,suffix) * InstallNamedTarget(step,srcname,flags,dest,dstname) - * InstallNamedTargetNoDep(step,srcname,flags,dest,dstname) * InstallTarget(step,file,flags,dest) * InstallLibrary(libname,dest) * MergeIntoInstalledLibrary(tolib,fromlib) --- 67,72 *** *** 1164,1182 #endif /* InstallNamedTarget */ /* - * InstallNamedTargetNoDep - Like InstallNamedTarget, but doesn't - * do dependency checks or rebuilding of target being installed. - * Allows users and environments incapable of building to install - */ - - #ifndef InstallNamedTargetNoDep - #define InstallNamedTargetNoDep(step,srcname,flags,dest,dstname)@@\ - step:: @@\ - MakeDir(
4.4 on trailing edge hardware
Hello all;
I have an ancient Hercules mono card and monitor that I'd like to use
with 4.4.
As with all ISA cards, it needs exclusive access to it's resources,
which are currently
claimed by various vga objects. Before putting anything in bugzilla, I
thought
listing my proposed changes here would uncover any oversights. The
actual hga
driver will come later.
There are two kinds of vga mono, one using a 15 pin analog monitor and
the other
using the 9 pin digital monitor used by mda and hercules cards. The
analog version
takes it's signal from the green component and from a driver standpoint
is a color
device, so modern and even most older cards should not be reserving the mono
resources. The following test:
if (inb(VGA_IN_STAT_0) & 1)
return (int)CHIP_VGA_GENERIC_MONO;
Should be enough to identify the true vga digital monochrome configuration.
This would go in the vga driver probe, and possibly others as well. I
have an ati
wonder 16 with 9 and 15 pin connectors for testing once I get 4.4 onto
that box.
Opinions on other drivers to check are welcome.
To configure multiple isa heads requires keeping track of which
resources are used by
each card, as is already done for pci cards. It's still first come,
first served, but no
longer first come, only one served.
Most of the changes are in hw/xfree86/common, with the above test added to
hw/xfree86/drivers/vga/generic.c and symbol table changes in
hw/xfree86/loader/xf86sym.c
Enjoy
Lee
---
Here are the diffs I think are appropriate:
diff -c xf86Resources.h*
*** xf86Resources.hTue Mar 16 08:26:15 2004
--- xf86Resources.h.origFri Feb 13 15:58:38 2004
***
*** 57,87
#define _VGA_EXCLUSIVE \
{ResExcMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
{ResExcMemBlock | ResBios | ResBus, 0x000B8000, 0x000B},\
{ResExcIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
#define _VGA_SHARED \
{ResShrMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
- {ResShrMemBlock | ResBios | ResBus, 0x000B8000, 0x000B},\
- {ResShrIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
-
- #define _VGA_EXCLUSIVE_MONO \
- {ResExcMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
- {ResExcMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
- {ResExcIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
- {ResExcIoBlock | ResBios | ResBus, 0x03C0, 0x03CF}
-
- #define _VGA_SHARED_MONO \
- {ResShrMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
{ResShrMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
{ResShrIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
! {ResShrIoBlock | ResBios | ResBus, 0x03C0, 0x03CF}
#define _VGA_SHARED_MEM \
{ResShrMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
{ResShrMemBlock | ResBios | ResBus, 0x000B8000, 0x000B}
#define _VGA_SHARED_IO \
{ResShrIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
/*
--- 57,81
#define _VGA_EXCLUSIVE \
{ResExcMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
+ {ResExcMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
{ResExcMemBlock | ResBios | ResBus, 0x000B8000, 0x000B},\
+ {ResExcIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
{ResExcIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
#define _VGA_SHARED \
{ResShrMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
{ResShrMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
+ {ResShrMemBlock | ResBios | ResBus, 0x000B8000, 0x000B},\
{ResShrIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
! {ResShrIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
#define _VGA_SHARED_MEM \
{ResShrMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
+ {ResShrMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
{ResShrMemBlock | ResBios | ResBus, 0x000B8000, 0x000B}
#define _VGA_SHARED_IO \
+ {ResShrIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
{ResShrIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
/*
***
*** 90,96
--- 84,92
*/
#define _VGA_EXCLUSIVE_UNUSED \
{ResExcUusdMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
+ {ResExcUusdMemBlock | ResBios | ResBus, 0x000B, 0x000B7FFF},\
{ResExcUusdMemBlock | ResBios | ResBus, 0x000B8000, 0x000B},\
+ {ResExcUusdIoBlock | ResBios | ResBus, 0x03B0, 0x03BB},\
{ResExcUusdIoBlock | ResBios | ResBus, 0x03C0, 0x03DF}
/*
***
*** 99,105
--- 95,103
*/
#define _VGA_SHARED_UNUSED \
{ResShrUusdMemBlock | ResBios | ResBus, 0x000A, 0x000A},\
+ {ResShrUusdMemBlock | ResBios |
Re: Make install and nfs
Marc Aurele La France wrote: On Mon, 15 Mar 2004, Lee Olsen wrote: I'm building 4.4 on one linux redhat 7.3 i686 box and installing on a much slower i486. Make World and make install on the local i686 box complete successfully, but make install on the 486 does not. Make install is run as root on the 486, which maps to nobody on the nfs mounted build tree. Make install seems to replace a number of symbolic links in the build tree, which it should not do. Make -i allows the installation to complete, but hides any real problems that might arise. A snippet from install.log: installing in lib/font... make[3]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font' making all in lib/font/bitmap... make[4]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font/bitmap' making all in lib/font/bitmap/module... make[5]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font/bitmap/module' rm -f ../../../../exports/lib/modules/fonts/libbitmap.a rm: cannot unlink `../../../../exports/lib/modules/fonts/libbitmap.a': Permission denied make[5]: *** [all] Error 1 The interesting part is installing in lib/font becomes making all in it's subdirectories, instead of just installing. Checking the installation log on the server, the same links are rebuilt at the same spot, but root has the ability to do the replacements. I can't compare with 4.3, but 4.2.0 does the same thing, so this is clearly not new (or critical). Your NFS client and NFS server have a different notion of what time it is. Fix that and you'll be fine. Um, no. As I said before, the same link replacements happen on local build trees during a make install. The difference being root has write access on local drives and you don't get any errors. My nfs clients use rdate to synchronize their their notions of time with my server during the boot process, as I've stepped in that hole before. Enjoy Lee
Make install and nfs
Hello all; I'm building 4.4 on one linux redhat 7.3 i686 box and installing on a much slower i486. Make World and make install on the local i686 box complete successfully, but make install on the 486 does not. Make install is run as root on the 486, which maps to nobody on the nfs mounted build tree. Make install seems to replace a number of symbolic links in the build tree, which it should not do. Make -i allows the installation to complete, but hides any real problems that might arise. A snippet from install.log: installing in lib/font... make[3]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font' making all in lib/font/bitmap... make[4]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font/bitmap' making all in lib/font/bitmap/module... make[5]: Entering directory `/work/src/redhat/SOURCES/X440/xc/lib/font/bitmap/module' rm -f ../../../../exports/lib/modules/fonts/libbitmap.a rm: cannot unlink `../../../../exports/lib/modules/fonts/libbitmap.a': Permission denied make[5]: *** [all] Error 1 The interesting part is installing in lib/font becomes making all in it's subdirectories, instead of just installing. Checking the installation log on the server, the same links are rebuilt at the same spot, but root has the ability to do the replacements. I can't compare with 4.3, but 4.2.0 does the same thing, so this is clearly not new (or critical). Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Problems with xf86cfg on vesa and vga
These drivers default to 320x200, but the xf86cfg resources request a minimum of 320x400. Needless to say, "Ok", "Cancel", etc wind up off the bottom of the screen with no way to scroll down to them. You need to have these drivers for unrecognized hardware, old or new, and the config tool needs to work on all the supported drivers. If you can't configure in 320x200, with or without scroll bars, force these drivers to use text mode (which works great). Enjoy Lee ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
hercules driver for 4.x
The attachments are the pieces I used to build the hga driver for
hercules cards. The Imakefile was cloned
from the one for vesa and probably has extra cruft, but it does the job.
Thes files expect to be in hw/xfree86/drivers/hga. You will need the
resource conflict fixes I posted earlier to get it running.
Don't forget to add hga to your driver list in site.def if you want it
built automatically.
If you run linux and use mdacon, there are some interaction issues.
XFree86 switches the active
console to an unused one, but you have two in use, so one is exposed to
console driver activities.
Bringing up a dual headed X from an mda console steps through a console
driver bad pointer when X
terminates (at least it does on Redhat 7.3, 2.4.18-3), leaving stuck
displays. Ctrl-alt-del still works,
but thats about it.
Enjoy
Lee Olsen
[EMAIL PROTECTED]
/*
* Copyright 2003 by Lee Olsen [EMAIL PROTECTED]
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of Lee Olsen not be used in advertising or publicity
* pertaining to distribution of the software without specific, written
* prior permission. Lee Olsen makes no representations about the suitability
* of this software for any purpose. It is provided "as-is" express or
* implied warranty.
*
* LEE OLSEN DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO
* EVENT SHALL LEE OLSEN BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
* DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
* PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
* ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
* THIS SOFTWARE.
*/
#ifndef _HGA_H_
#define _HGA_H_
/* All drivers should typically include these */
#include "xf86.h"
#include "xf86_OSproc.h"
#include "xf86Resources.h"
/* All drivers need this */
#include "xf86_ansic.h"
#include "compiler.h"
#if 0
/* Drivers for PCI hardware need this */
#include "xf86PciInfo.h"
/* Drivers that need to access the PCI config space directly need this */
#include "xf86Pci.h"
#endif
/* ShadowFB support */
/* from hw/xfree86/shadowfb, not miext/shadow */
#include "shadowfb.h"
/* bank switching */
#include "mibank.h"
#if 0
/* Dga definitions */
#include "dgaproc.h"
#include "xf86Resources.h"
#include "xf86RAC.h"
#endif
#include "xf1bpp.h"
#include "fb.h"
#include "mfb.h"
#define HGA_VERSION 4000
#define HGA_NAME"HGA"
#define HGA_DRIVER_NAME "hercules"
#define HGA_MAJOR_VERSION 0
#define HGA_MINOR_VERSION 1
#define HGA_PATCHLEVEL 0
#ifdef CSRG_BASED
#define MONOBASE 0xFF00
#else
#define MONOBASE 0xF000
#endif
/*
* Define the generic HGA I/O Ports
*/
#define HGA_INDEX 0x3B4
#define HGA_DATA0x3B5
#define HGA_MODE0x3B8
#define HGA_STATUS 0x3BA
#define HGA_CONFIG 0x3BF
#define DSP_VSYNC_MASK 0x80
#define DSP_ID_MASK 0x70
#define BITS_PER_GUN 1
#define COLORMAP_SIZE 2
#define HGA6845MapBase ((unsigned char *)0xB)
#define HGA6845MapSize 0x8000
#define HGA6845ScanLineWidth720
#define HGA6845HDisplay 720
#define HGA6845VDisplay 348
/*XXX*/
typedef struct {
unsigned char config; /* write only conf register at port 0x3BF */
unsigned char mode; /* write only mode register at port 0x3B8 */
unsigned char tbl[16];
} hga6845Rec, *hga6845Ptr;
typedef struct _HGARec
{
EntityInfoPtr pEnt;
CARD16 major, minor;
GDevPtr device;
#if 0
pciVideoPtr pciInfo;
PCITAG pciTag;
#endif
miBankInfoRec bank;
int curBank, bankSwitchWindowB;
CARD16 maxBytesPerScanline;
int mapPhys, mapOff, mapSize; /* video memory */
void *base, *VGAbase;
hga6845Ptr state, pstate; /* Video state */
int statePage, stateSize, stateMode;
int page;
Bool shadowFB, primary;
CARD8 *textContents;
CARD8 *shadowPtr;
CARD32 shadowPitch;
CARD32 windowAoffset;
CARD32 frameX;
CARD32 frameY;
CloseScreenProcPtr CloseScreen;
OptionInfoPtr Options;
} HGARec, *HGAPtr;
typedef enum save_restore {
MODE_SAVE,
MODE_RESTORE
} SaveRestoreFunction;
#endif /* _HGA_H_ */
/*
* Copyright 2003 by Lee Olsen [EMAIL PROTECTED]
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the a
Resource sharing crash in dual head ISA box using 4.2.0
While creating a hercules driver for 4.2.0, I ran into some resource
sharing issues. Gecause the vga
and vesa drivers claim the monochrome ports and memory, I initially
declared them shared in the
hercules driver. This leads to a crash in xf86Bus.c down around line
2080 (last line of setAccess).
Protecting this busAcc->set_f call the same way the other set_f calls
are protected fixes the problem.
Since the hercules driver really does require exclusive use of the mono
resources, the vga and vesa
conflicts should be fixed in those drivers. The vesa fix is simpler
because there are no monochrome
vesa modes, it just needs to have the resource list in xf86Resources.h
and xf86Bus.c adjusted. The vga
driver needs to choose which resource set it needs based on the same
function the vgaHW module
determines the IObase, which is reading bit 0 of the misc out register
(0x3CC).
The last change is adding the new resource symbols to the loader seed
file, xf86sym.c.
I attached context diffs for the changes described above. The hercules
driver will be in a separate message.
Enjoy
Lee Olsen
[EMAIL PROTECTED]
*** generic.c Wed Mar 19 14:29:01 2003
--- generic.c.orig Tue Mar 18 13:16:52 2003
***
*** 206,232
enum GenericTypes
{
! CHIP_VGA_GENERIC,
! CHIP_VGA_MONOCHROME
};
/* Supported chipsets */
static SymTabRec GenericChipsets[] =
{
! {CHIP_VGA_GENERIC, "generic color"},
! {CHIP_VGA_MONOCHROME, "generic monochrome"},
{-1, NULL}
};
static PciChipsets GenericPCIchipsets[] = {
! { CHIP_VGA_MONOCHROME, PCI_CHIP_VGA, RES_SHARED_VGA_MONO },
! { CHIP_VGA_GENERIC, PCI_CHIP_VGA, RES_SHARED_VGA_COLOR },
{ -1, -1, RES_UNDEFINED },
};
static IsaChipsets GenericISAchipsets[] = {
! {CHIP_VGA_MONOCHROME, RES_EXCLUSIVE_VGA_MONO},
! {CHIP_VGA_GENERIC, RES_EXCLUSIVE_VGA_COLOR},
{-1,0 }
};
--- 206,228
enum GenericTypes
{
! CHIP_VGA_GENERIC
};
/* Supported chipsets */
static SymTabRec GenericChipsets[] =
{
! {CHIP_VGA_GENERIC, "generic"},
{-1, NULL}
};
static PciChipsets GenericPCIchipsets[] = {
! { CHIP_VGA_GENERIC, PCI_CHIP_VGA, RES_SHARED_VGA },
{ -1, -1, RES_UNDEFINED },
};
static IsaChipsets GenericISAchipsets[] = {
! {CHIP_VGA_GENERIC, RES_EXCLUSIVE_VGA},
{-1,0 }
};
***
*** 361,370
if ((CurrentValue ^ 0x0F) != TestValue)
return -1;
#endif
! if (inb(0x3CC) & 1)
! return (int)CHIP_VGA_GENERIC;
! else
! return (int)CHIP_VGA_MONOCHROME;
}
static Bool
--- 357,363
if ((CurrentValue ^ 0x0F) != TestValue)
return -1;
#endif
! return (int)CHIP_VGA_GENERIC;
}
static Bool
*** vesa.c Tue Mar 18 13:54:01 2003
--- vesa.c.orig Wed Mar 5 05:55:36 2003
***
*** 119,130
};
static PciChipsets VESAPCIchipsets[] = {
! { CHIP_VESA_GENERIC, PCI_CHIP_VGA, RES_SHARED_VGA_COLOR },
{ -1, -1,RES_UNDEFINED },
};
static IsaChipsets VESAISAchipsets[] = {
! {CHIP_VESA_GENERIC, RES_EXCLUSIVE_VGA_COLOR},
{-1,0 }
};
--- 119,130
};
static PciChipsets VESAPCIchipsets[] = {
! { CHIP_VESA_GENERIC, PCI_CHIP_VGA, RES_SHARED_VGA },
{ -1, -1,RES_UNDEFINED },
};
static IsaChipsets VESAISAchipsets[] = {
! {CHIP_VESA_GENERIC, RES_EXCLUSIVE_VGA},
{-1,0 }
};
*** xf86Bus.c Wed Mar 19 13:46:50 2003
--- xf86Bus.c.orig Sat Oct 27 20:33:17 2001
***
*** 53,62
resPtr ResRange = NULL;
/* predefined special resources */
! resRange resVgaExclusive[] = {_VGA_EXCLUSIVE_COLOR, _END};
! resRange resVgaShared[] = {_VGA_SHARED_COLOR, _END};
! resRange resVgaExclusiveMono[] = {_VGA_EXCLUSIVE_MONO, _END};
! resRange resVgaSharedMono[] = {_VGA_SHARED_MONO, _END};
resRange resVgaMemShared[] = {_VGA_SHARED_MEM,_END};
resRange resVgaIoShared[] = {_VGA_SHARED_IO,_END};
resRange resVgaUnusedExclusive[] = {_VGA_EXCLUSIVE_UNUSED, _END};
--- 53,60
resPtr ResRange = NULL;
/* predefined special resources */
! resRange resVgaExclusive[] = {_VGA_EXCLUSIVE, _END};
! resRange resVgaShared[] = {_VGA_SHARED, _END};
resRange resVgaMemShared[] = {_VGA_SHARED_MEM,_END};
resRange resVgaIoShared[] = {_VGA_SHARED_IO,_END};
resRange resVgaUnusedExclusive[] = {_VGA_EXCLUSIVE_UNUSED, _END};
***
*** 2079,2087
if (!pEnt->access->pAccess
&& (pEnt->entityProp & (state == SETUP ? NEED_VGA_ROUTED_SETUP :
NEED_VGA_ROUTED)))
! if (((BusAccPtr)pEnt->busAcc)
!&& ((BusAccPtr)pEnt->busAcc)->set_f)
! ((BusAccPtr)pEnt->busAcc)->set_f(pEnt->busAcc);
}
--- 2077,2083
4.2.0 vesa depth 4 broken
The death of a disk drive on my old 486 gave me the opportunity to upgrade the software (Suse 6.1) to something more contemporary (redhat 7.3). This encouraged yhe upgrade of XFree86 from 3.3.x to 4.2.0. In 3.3.x, to run a dual headed system, the color card was limited to mono or 4 bit, so those were my initial tests. The monitor on this box is a MultiSync II, which was old when the 486 was new. The vesa driver is more flexible in locating clocks and agreed to drive the monitor at [EMAIL PROTECTED] That's probably enough history. Running with 4 bit depth, the shadow buffer size computation uses 4 bits per pixel, but the pixmap format says to use 8 and that is what shadowUpdatePlanar4 uses, walking off the end of the buffer and video memory, causing a signal 11. Doubling the size of the buffer stops the signal 11, but the screen is double width, wrapped on top of itself. Halving the size in the pixmap format fixes the window width problem, but funts are still double width. Turning off the shadow buffer solves the problem. Depths 8 and 16 work great, and with the new architecture in 4.x, the requirement of sharing memory models across displays goes away, so I'm not likely to use 4bpp again. Getting the hercules running will be a later message. Enjoy Lee [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
