<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics" href="https://bugs.freedesktop.org/show_bug.cgi?id=91966#c302">Comment # 302</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics" href="https://bugs.freedesktop.org/show_bug.cgi?id=91966">bug 91966</a> from <a class="email" href="mailto:huangran@iscas.ac.cn" title="HuangRan <huangran@iscas.ac.cn>"> HuangRan</a> <pre>Hi Kevin, (In reply to Kevin Brace from <a href="show_bug.cgi?id=91966#c301">comment #301</a>) > Okay, some times I do have to disappear for several days to get something > done. > This is why I sometimes do not reply to your comments for several days. > Sorry about that. I can understand that. Especially for graphics driver. Sometimes, we need some days to learn the new stuff. For example, right now I am learning VIA's close driver open source part. > Anyway, after researching what to do with the LVDS flat panel automatic > detection issue, I believe I came up with a good enough solution. > Apparently, VIA uses scratch pad registers in their CRT register section to > pass the presence of a flat panel and what native resolution the panel > supports (I will call this panel ID.). > They allow the user to alter these values via BIOS setup (I have several > mainboards that support this feature.), and in fact, the code they have > written actually uses these feature. > I was reading James Simmons' DRM code, and in fact, that is what is > happening. > I already experimented with the panel ID, and it works with my netbook that > comes with an 800 X 480 screen resolution flat panel. As I have asked before, does DVP(display video port) is related to LVDS? As I have seen some code in closed drive, it seems DVP has something relationship with LVDS. For scratch pad registers, do you mean the hot plug detection bits? Which part of code you are checking with in DRM code? > I will write the code to figure out the presence of a flat panel tomorrow (a > few lines of code), and hope to commit it in the next few days. > Okay, is the mouse cursor working with the DVI coming from VT1632A? As I wrote before, right now only KMS mode on my platform can work with openchrome. For pure UMS(xf86-video-openchrome), I can not go into the desktop. For KMS, I can confirm that mouse cursor is working, it should use DRM's HW cursor's code. So I am not sure for UMS case with HW cursor. But I have make one guy of my team look into this HW cursor issue. > Eric was reporting that it was not showing up on the screen. > If it works, I will not disable the use of it (I was thinking of disable the > use of for Version 0.4.0 release for the sake of stability.). > Assuming there aren't any more serious issues, I might be able to release > OpenChrome Version 0.4.0 within a month. > Since I have a good enough solution for the flat panel detection, and this > was the culprit of causing display detection issues within the past few > weeks, assuming that the solution works, there will not be a Version 0.3.4 > release. > When I think we are reaching a RC (Release Candidate) stage, I will send out > an e-mail about it so that interested people can test the code before the > official release. > In the future, the version number will go up faster, especially the patch > level number (i.e., Version 0.4.("patch level")). Got it. Please go ahead. By the way, for drm-openchrome repository, have you gotten the previlege to do the commit? How about our patch for "AGP detection" issue? Thanks, Frank</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>