[Openchrome-devel] [Bug 94259] No mouse cursor (invisible) with dual monitors and DVI/VGA "Y" cable, no display on DVI

[bugzilla-daemon at freedesktop.org]

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

--- Comment #18 from Kevin Brace <kevinbrace at gmx.com> ---
(In reply to Eric from comment #8)

Hi Eric,

> Tested with current openchrome as of this date
> Current setup: Wyse Vx0LE 
> lspci shows: [S3 Unichrome Pro] (rev 01), 
> Dual HP LP2065 4:3 monitors, one DVI mode, one VGA mode (DVI/VGA "Y"
> adapter) 1600x1200 60hz. 
> Kernel 3.2.0-101-generic
> 
> Previously when you ONLY had the VGA connected, it would boot fine with
> mouse cursor present.
> 
> When testing with the recent openchrome, the mouse cursor is not present
> when booted with ONLY the VGA connected.
> 
> ARandR shows a NEW Output LVDS-1 as active. If you fool around till you can
> uncheck "Outputs> LVDS-1> Active" and Apply, you get the mouse back. 
> 
> LVDS-1 only haS 1 resoulution, 1600x1200. 
> 
> This board has some un-populated connector pads on it. I don't know if it is
> a false detection or if the board has some un-used hardware on it.
> 
> When booted with BOTH VGA and DVI connected, it behaves as it did with
> previous versions as originally described, except that the LVDS-1 now shows
> up, but NOT "active"

First of all, it appears that there has been some regression in terms of the
device driver behavior.
I apologize for that.
One thing I will say about my commit policy is that I do my own testing with
the equipment I have on hand before I do a commit.
At least with the netbook laptop I have, DVI is working.
However, this DVI is from an integrated TMDS transmitter, and your system has
an external TMDS transmitter.
    I can definitely say that fixing existing OpenChrome bugs is taking a lot
longer than I envisioned a month ago.
The reality is, OpenChrome code base has many features that are quite
undesirable when it comes to maintaining reliable code.
For example, the previous developers had a large known device table in the code
which was very hard to maintain since it required constant reporting by users
to keep it up to date.
I discontinued this completely.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=9822064f0cf2675fbaa1390b86a83e5bdd61fbf2

Furthermore, I discontinued legacy user mode setting and VESA BIOS Extension
user mode setting.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=d6a65df0e31657495fbdd488c06780b8b33fdccc

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=b48fb4176c96b04f5de8b2ee20f55af404ba0db7

Since there is no known device table anymore, the display resources are now
going to be detected automatically (the only exception is OLPC XO-1.5 laptop).
OpenChrome does have some code that allows automatic detection of display
resources beyond using I2C bus, but it is far from perfect.
This is why things regressed in your system.
    Now that I have gotten rid of "rot" from the code (i.e., known device
table, legacy user mode setting, and VBE mode setting), I can now clean up the
display resource detection code more freely, and I hope that this will
eventually lead to fixing your problem down the road.

-- 
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/20160319/1fb52080/attachment.html>