On Tue, Jan 17, 2006 at 01:02:43PM +0100, Sven Luther wrote: > On Tue, Jan 17, 2006 at 11:55:49AM +0100, Frans Pop wrote: > > The description also says it only works on i386 (including AMD64 I > > presume) and ppc. > > Well, the ppc uses the OF device-tree, and if this doesn't work falls back to > parsing the /sys fbdev tree. This would work for all arches, but only for > those fbdev drivers supporting it. I know of radeonfb only right now, haven't > looked in a while. Also, it obviously only works in fbdev mode. Not sure about > vesafb, and if it provides the DDC information. > > This could (and should if i remember the discussions of the fbdev authors > right) be fixed in the corresponding fbdev drivers.
Yes, but you don't want to depend on accelerated framebuffer drivers, particularly if you want to use accelerated X. In addition, most of the X drivers are unmaintained, let alone the framebuffers. Let's not walk that path. > > It thus has a limited (though growing) application and other types of > > systems will also need to be supported (probably using current manual > > resolution/frequency selection methods). > > Sure, the ideal would be for xresprobe to either work and give the right data, > for aall heads if posssible, or fail and inform the caller of the fail so the > caller can do the right thing. So what do you do on a laptop where you can't get any EDID for the external head? What do you do in the case where you have two cards (let's say, one integrated and a discrete one that you actually use), where only one is connected? And so on, and so forth. I think it's better to get something up usefully than to insist on this ridiculous ideal of 'we must find out all information for every display', or nothing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
