VIA drm compatibility update.
Hi! Code for bringing the VIA 2d driver up to date with the drm module currently in dri.sourceforge.net cvs has been submitted under bugzilla 1327 /Thomas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VIA drm compatibility update.
--- Thomas Hellstrom [EMAIL PROTECTED] wrote: Hi! Code for bringing the VIA 2d driver up to date with the drm module currently in dri.sourceforge.net cvs has been submitted under bugzilla 1327 /Thomas Thomas, If you'd like to keep an up-to-date 2D driver in DRI cvs that's in sync with the 3D driver and DRM, you are more than welcome to. The changes there will gets synced with Xfree86 when the trees get periodically merged. We can also provide nightly snapshots along with the other DRI drivers. Alex __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
David Dawes writes: My point is that this is just one example of a class of problem that is not unique to the vesa driver. Therefore solving it within the vesa driver, while useful, does not solve the underlying problem. Also, this class of problem is not limited to vintage hardware. With the configuration work I'm doing, I'm interested in dealing with the underlying problems. Right this class of problems includes all cases where drivers may support a certain chipset but not the specific combination of hardware found on a card - like DACs. In this case an automatic configuration mechanism needs to make decisions about a possible fallback path and this can only be done after PreInit() returns - like many other cases where a specific mode may not be supported and the configuration mechanism has to decide about possible tradeoffs and fallsbacks. Lee was calling for a change in paradigms in '-configure' to overcome its weaknesses. It attempts to detect any hardware it can find provided it is either generically detectable or there is a device specific probe for it. It doesn't guarantee that all hardware it detects will run. It will also fail if a certain HW cannot be probed generically or has a specific probe function. The future may however be an automatic configuration process that dynamically attempts to find the optimally possible settings. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multihead ISA
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. 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. 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). 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. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
On Sun, Apr 04, 2004 at 12:03:34AM +0200, Egbert Eich wrote: David Dawes writes: My point is that this is just one example of a class of problem that is not unique to the vesa driver. Therefore solving it within the vesa driver, while useful, does not solve the underlying problem. Also, this class of problem is not limited to vintage hardware. With the configuration work I'm doing, I'm interested in dealing with the underlying problems. Right this class of problems includes all cases where drivers may support a certain chipset but not the specific combination of hardware found on a card - like DACs. In this case an automatic configuration mechanism needs to make decisions about a possible fallback path and this can only be done after PreInit() returns - like many other cases where a specific mode may not be supported and the configuration mechanism has to decide about possible tradeoffs and fallsbacks. As I said, the latest autoconfig (version 1.2 of X-Oz automatic configuration for XFree86) is a first cut of this, greatly improving the fallback mechanism. The future may however be an automatic configuration process that dynamically attempts to find the optimally possible settings. I'm continuing to make progress on this. It is possible to get some way without major driver structure changes, but to do it right will need reworking of some of the driver interfaces. I'm not sure yet if that will be material for XFree86 4.5 or a later release. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Mode Validation question
Lets say you have a DFP with a fixed resolution and therefore can't run modes with an HDisplay or VDisplay beyond that. What's the most efficient way to validate those modes? I see that xf86ValidateModes will check pScrn-maxHValue and pScrn-maxVValue for HTotal and VTotal and it supports maximum virtual desktop sizes, but I see no facility for limiting HDisplay and VDisplay. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mode Validation question
On Sun, Apr 04, 2004 at 02:48:54PM -0700, Mark Vojkovich wrote: Lets say you have a DFP with a fixed resolution and therefore can't run modes with an HDisplay or VDisplay beyond that. What's the most efficient way to validate those modes? I see that xf86ValidateModes will check pScrn-maxHValue and pScrn-maxVValue for HTotal and VTotal and it supports maximum virtual desktop sizes, but I see no facility for limiting HDisplay and VDisplay. You can do it in the driver's ValidMode() function. I'd also recommend that in the absence of DDC/EDID information for the panel, that the driver set the default monitor parameters to accomodate the maximum mode at a suitable refresh (60Hz?). The neomagic driver does both of these things. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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 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.
Re: XFree86 4.4.0 RC2 xf86cfg Solaris build failure
On Thu, 8 Jan 2004, David Dawes wrote: Is strings.h needed here for Solaris? I didn't find it necessary for the Solaris builds I've tried. It provides a prototype for keyboard-cfg.c's and monitor-cfg.c's use of bzero(). An alternative would be to change them to memset()'s. Code that uses bzero() should include X11/Xfuncs.h, which in most cases defines it in terms of memset(). I've just committed exactly this. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
