[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Analysis On Getting Rid Of xresprobe



On Sat, Dec 08, 2007 at 05:34:34PM -0500, David Nusinow wrote:
> One issue is that sometimes the monitor will fail to do a proper
> DDC on one occasion, but succeed on another.

I saw this happening when I was doing some laptop/projector testing a
few weeks ago.  It seemed that sometimes it'd return EDID of one, and
sometimes the other.  It seemed to make a difference whether the
projector was attached during X start or not.

This opens a bigger question - how exactly does DDC handle multi-monitor
situations?  From what I could tell of xresprobe there's sort of a
single-monitor assumption woven in there, but I couldn't tell how deeply
that assumption goes.  I looked at docs for the DDC call, but it wasn't
very illuminating; my assembly-fu is not strong though, so I might have
missed something obvious.

> > I'm concerned about this because the way things are scaling, this is
> > going to become a larger and larger sore spot for all of us.  Maybe we
> > need to start (threatening to?) deprecate extremely out of date drivers,
> > or become more proactive at recruiting driver maintainers, or even just
> > publish task lists for them?
> 
> Yeah, pci-rework will be the first real breaking point for the drivers.
> Previously they all worked fine with the server updates. I could see SuSE
> or Redhat porting a bunch of the legacy drivers so as to not piss off their
> customers, but we may not want to wait around that long. Porting over to
> pci-rework isn't too terribly difficult[0], but it does need to be done if
> these drivers are going to survive. Otherwise we'll have to simply EOL the
> drivers and tell people to use old versions or buy new hardware :-\
> 
> [0] http://wiki.x.org/wiki/PciReworkHowto

Thanks for the link.

Of course, some of the companies picking Linux are doing so for cost
reasons (particularly in the embedded and educational areas), and
similar thinking also leads them to cheap low-end hardware options that
often include graphics chips that require the less mainstream drivers.
My thinking is that having TODO lists in our back pockets (in addition
to EOLing the drivers) would help here - if the company has already
proceeded too far and can no longer alter their hardware and OS version
choices, that would communicate the NRE work they'd need to fund.
Ideally, future companies will do research prior to settling on their
graphics chip choice, and would be able to use the TODO and EOL info to
assist in their selection criteria, and either select better maintained
options, or budget/arrange for the maintenance work.

Bryce



Reply to: