Egbert Eich wrote:
Hello Lee,The problem is resource conflicts are fatal. If a vendor specific Probe() succeeds, then the vesa and vga
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.
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() intoThis will be a big help.
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.
> > Without hardware to test it, you may not want to add the driver to the > source tree, but it would beI had not considered third party drivers. It does not need to go away, nor it's reference in loader/xf86sym.c.
> 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).
2. You are splitting the mono and color resources. This is good,There are three sets of resource blocks in xf86Bus.c, color, mono, and both. The shorthand defines
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.
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 the registers,
which the X -configure won't detect, or it might work.
I keep the hercules cards around for the extra parallel port, which I use for pic programming. If
I need that capability on my PCI box, I'll look at PCI vs ISA resources. Until then, this looks fine.
Enjoy Lee
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
