[Openchrome-devel] [Bug 91966] No signal to monitor with X and openchrome using VX855 chipset graphics

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91966

--- Comment #295 from Kevin Brace <kevinbrace at gmx.com> ---
(In reply to HuangRan from comment #294)

Hi Frank,

I am not sure what I can do now.
You may have to go back further when it comes to going back in the commit, and
that's all I can say for now.
I do not really recall which OpenChrome with which commit ID worked with Wyse
V90LE.
    As far as I am concerned, the compiled device driver is working with
several of the test platforms I have.
Otherwise, I will not do a commit in the first place.
That being said, for the current master brach head (Commit ID
d6a65df0e31657495fbdd488c06780b8b33fdccc), the code is now running through the
LVDS based flat panel detection code, and unfortunately, the previous
developers were doing some kind of a weird backdoor opeation to figure out
("guess" is a better term) what the flat panel native screen resolution is if
the flat panel does not support I2C bus.
Unfortunately, this causes problems with those that do not have a flat panel.
After studying VIA Technologies written frame buffer device driver code over
the past few days, I found a way to deal with this situation, and in fact,
OpenChrome already had the code to support this.
But for some reason, the previous developers were not really using this, so I
got rid of that weird backdoor code that tries to "guess" the flat panel native
screen resolution, and now the flat panels without I2C bus can be detected
properly.
However, one problem remains, and the problem is, I need a reliable way to
figure out if a flat panel is connected in the first place, and if a flat panel
is not connected, the code should not bother trying to figure out the flat
panel native screen resolution.
I2C bus cannot be used for this purpose since some flat panels do not support
I2C bus in the first place.


> Hi Kevin,
> 
>   I gave a try with SHA id "802544370dd827ed3488965e39804e3cb630888a" code,
> but unfortunately both VGA/DVI ports can not enter into desktop too.
>   Nearly same Xorg log for them. No EDID information for VGA port of my
> V90LE board.
> 
> Thanks,
> Frank
> 
> (In reply to HuangRan from comment #293)
> > Hi Kevin,
> > 
> >    Okay, let me try it next week and tell the result here.
> > 
> > Thanks,
> > Frank
> > 
> > (In reply to Kevin Brace from comment #290)
> > 
> > > Sorry for not really being on top of the problem you and Eric have been
> > > reporting.
> > > I have been consumed with other OpenChrome related activities for the past
> > > few days.
> > > I think what happened was that when I fixed the DVI to VGA adapter
> > > regression Christopher reported previously (in September 2015), I started to
> > > notice that my Sylvania gnet 13001 netbook's flat panel started to go wrong.
> > > This commit is the one before the fix for the flat panel that does not come
> > > with an I2C bus.
> > > 
> > > https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/
> > > ?id=802544370dd827ed3488965e39804e3cb630888a
> > > 
> > > Try that code ("git reset --hard 802544370dd827ed3488965e39804e3cb630888a"),
> > > and see what happens.
> > > I will tell Eric about this temporary if it works.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20160328/5f08275d/attachment.html>