Could you please attach the X log from at least the VGA run ? And possibly also the DVI run, although that is probably not a setup that could be made to work that easily. Created attachment 118249 [details]
Xorg.0.log from initial bootup
Created attachment 118250 [details]
xerrs.log from initial bootup
OK, I've attached /var/log/Xorg.0.log and /tmp/xerrs.log from an initial bootup, no savefile (as if the system had just had TahrPup installed). This is with my compiled driver (openchrome_drv.so and openchrome_drv.la were the files produced), over VGA to the Dell 17" screen with native 1280x1024 resolution. Ignore the messages, please, about missing modesetting (etc) drivers -- I removed them to force it to use openchrome. If I leave them in, it seems to want to default to 'modesetting' which just breaks everything when it runs... Do you also want me to bring in the same logs from the version of 'openchrome' that ships with TahrPup? I can do that if you'd like. Created attachment 118274 [details]
xerrs.log from Precise 5.7.1 Retro first boot
Created attachment 118275 [details]
Xorg.0.log from Precise 5.7.1 Retro first boot
Now this is potentially rather interesting. For reasons I can't entirely explain myself, I booted a much older Puppy (Precise Puppy 5.7.1 Retro) on the target system, to see what would happen. It got to a desktop. If I'm reading the logs correctly, it's using version 0.2.904 of openchrome. I'm at a bit of a loss here, but my best guess is that something changed between that version and the newer 0.3.3 version used in TahrPup -- a change, whatever it may be, that inadvertently broke VX855 support. I've uploaded those logs, so I think, at this point, I'll wait for you guys to pore them over and try to make sense of what I just did and typed... Ok, so the display is not detected and thus not configured. Could you please try with git master ? This bug might be addressed already. I'm working on it! Got a stupid issue with the timezone not being set properly -- almost everything in Puppy is desktop-oriented, to the point that the command line is almost crippled. Since I can't get a GUI on this system, I'm limited to the command line, and that makes everything so much harder. I'll get it either tonight or tomorrow, and update again at that point. Created attachment 118329 [details]
xerrs.log from Git-built driver
Created attachment 118330 [details]
Xorg.0.log from Git-built driver
Got it to build (yay!) after finding the correct command for timezone setting. Except that (boo!) it still doesn't work. New logs attached. oh, this is DVI-I. I was confused and thought it was plain VGA. Can you try the ForcePanel option ? Created attachment 118331 [details] [review] enable lcd for VIA VT8562C And also try the following patch. ForcePanel locks it up upon attempted GUI -- had to power off via the button. How do I apply the patch? To apply the patch, go into your git checkout, then : patch -p1 < /path/to/diff.patch To revert, the patch : patch -R -p1 < /path/to/diff.patch I guess if ForcePanel locks up your device, then the enable_lcd.patch will lock up too. I'll attach another one for you to try in a minute. Created attachment 118332 [details] [review] enable dp for VIA VT8562C another patch to try. Revert the first one before applying this one. Neither patch is functional. The enable_lcd patch does, indeed, lock things up. The enable_dp patch repeats the usual behavior -- no screen. I (stupidly) didn't get logs out before reverting it, though. Sorry if I was too abrupt before... I'd still like to get this working, if you can help... This is still an ongoing issue. Where'd everyone go...? Still not resolved. No reply of any kind regarding the issue since 17 Sept 2015. If there is no intent to further examine, work on, and/or resolve this issue -- please mark as "won't fix" in some way. If there IS intent to fix this issue, I would like to try and make some progress soon. (I ain't gonna live forever.) If the devs are otherwise occupied and need some time, that's fine, but I'd like to know so that I don't wind up feeling abandoned. I really don't think I'm asking too much. No response as of Oct 16 2015. I'm going to consider this abandoned (sadly) as EWONTFIX. If anyone pops up here and is interested in picking up the pieces... you know how to find me :) Marking this as WONTFIX to reflect abandoned status. If anyone wants to reopen, let me know and I'll join back in. Hello Christopher,
No, this is not a "wontfix" bug; it is more like a "cantfix because dont know how" one. It seems that Xavier is the only maintainer at the moment, and as far as I know he does not have the expertise to really fathom what is going wrong. Correct me if I'm wrong, Xavier. (Hi there, BTW! :)
But, Christopher, you say you got a visible desktop on an older Puppy version? Is that reproducible, or was it a fluke? If reproducible, then good, because you are able to build from git. You could then do:
git checkout release_0_2_904
and then build and install that, and you should have a working openchrome driver on your newest Puppy distro.
When that works, you could try building 905, 906... and so on (look at the output of 'git tag'), until it breaks. When you've found the version where it breaks, you can try to bisect ('git help bisect') to find the commit that broke things. It's a lot of work, but if you have the time and the willingness, you can find the problem.
Oh, before you get your hopes up too high... 0.2.904 will probably not work with a current X. :| Which is the minimum version that could work, Xavier will probably know. Thanks for reopening! Deeply appreciated, as is the explanation. A pity that the other devs have left... loss of interest, I assume? *ahem* The function is reproducible. Any version of Puppy Precise (Puppy v. 5.7.1) works fine. Any version later than that, no video. I have tested with two other Pups -- X-Precise 2.4 (based on Precise Puppy 571) and LXPup Precise (based on Puppy 571 Retro) -- both work fine. I have also tested an odd Pup of ours -- ClassicPup 2.14X Top10 is a highly updated old dog of a Pup. (Pun intended.) It's based on the final 2.x-series release, but it's actually capable of running eg Chromium 43 or so. Pretty amazing. I can confirm that /it/ boots to desktop on that hardware as well... I would assume that any Pup earlier than Precise 571 would have no trouble, but I haven't tested that yet. I have asked the developer of TahrPup to spin me up a version of that Pup which has no zdrv (external driver SFS, rather than keeping them in/with the kernel) and the older openchrome driver from Precise Puppy 571. I'll update this to note what happens when I hear back... (In reply to Christopher from comment #26) > The function is reproducible. Any version of Puppy Precise (Puppy v. 5.7.1) > works fine. Any version later than that, no video. Could you try the Puppy version immediately after 5.7.1 (which gives no video) and grab a log from that and attach it here? That would be, er, TahrPup 6.0.2... the one mentioned in the first post in this bugthread. We have never actually gotten to eg 5.99... minor versions are bugfixes and minor updates, major versions introduce major changes. 4.2.0 was I think our last official 4-series Pup... might've been a 4.2.1, don't remember. A 4.3.2 was released much later, it had not been finished when the 5-series Pups were released, with a different direction -- Puppy changed at that point from being its own thing built on T2 packages, to being primarily a derivative distro built on other distros' packages, and there were (around that time) two official Puppies and a remarkable number of 'Puplets' (not made officially). The two Puppies were Wary Puppy (really old heap computers, and still based on T2) and Lucid Puppy. Eventually Lucid became Precise and Wary was joined by Racy, and we also had a Slackware-based 'Slacko Puppy'. That was the 5.5.x-5.7.x series... A note about Puppies vs Puplets vs Pups. I use 'Pups' to refer to the collection of all Puppies and Puplets together, or to Puppy Linux releases in general where distinguishing between un/official releases would be cumbersome or complicating. Puppies, are the official Pups, and Puplets are the 'unofficial' Pups -- think of it like Chrome vs Chromium, where Google makes Chrome, everyone else makes Chromium -- except if the Chrome devs and the Chromium devs were one and the same, with a community around them cooking up different special Chromiums and all getting support from the same pool of talent. That's Puppy -- the devs kind of blend in with the users in what in my opinion is a truly extraordinary way. Our lead dev and 'benevolent dictator' Barry Kauler actually stepped down into semi-retirement (he still tinkers with Puppy-like stuff that isn't quite Puppy, but he doesn't officially release any new Pups) and TahrPup was released afterwards. Yes -- for a decade, Puppy has been, in some sense, a one-man distro -- and in another sense, a multi-person distro. Mr Kauler did not act alone -- others (handles 01micko and 666philb being two amongst several more) helped a lot. TahrPup is 666philb's production AFTER Mr Kauler's retirement. We couldn't have done that without our community being the way it is... (In reply to Christopher from comment #28) > That would be, er, TahrPup 6.0.2... the one mentioned in the first post in > this bugthread. So... Puppy 5.7.1 uses X.Org X Server 1.11.3, Release Date 2011-12-16, and Puppy 6.0.2 uses X.Org X Server 1.15.1, Release Date 2014-04-13? And there is no other version in between? The first uses openchrome 0.2.904, and the latter openchrome 0.3.3? Right? I had hoped you would have a non-working Puppy version that uses openchrome 0.2.905 or 0.2.906 -- then the things to look at would be much, much less. BTW, could you stick to the matter at hand and leave out all descriptions of cute little puppies? :) We're trying to find the root of a problem here, not to write history. :) My apologies for the history stuff -- I simply thought it would help... I'll try to keep my enthusiasm to a minimum there, although I will note that I'm something of a fanatic. What you've stated is correct. There was that significant jump. Later today I can try compiling those two intermediate versions of openchrome and seeing how they behave in TahrPup 602. It may take me a while -- I've a desk to clean off before I can get to that stuff :P but it /should/ happen today. Compilation failed with both intermediate versions. 'make' couldn't find xf86.h and threw itself off a bridge in both cases. Commands were -- # ./configure --prefix=/usr # make -- and would have included -- # make install -- if I'd gotten that far. (In reply to Christopher from comment #31) > Compilation failed with both intermediate versions. > 'make' couldn't find xf86.h Well, that's strange. How then were you able to compile git master? To test, do 'git checkout master' and compile that. It too should fail on an unfindable xf86.h. > Commands were -- > > # ./configure --prefix=/usr > # make That's not enough. When you compile from git, after a checkout you should start with './autogen.sh', then configure and make. (In reply to Christopher from comment #0) > I don't know how relevant this is, but if I use the 'modesetting' or 'vesa' > drivers, the symptom is the same, except that additionally the system > freezes upon attempting to return to text mode. Well, if you can't get an image on your monitor even with the vesa driver, all bets are off. Vesa should work always. What does your xorg.conf look like when Puppy has generated it? How do you modify things to get the vesa driver to be used? I did not compile from git, I compiled the two downloads of the versions we'd mentioned -- one download per version -- from the website. Thought that was more clear, sorry. VIA and VESA do not get along -- Puppy wants to use VESA but it doesn't work with that chipset. The modification to xorg.conf changes one line, where Puppy assumes 24-bit color, changing that to 16-bit color. That is a fault with Puppy (it defaults to that with *everything*) not anywhere else. (In reply to Christopher from comment #34) > I did not compile from git, I compiled the two downloads of the versions > we'd mentioned Okay. Then start by compiling again git master, install it, run it, grab a log. Then check out release_0_3_3, compile, install, run, grab log. Then release_0_3_2... And so on. Until the compilation fails due to incompatibilities, or until you hit a working version of the driver. (Here's to hope! :) > VIA and VESA do not get along -- Puppy wants to use VESA but it doesn't work > with that chipset. The vesa driver does not work on the VX855 chipset? Oh dear. Poor VIA. > The modification to xorg.conf changes one line, [...] You did not attach the xorg.conf file as Puppy generates it. Please do. The logs from the Git master are already attached to this thread. They are clearly labeled... re-compiling from Git and replacing those logs will provide no changes, so I will refer you to those that are already attached. When it fails, it fails exactly the same way every time -- it can't detect or communicate with the monitor and proceeds to march itself off a cliff instead. I will get the xorg.conf shortly. I can also provide the script that generates it -- there are three xorgwizard scripts within Puppy. The one at initial first-boot is 'xorgwizard-automatic'; there's also 'xorgwizard-cli' (which is used when manually invoked as 'xorgwizard' from bash) and 'xorgwizard', which determines whether the automatic or the CLI version is what runs. I will copy those over in case you want them, so that I won't have to boot the machine more times than necessary. (There is no CLI networking within Puppy, and so I have to sneaker-net everything with a USB flash drive.) I will also download v.0.3.2x of openchrome, as well as re-downloading the 0.2.90x versions that I had previously tried, so that I can try to compile them again. I'll do what I can tonight and tomorrow -- but tomorrow evening I have to have a minor medical procedure (nothing serious, I promise) and I'll be gone after about 5pm till sometime late Tuesday afternoon, US Eastern time... won't be able to do anything till I get back, obviously. (In reply to Christopher from comment #36) > The logs from the Git master are already attached to this thread. I know. I said "grab the log", I did not say "attach it". > I will get the xorg.conf shortly. Good. > I can also provide the script that generates it No! No need. I just want to see xorg.conf. > I will also download v.0.3.2x of openchrome, as well as re-downloading the > 0.2.90x versions that I had previously tried, [...] No, please don't use the tarballs. Compile from git. First compile and test master again, then work your way backwards like I explained. I need you to be able to build from git. If you can't, then please say so, then we can stop this. > I'll do what I can tonight and tomorrow -- but tomorrow evening I have to > have a minor medical procedure (nothing serious, I promise) and I'll be gone > after about 5pm till sometime late Tuesday afternoon, [...] Good luck. There is no rush. I can compile from git, but I only know how to pull the most recent version. If you can tell me how to pull earlier versions, I can probably start going through it all again on Wednesday morning. (In reply to Christopher from comment #38) > I can compile from git, but I only know how to pull the most recent version. > If you can tell me how to pull earlier versions, [...] I already told you. In the directory that you pulled, do: git checkout release_0_3_2 Instead of "release_0_3_2" you use whatever other tag you want to check out (see 'git tag'). You don't need to "pull" anything more; you already have the entire history of the openchrome driver on your disk. Read what I write; chew it; wait two days before answering. Getting back to this. I had forgotten from last time -- but the Git master requires dependencies for 'Mir' which is irrelevant to Puppy (Puppy uses Xorg only). Last time I got around this by manually installing the deps -- but I'd like to avoid that if possible. Can you / will you tell me how to do that? Whoops -- forgot that danged xorg.conf file again. My apologies, I'll get it next time. I'm doing a pristine first-boot each time anyways... (In reply to Christopher from comment #40) > Git masterrequires dependencies for 'Mir' which is irrelevant to Puppy. > Last time I got around this by manually installing the deps -- but I'd > like to avoid that if possible. Can you / will you tell me how to do that? Don't know; I've never built from git. But I would try: ./configure --without-mir And if that doesn't work, look through the output of ./configure --help. My understanding is that with the Git stuff, ./autogen.sh replaces ./configure. I have a local friend who's a Linux guru... I'm more the user type... he uses git and knows all this stuff, let me see if I can get him to explain this to me. I'll pipe up with results when I have them. Sorry I haven't had a chance to work on this... been a crazy couple days... Basically what my friend told me was to run autogen.sh, then ./configure (overriding the configure from autogen) and then make, make install. Obviously I'll have a look 'round configure's help screen so I know what options to play with. Don't know off hand when I'll have a chance to get back to this tho. Would be nice if it were today but I got stuff to do... ...thought you folks would want an update, though, so here 'tis... (In reply to Christopher from comment #43) > Basically what my friend told me was to run autogen.sh, then ./configure > (overriding the configure from autogen) No, no, no, you're not overriding anything. ./autogen.sh *creates* ./configure. Then you run this ./configure; and you can pass certain options to it to adapt the configuring to your needs. > ...thought you folks would want an update, though, so here 'tis... No, we don't want a blabla update, we want *data*. And it doesn't matter how long it takes: you are the one who wants to get things working, we are in no hurry. (In reply to Christopher from comment #31) Hi Christopher, > Compilation failed with both intermediate versions. 'make' couldn't find > xf86.h and threw itself off a bridge in both cases. > > Commands were -- > > # ./configure --prefix=/usr > # make > > -- and would have included -- > > # make install > > -- if I'd gotten that far. At this point, I am not an official maintainer or developer of OpenChrome, but between June to early September 2015, I have worked on trying to fix a bug that causes LCD screen to get lost when the computer resumes from ACPI S3 State (Suspend to RAM or STR). So far, I was not successful in fixing this bug, but in the process, I did learn something about OpenChrome device driver. In my opinion, many portions of the UMS (User Mode Set) display management code paths are broken. This is ultimately the root cause of why things are not working out on your end. I do own one laptop with VN896 chipset (MSI VR321 laptop I am now typing this posting from.) and the OpenChrome I obtained from freedesktop.org anonymous Git repository works fine except ACPI S3 State resume. I also own VX800 chipset-based mainboard from VIA Embedded, but it is in storage right now (I can get it ready if I have to.). I do not currently own VX855 or VX875 chipset-based mainboard, so I am not able to do the precise testing on that mainboard, but I can definitely report that OpenChrome 0.3.3 works fine with VX800 integrated graphics except ACPI S3 State resume. Anyway, here is the very detailed instructions on how to compile and install OpenChrome compiled from the source code. http://www.freedesktop.org/wiki/Openchrome/Installation/ The only thing to watch out is to actually make a backup of the original OpenChrome compiled device driver files just in case you need to restore it. Other than that, if you follow the instructions, the compiled device driver code should get installed without too many issues. If you want me to, I can start looking into the VX855 / VX875 UMS display management code path to see what the device driver is doing. Let me know what you will like me to work on (Other than a vague demand like "fix my problem right now!"). Regards, Kevin Brace Kevin, would you have the expertise to repair the UMS issues within the driver? I'll gladly test if you can code. (In reply to Christopher from comment #46) Hi Christopher, > Kevin, would you have the expertise to repair the UMS issues within the > driver? I'll gladly test if you can code. Many years back when I was a kid, I have done direct VGA register programming in MS-DOS and x86 assembly language, in order to write a game. I still do remember some aspects of it. 2 months ago when I was trying to fix the standby mode resume LCD issue (ACPI S3 State or STR resume), I did read through VX800, VX855, and VX900 technical documentation, and worked mainly on via_vgahw.c. The functions that save and restore VIA Technologies extended VGA registers were broken (i.e., Many registers were not being saved when they should have been saved.), and in particular, the code was not fully saving many VGA registers for UniChrome Pro and Chrome 9. I completely rewrote the save and restore function, but this still did not resolve the LCD screen functionality getting lost when my VN896 chipset-based laptop resumes from STR (The LCD screen is restored okay if I use hibernation, however.). Probably some other portion of the OpenChrome UMS code is handling display controller reinitialization, so I need to look into understanding the code paths that handle this. Since the my current code does not really resolve the matter, there is no official patch for this rewrite at this point. I sent the code sample to Xavier Bachelot, but due to various first time developer issues has not accepted the changes yet. Right now, I am trying to figure out how to create a patch for some other change I made to the OpenChrome code that Xavier did not really like (Sorry, I am not trying to annoy Xavier, but as a first step, just want to start cleaning up the OpenChrome code. This update did not alter the functionality of the device driver.) Anyway, I obviously cannot promise when a patch to fix the VX855 display controller initialization can be ready, but I will start reading the UMS display management code (via_ums.c) right now after I finish writing this e-mail so that I can start understanding what is going on inside UMS display management code. From reading VX855 graphics hardware programming documentation, generally speaking, the display controller portion is very similar to VX800 graphics. There was a lot of changes made between VX855 and VX900 (VX900 graphics supports HDMI and DisplayPort, in addition to the legacy stuff like VGA. That being said, the HDMI display controller programming information is somehow missing. The programming information for DisplayPort is properly provided.), so I am myself surprised that the code "broke" with VX855. Regards, Kevin Brace (In reply to Kevin Brace from comment #47) > The functions that save and restore VIA Technologies extended VGA registers > were broken (i.e., Many registers were not being saved when they should have > been saved.), and in particular, the code was not fully saving many VGA > registers for UniChrome Pro and Chrome 9. One obvious fix is suggested by the code itself. See attached patch. > Since the my current code does not really resolve the matter, there is no > official patch for this rewrite at this point. Small patches that fix one specific issue are much more likely to get accepted. > I sent the code sample to Xavier Bachelot, but due to various first time > developer issues has not accepted the changes yet. Did you send it to the mailing list too? It's much better to have things in the open: seeing things happen can trigger someone into helping. Created attachment 119337 [details] [review] restores arbiter also for VX800 and VX855 I'll test that patch some time today, if I can. Got the thing to compile, with the arbiter patch included. Was unable to bypass mir requirement, but was able to institute a workaround that didn't involve patching Puppy itself. Per request I will not go into detail about /how/ I did the workaround. Have not actually /tested/ the newly-built driver yet, as I would like you folks' help on adjusting xorg.conf this time. Next message will be me attaching it from a 'pristine install' (having booted Puppy with instructions to ignore persistence). Commands were -- ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug --enable-viaregtool make make install Created attachment 119354 [details]
xorg.conf from initial boot
Hi Benno, (In reply to Benno Schulenberg from comment #48) > > One obvious fix is suggested by the code itself. See attached patch. > I reviewed the patch, and I find it unlikely the patch will make any material difference in the behavior. Why can I say this? It is because the unpublished code I wrote between July and early September touched upon the very code path your patch addresses. That particular function you are applying the patch apparently deals with standby / hibernation resume extended VGA register restoration. I completely rewrote this section, but at least in my case, it did not alter the behavior of OpenChrome on VN896 chipset (i.e., LCD screen state restoration after ACPI S3 State resume). I believe the patch will likely add 150 to 200 lines of code to OpenChrome. The code I wrote is still not available as a patch due to the fact that I am still learning how to create a patch in the first place (i.e., I am a first time developer.), but also Xavier did not really like the other modifications I made to OpenChrome (i.e., Some of what he suggested were reasonable, so I will comply with most of his wishes.). The code I wrote saves all known published extended VGA registers, however, it does not save VX900 DisplayPort registers at this point (VX900 HDMI registers appears to be unpublished.). Other than that, the code I wrote appears to work, and doesn't crash the system when the computer resumes, but LCD screen is still getting lost. Based on this, the bug is likely located in via_ums.c. I will start analyzing this module soon. > Small patches that fix one specific issue are much more likely to get > accepted. > I am planning to create 2 patches soon. > Did you send it to the mailing list too? It's much better to have things in > the open: seeing things happen can trigger someone into helping. I can provide the code in the form of a patch after I figure it out how to do it. If you know how to do it, it will be nice if you can share the instructions on how to do this. The way I did it is, $ diff -cr (Original Files Directory) (Modified Files Directory) If there is a better way to create a patch, let me know. Regards, Kevin Brace Just to correct myself, this was how I generated my patch. $ diff -cr Original_xf86-video-openchrome xf86-video-openchrome > Sample_Patch.patch I hope this is correct. Regards, Kevin Brace (In reply to Kevin Brace from comment #54) > $ diff -cr Original_xf86-video-openchrome xf86-video-openchrome > > Sample_Patch.patch That is nearly right: instead of '-cr' you would use '-ur', making a unified diff. However, it seems you make patches from an unpacked tarball. It would be much better if you made your changes in git. That is: in git branches. Use 'git clone' to make a copy of the openchrome repository. Then use 'git checkout -b somefix' to make a branch, then make your changes there, and when you have a self-contained small change ready, you do 'git commit -a' and write a nice commit summary. Then you make more changes, and then commit those, and so on. Instead of 'somefix' you use whatever name is appropriate for the thing you are working on. The smaller the single, self-contained commits, the better. (In reply to Christopher from comment #52) > xorg.conf from initial boot Strange: the entire "Device" section is commented out. And with exactly this xorg.conf you obtained the very first Xorg.0.log attached on Sep 14? (I have no experience with modern Xorgs; apparently it is pretty good at detecting available and applicable drivers.) @ Benno -- yes, that xorg.conf is the initial one provided at first bootup after install, or if you instruct Puppy to boot ignoring 'savefile' or 'savefolder' (persistence). If you and/or Xavier and/or Kevin want to suggest how I might properly modify it to maximize chances of getting a display -- I will do so in testing the new driver. FYI -- I got a Puppy developer (he goes by the handle 666philb on the Puppy Forum, I don't know his real name) to bodge together a version of TahrPup 6.0.2 (the target Puppy here) with the kernel and Xorg stuff from Precise Puppy 5.7.1 Retro, and lo and behold I get working video. That pretty well isolates this as Not A Puppy Quirk (there's plenty of those to be had, unfortunately) which we pretty well already knew but I thought I'd mention it here anyways. I'm very much still interested in trying to work out what the issue is that's breaking the driver on this hardware in later revisions... but I wanted to keep you guys in the loop as well :) (In reply to Benno Schulenberg from comment #55) Hi Benno, > That is nearly right: instead of '-cr' you would use '-ur', making a unified > diff. > Yes, looking at the several patches, I did notice that when patches are created, they are done against the current master branch on the Git repository rather than using diff against the cloned version on the local computer. I honestly do not want to create the patch against the cloned version on my computer. > However, it seems you make patches from an unpacked tarball. It would be > much better if you made your changes in git. That is: in git branches. > > Use 'git clone' to make a copy of the openchrome repository. Then use 'git > checkout -b somefix' to make a branch, then make your changes there, and > when you have a self-contained small change ready, you do 'git commit -a' > and write a nice commit summary. Then you make more changes, and then > commit those, and so on. Instead of 'somefix' you use whatever name is > appropriate for the thing you are working on. The smaller the single, > self-contained commits, the better. Benno, I think I figured out how to create a patch, and I will upload it shortly. It doesn't really fix anything, but it merely updates a few cosmetic issues of OpenChrome (i.e., VM800 / VN800 naming issue, better device support message in Xorg.0.log.). Regards, Kevin Brace Created attachment 119397 [details] [review] VM800 / P4M800 Pro Correction Patch This is my first ever patch. This patch doesn't really solve any issues, but I always wanted get rid of VM800 reference in OpenChrome since such chipset doesn't exist. There is, however, a chipset called VN800. P4M800 Pro and VN800 chipsets are related. For whatever reason, I will like to see this confusion cleared up so I created a patch that will get rid of this confusion once and for all. Hopefully, I will create a second patch that will incorporate Benno's current patch since I worked on completely rewriting VIASave and VIARestore functions between July and September 2015. Hi Christopher, I was looking at xerrs.log, and this portion of the error message is concerning to me. ________________________________________________________________________ . . . Initializing built-in extension DRI2 Loading extension GLX 3145728 bytes of Linear memory allocated at 300000, handle 3110288112 262144 bytes of Linear memory allocated at 600000, handle 3110288240 32 bytes of Linear memory allocated at 640000, handle 3110288368 32 bytes of Linear memory allocated at 640080, handle 3110288496 16384 bytes of Linear memory allocated at 641000, handle 3110292608 16384 bytes of Linear memory allocated at 645000, handle 3110288584 DRM memory allocation failed -6 via_xv.c : viaInitVideo, Screen[0] 635904 bytes of Linear memory allocated at 649000, handle 3110270016 Freed 6590464 (pool 4) via_xv.c : viaSetupAdaptors (viaSetupImageVideo): via_xv.c : viaGetPortAttribute : port 0 73 via_xv.c : ColorKey 0x821 . . . ________________________________________________________________________ For some reason, the device driver is causing DRM to fail in allocating memory. This is the likely reason why you don't see anything on your screen. It is possible that the bug has nothing to do with screen mode set, and something to do with memory allocation from the OS. I will start studying which functions are called during initialization, in order to understand what is going on. Regards, Kevin Brace Hi Christopher, I found 2 similar bug reports that are very similar to the situation to you are in. http://unix.stackexchange.com/questions/144669/via-chrome-9-hc-graphics-card-causes-blackscreen-on-centos-6-5 http://ubuntuforums.org/showthread.php?t=2220006 What unites your situation and these 2 cases is the following message. "DRM memory allocation failed -6" If you search through your first Xorg.0.log you posted, you can find the above message. https://bugs.freedesktop.org/attachment.cgi?id=118249 You will see the same for the 2 other messages. Although it is unlikely to fix any issue, is it possible your can adjust AGP aperture size from the BIOS setup? Although the graphics might be integrated, they "appear" like an AGP device from software, hence, many BIOSes provide a way to adjust AGP aperture size via BIOS setup. Another temporary workaround can be to change the SO-DIMM size (i.e., increase or decrease) to see if the situation changes. At this point, I am just suggesting these test cases because I suspect a bug in allocating memory via DRM. Regards, Kevin Brace (In reply to Christopher from comment #58) > FYI -- I got a Puppy developer [...] to bodge together a version of TahrPup > 6.0.2 [...] with the kernel and Xorg stuff from Precise Puppy 5.7.1 Retro, > and lo and behold I get working video. Great! Which kernel version is that? Please attach a Xorg.0.log. > I'm very much still interested in trying to work out what the issue is > that's breaking the driver on this hardware in later revisions... Yes, but most likely it's not a driver issue, but a kernel issue... You see, I woke up my old KM400 machine, booted it from a USB stick with Linux Lite 2.6... and see... I don't get any video either! (When I boot it in safe mode, it forces the use of the vesa driver and I get a visible and usable desktop.) What I then noticed in the log is a line that I'll post in a minute. (In reply to Kevin Brace from comment #62) > What unites your situation and these 2 cases is the following message. > > "DRM memory allocation failed -6" Well, yes, but what comes before it is a line saying this: (EE) CHROME(0): [drm] Failed to open DRM device for pci:0000:00:01.0: No such file or directory Ouch. I didn't pay attention to that line at first, because in the old times I've seen it many times but then later it would work anyway. Not nowadays, it seems. Hi Kevin, (In reply to Kevin Brace from comment #60) > Created attachment 119397 [details] [review] [review] > VM800 / P4M800 Pro Correction Patch Please file a new bug for this (as it's not directly related to this bug), or start a thread on the mailing list. The TahrPup/Precise Hybrid (as I'm calling it) is kernel 3.2.48. I will note that it's BETA quality at best -- there are some issues with keyboard layout settings being misreported and the audio drivers got clobbered somehow (they don't work). But hey, desktop! Xorg.0.log and xerrs.log comin' up! Created attachment 119406 [details]
xerrs.log from TahrPup/Precise Hybrid
Created attachment 119407 [details]
Xorg.0.log from TahrPup/Precise Hybrid
(In reply to Christopher from comment #66) > The TahrPup/Precise Hybrid (as I'm calling it) is kernel 3.2.48. Okay. What's the output of 'dmesg | grep -e agp -e drm' after a fresh reboot? #dmesg | grep -e agp -e drm [ 111.700196] Linux agpgart interface v0.103 [ 111.733412] [drm] initialized drm 1.1.0 20060810 # This is on a pristine boot, as if it had been first installed (i.e. no persistence). (In reply to Christopher from comment #70) > #dmesg | grep -e agp -e drm > [ 111.700196] Linux agpgart interface v0.103 > [ 111.733412] [drm] initialized drm 1.1.0 20060810 See on http://www.freedesktop.org/wiki/Openchrome/Troubleshooting/ what it should say. Also see the TODO list on http://www.freedesktop.org/wiki/Openchrome/Development/, there it says: "Prepare drm-openchrome for merge into drm-next". Apparently some openchrome-specfic DRM stuff is currently missing from the kernel. Xavier? So... wait. This is a *kernel* issue? Is this something I need to go to, er, Mr Linus Himself for? (I hope not... although I'd be interested in hearing his reaction to the fact that I've got a computer much like his famous 386 :P probably I'd hear either 'bin it' or 'get cracking' tho... right now the cynic in me is leaning towards the former.) Also, worth noting -- Puppy uses a 'patched' kernel. Something to do with aufs, I think. (That's really all I know. Honest.) I may be able to talk 666philb into adding an extra patch if he knows what exactly to stuff in... (In reply to Christopher from comment #72) Hi Christopher, > So... wait. This is a *kernel* issue? Is this something I need to go to, er, > Mr Linus Himself for? (I hope not... although I'd be interested in hearing > his reaction to the fact that I've got a computer much like his famous 386 > :P probably I'd hear either 'bin it' or 'get cracking' tho... right now the > cynic in me is leaning towards the former.) > > Also, worth noting -- Puppy uses a 'patched' kernel. Something to do with > aufs, I think. (That's really all I know. Honest.) I may be able to talk > 666philb into adding an extra patch if he knows what exactly to stuff in... In addition to adjusting AGP Aperture size (i.e., make it larger), is it possible for your to adjust your integrated graphics frame buffer size (i.e., also make it larger)? I will attach my dmesg and Xorg.0.log shortly as a reference. At least on my laptop, the AGP Aperture is 128 MB and integrated graphics frame buffer is 64 MB. Regards, Kevin Brace The BIOS on this system is very limited. I can adjust only the frame buffer size. It defaults to 128MB. Sometime after you suggested increasing it or decreasing it I remembered a remark from my local guru that 64mb was more than enough given the graphics 'performance' (for lack of a better term) that VIA chips provide. I at that time lowered it to 64mb which is its lowest setting. Available frame buffer sizes (in mb) -- 64,128,256,512. I have tried all of them and none provide any remedy to this issue. Created attachment 119411 [details]
Epic 1314 laptop (MSI VR321 laptop equivalent) dmesg
This is my Epic 1314 laptop (MSI VR321 laptop equivalent) dmesg.
As you can see, it sets AGP Aperture Size to 128 MB.
At least for this laptop, this setting is not adjustable in BIOS setup.
Created attachment 119415 [details] Epic 1314 laptop (MSI VR321 laptop equivalent) Xorg.0.log This is my Epic 1314 laptop (MSI VR321 laptop equivalent) Xorg.0.log. As you can see, the computer allocates 64 MB of frame buffer. > [ 29.394] (--) CHROME(0): Probed amount of VideoRAM = 65536 kB At least for this laptop, this setting is not adjustable in BIOS setup. (In reply to Christopher from comment #74) Hi Christopher, > The BIOS on this system is very limited. I can adjust only the frame buffer > size. It defaults to 128MB. Sometime after you suggested increasing it or > decreasing it I remembered a remark from my local guru that 64mb was more > than enough given the graphics 'performance' (for lack of a better term) > that VIA chips provide. I at that time lowered it to 64mb which is its > lowest setting. > > Available frame buffer sizes (in mb) -- 64,128,256,512. > > I have tried all of them and none provide any remedy to this issue. Okay, then this idea to temporarily workaround the bug did not work. I will set up KM400, K8M800, and P4M900-based system with Lubuntu 12.04 i386 to be able to run more experiments on my side. I will use the latest version of the device driver code from the Git repository for testing purposes. Please give me several days to get this ready as I usually install multiple installations of Ubuntu / Lubuntu on each system (i.e., Ubuntu 8.04 LTS, Ubuntu 10.04 LTS, Lubuntu 10.04, Lubuntu 12.04, etc.). I will also try to read and understand how the device drive code works as I am interested in fixing and improving the base code itself. Regards, Kevin Brace You know, if you want to pick up a WYSE Cx0 series system (just like mine) on eBay they are alarmingly inexpensive... I don't know where you're located, but in the US this would be a good choice --> http://www.ebay.com/itm/191707391050 That one is $13 with free shipping. Boots from USB, and the DEL key gets you into the BIOS. I'm just sayin'. Agh, no edit button. Dontcha just hate it when you hit [POST] and then you think of something else and there's no dang edit button? Ugh. Anyhow -- if you pick up that listing, you'll need a power supply. Barrel jack is the input, 2.1x5.5mm, I believe are the proper plug dimensions (that's inner diameter x outer diameter, mind you!). INPUT MUST BE TWELVE REGULATED VOLTS unless you want to do unspeakable things to your Cx0 ;) I'm running mine off of a spare 12v 1.5a Netgear router "wall wart" (transformer lump that hogs space around the outlet) but even that really is a bit overkill... I could quite likely go down to a 1a model if I had one that was properly regulated (i.e. switching, not "unregulated" which really is load regulated and does Very Nasty Things to computers if you try and use it with them...). Mind you also that PS/2 keyboards and mice pull way more power than USB equivalents, or so I hear -- I'm using USB keyboard and mouse with mine. ...oh, and if you've got a VGA-only screen you'll need an adapter for that, the video port is a DVI-I. (In reply to Christopher from comment #78) Hi Christopher, > You know, if you want to pick up a WYSE Cx0 series system (just like mine) > on eBay they are alarmingly inexpensive... I don't know where you're > located, but in the US this would be a good choice --> > http://www.ebay.com/itm/191707391050 > > That one is $13 with free shipping. Boots from USB, and the DEL key gets you > into the BIOS. > > I'm just sayin'. Yes, I do pay for some old hardware if it is sufficiently "cheap." I will say that I will be non-committal buying a Wyse thin client at this point. I did set up a computer with P4M900 chipset (ASRock P4VM900-SATA2 mainboard), but I will need to set up several other computers over the next few days for testing purposes (Mainboards with CLE266, KM400, K8M800, P4M800 Pro, and CN700 chipsets). I will be reading the source code to understand how it works, so it will take several more days before I can possibly report any progress, if any. Feel free to ask me what is going on, periodically. Regards, Kevin Brace @ Kevin -- no worries, the purchase idea was just a suggestion. Take all the time you need -- time is something I have plenty of :) and, on that note, if you at any time need me to test something, let me know and I will do it as soon as I reasonably can. I'm not the type that just says "solve it" and goes off for a nap ;) if I can help I will. (In reply to Christopher from comment #81) Hi Christopher, > @ Kevin -- no worries, the purchase idea was just a suggestion. Take all the > time you need -- time is something I have plenty of :) and, on that note, if > you at any time need me to test something, let me know and I will do it as > soon as I reasonably can. I'm not the type that just says "solve it" and > goes off for a nap ;) if I can help I will. Yesterday, I was setting up a computer with Abit KV-80 mainboard (K8M800 chipset, Socket 754). I will be installing 9 favors of Ubuntu / Lubuntu going all the way back to Ubuntu 6.06 LTS, and I will also be installing Athlon 64 soon so that I can do testing against x86-64 (AMD64) instruction set (I currently have a particular version of Sempron that does not support x86-64 instruction set, so I need to replace this with Athlon 64.). I know from experience that that the OpenChrome source code on the anonymous Git repository does not compile without errors on Ubuntu 8.04 LTS, but it compiles fine with Ubuntu 10.04 LTS (and Lubuntu 10.04) or later. It probably something to do with ABI version, etc. as to why it does not compile. I need to make slight changes to the patch I posted a few days ago unrelated to your issue, and create another patch that incorporates Benno's patch, but also completely rewrites VIASave and VIARestore functions in via_vgahw.c. After that, I can start learning how memory allocation is being done, so that hopefully it can lead to a fix for the bug you have reported. Regards, Kevin Brace Sounds like a plan! Just keep me in the loop, is all I ask :) (In reply to Benno Schulenberg from comment #65) Hi Benno, > Hi Kevin, > > (In reply to Kevin Brace from comment #60) > > Created attachment 119397 [details] [review] [review] [review] > > VM800 / P4M800 Pro Correction Patch > > Please file a new bug for this (as it's not directly related to this bug), > or start a thread on the mailing list. You are right, I should start a new bug report, in order to submit this patch. I will do so shortly, but I made slight changes to the original patch, so I will upload it here just because I already posted one here. Regards, Kevin Brace Created attachment 119472 [details] [review] VM800 / VN800 / P4M800 Pro Correction Patch I will open a new bug report specifically for this patch, but I just wanted to replace the previous patch I posted several days ago. I am marking the previous patch as obsolete. I will be e-mail this patch to Xavier Bachelot shortly. Regards, Kevin Brace _____________________________________________________________________________ Patch Comment: Replaces VIA_VM800 label with VIA_P4M800PRO label inside via_driver.c due to the fact that there is no such product as VM800 chipset from VIA Technologies. The VM800 chipset the source code refers to really is P4M800 Pro chipset. Also, the source code refers to a product called VN800 chipset, and this is similar (related) to P4M800 Pro chipset. Made an improvement in supported device message recorded by Xorg.0.log. Other than that, there is no change in terms of the device driver functionality. The compiled device driver was tested on the following computer. - Epic 1314 laptop (MSI VR321 laptop equivalent, VN896 chipset) with Lubuntu 12.04 i386. _____________________________________________________________________________ I posted the VM800 / VN800 / P4M800 Pro correction patch as Bug 92861. https://bugs.freedesktop.org/show_bug.cgi?id=92861 Kevin Brace (In reply to Christopher from comment #83) Hi Christopher, > Sounds like a plan! > > Just keep me in the loop, is all I ask :) Yes, I just posted a patch unrelated to your issue. I will make another patch that incorporates Benno's code, but also extensively rewrites VIASave and VIARestore functions inside via_vgahw.c. Again, I did this independently between July to early September 2015 because I was trying to fix LCD screen loss after standby resume bug. After that, I will move into trying to remotely figure out what is causing OpenChrome 0.3.3 to fail with VX855 chipset along with fixing other bugs of OpenChrome. Regards, Kevin Brace 'ey Kevin, how's it all going? Just checking in... (In reply to Christopher from comment #88) Hi Christopher, > 'ey Kevin, how's it all going? Just checking in... Thanks for checking in. Sorry for the lack of progress. I have been attending an event called ARM TechCon 2015 for the past 3 days, so I have had less time to work on analyzing the code. I have also been spending time on trying to figure out how to use Git correctly since I have little experience using Git until now. What I was trying to figure out is how I can create a patch that gets applied over the first patch I posted, but I have not been successful so far. I have finished editing the code per Xavier's requirements (i.e., no use of tabs in the code, commenting style, etc.), If I can figure out how to use Git correctly, I will have more time to work on troubleshooting your bug. Regards, Kevin Brace (In reply to Kevin Brace from comment #89) > What I was trying to figure out is how I can create a patch that gets > applied over the first patch I posted, but I have not been successful so far. First make sure all your changes are in patch files and safely outside of your openchrome git repo. Then do 'git reset --hard HEAD'. Then do 'git checkout -b workingonvx855', which makes a branch. Then make the changes (or apply the patch you already have) and commit it with 'git commit -as', write a message describing the change, and save. You will have made your first local commit. Then make more changes, then commit those. And so on. When you're done, do 'git format-patch origin', and git will make several patches for you that apply one after the other. You could also just look at 'git log' or 'git log -p' when you're still busy. (In reply to Benno Schulenberg from comment #90) Hi Benno, > > First make sure all your changes are in patch files and safely outside of > your openchrome git repo. Then do 'git reset --hard HEAD'. > > Then do 'git checkout -b workingonvx855', which makes a branch. Then make > the changes (or apply the patch you already have) and commit it with 'git > commit -as', write a message describing the change, and save. You will have > made your first local commit. Then make more changes, then commit those. > And so on. > > When you're done, do 'git format-patch origin', and git will make several > patches for you that apply one after the other. You could also just look at > 'git log' or 'git log -p' when you're still busy. I did the patch generation a little differently, but after spending several hours, I figured out how to do it the way I wanted it done. That being said, your instructions were helpful, so thank you very much for helping me out. Regards, Kevin Brace I just posted a second patch that supersedes Benno's previous patch as Bug 92957. https://bugs.freedesktop.org/show_bug.cgi?id=92957 I can now concentrate on trying to figure out what the reason why the latest OpenChrome fails with VX855 chipset. Regards, Kevin Brace I just posted a second patch that supersedes Benno's previous patch as Bug 92957. https://bugs.freedesktop.org/show_bug.cgi?id=92957 I can now concentrate on trying to figure out the reason why the latest OpenChrome code fails with VX855 chipset. Regards, Kevin Brace (In reply to Benno Schulenberg from comment #63) Hi Benno, > Yes, but most likely it's not a driver issue, but a kernel issue... You > see, I woke up my old KM400 machine, booted it from a USB stick with Linux > Lite 2.6... > and see... I don't get any video either! (When I boot it in safe mode, it > forces the use of the vesa driver and I get a visible and usable desktop.) > What I then noticed in the log is a line that I'll post in a minute. I am half done with setting up a K8M800 chipset-based computer (ABIT KV-80). I compiled the latest OpenChrome code with my 2 patches I posted, and it appears that the computer operates correctly (Ubuntu 10.04 LTS i386). I plan to install 4 more Ubuntu / Lubuntu distributions to this computer (I can only do about 1 OS installation per day.). For the test, I booted the computer with different frame buffer RAM settings (16 MB, 32 MB, and 64 MB) and various AGP Aperture Size settings, and all settings worked fine (i.e., Ubuntu booted without problems). I am also in the process of setting up a CLE266 chipset-based computer (VIA Technologies EPIA-CL), to which the graphics subsystem is similar to KM400 chipset (both have UniChrome). I also own a KM400 chipset-based Foxconn mainboard, so I will try to find an appropriate hard drive and start installing various Ubuntu / Lubuntu distributions for testing purposes. It will likely take a week or so before I can get this done at the present pace. Regards, Kevin Brace Hi Christopher,
Just to let you know, I have not forgotten your bug.
I have been spending time learning how OpenChrome works, and have made about 8 patches so far.
There is a lot problems in the way the code is written, so most of the patches I have created mainly address those issues.
I will post them in the next few days.
One of the big fix I was able to make is the laptop LCD backlight turn off feature that was never implemented in OpenChrome.
I was able to confirm that I can now turn off the laptop LCD backlight via power manager type of utility built into the OS (tested with Lubuntu 12.04 i386).
Currently, OpenChrome can turn off the screen itself, but not the laptop LCD backlight.
This is not nice for people running VIA Technologies integrated graphics laptop.
My original interest in working on OpenChrome's code was to fix my laptop's ACPI S3 State resume bug, and made a lot of progress in the past 2 days (have been working on the bug since July 2015).
The developer made a poor assumption regarding LVDS-based LCD state (i.e., laptop LCD), so I made some changes to the code.
For now, the screen does come back on after resuming from ACPI S3 State (previously, it was losing it completely), but due to video PLLs not being set up correctly (my current guess as to why the laptop screen is messed up), the laptop LCD screen is pretty messed up at this point.
Regarding your bug, it appears that OpenChrome code structure change dramatically between Version 0.2.9 and Version 0.3.3.
Lots of code were moved to via_ums.c, and in this process of restructuring the code, a regression occurred.
I will continue to spend some time on learning how memory allocation is being done, because I suspect that is the reason why it doesn't work with VX855 chipset.
My ISP lost my home Internet access (AT&T), so this has slowed me down considerably for the past 5 days.
Regards,
Kevin Brace
'ey, Kevin -- take all the time you need. I don't rush people when they're tryin' to help me ;) Do your thing. I'll be here when you got somethin' for me. (In reply to Christopher from comment #96) Hi Christopher, > 'ey, Kevin -- take all the time you need. I don't rush people when they're > tryin' to help me ;) > > Do your thing. I'll be here when you got somethin' for me. I spent a few hours analyzing one of the log file you attached. The one I looked at specifically was the current compiled version of OpenChrome Xorg.0.log (See Xorg.0.log from Git-built driver). I find these messages curious. _________________________________________________________________________ . . . [ 72.614] (II) Loading sub module "ddc" [ 72.614] (II) LoadModule: "ddc" [ 72.614] (II) Module "ddc" already built-in [ 72.614] (II) CHROME(0): ViaOutputsDetect [ 72.614] (==) CHROME(0): LVDS-0 : Digital output bus width is 12 bits. [ 72.614] (==) CHROME(0): LVDS-0 : DVI Center is disabled. [ 72.614] (==) CHROME(0): LVDS Panel will not be forced. [ 72.614] (==) CHROME(0): Panel size is not selected from config file. [ 72.615] (II) CHROME(0): Output VGA-1 using monitor section Monitor0 [ 72.615] (**) CHROME(0): Option "PreferredMode" "1280x1024" [ 72.616] (II) CHROME(0): I2C device "I2C bus 1:ddc2" registered at address 0xA0. [ 72.623] (--) CHROME(0): Test for CRT with VSYNC [ 72.623] (II) CHROME(0): EDID for output VGA-1 [ 72.624] (II) CHROME(0): Output VGA-1 disconnected [ 72.624] (WW) CHROME(0): No outputs definitely connected, trying again... [ 72.624] (II) CHROME(0): Output VGA-1 disconnected [ 72.624] (WW) CHROME(0): Unable to find connected outputs - setting 1024x768 initial framebuffer [ 72.624] (II) CHROME(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 72.624] (==) CHROME(0): DPI set to (96, 96) . . . _________________________________________________________________________ I think DDX (Device Dependent X == OpenChrome in this case) is not seeing a monitor when it tries to sense the presence of a VGA monitor via DDC (I2C). Hence, when the OS gives up the booting, it gives the following error message (See xerrs.log from Git-built driver). _________________________________________________________________________ . . . (EE) Server terminated successfully (0). Closing log file. xwininfo: error: unable to open display ":0" xwininfo: error: unable to open display ":0" /usr/bin/xinit: connection to X server lost XIO: fatal IO error 2 (No such file or directory) on X server ":0" _________________________________________________________________________ The question I now have is, why isn't DDX not seeing the VGA monitor? It appears that DDC related code is located inside xorg, and is not directly handled by OpenChrome. Although I do not wish to suggest a new "wild goose chase" type of an idea, if you happened to have a different VGA cable, maybe you can try it. Also, you can also try a DVI cable instead of VGA cable + DVI to VGA dongle combination to see what happens. Last time I checked, your Wyse thin client has a DVI output port, not VGA output port coming out of it. I personally think it will make no difference, but I will like to see what happens when you try a DVI cable. Just for your information, I have spent some time trying to figure out what OpenChrome does when it initialize itself. I now have somewhat better understanding of the code, hence, I was able to suggest this likely cause of why it does not work correctly with your particular hardware. I will be off for at least a day due to air travel. Regards, Kevin Brace 'ey Kevin, Merry Christmas! I have a little quandary with DVI. See, I'm at my father's house for Christmas... I'll be going home this Wednesday. My father owns one or two screens that can do DVI (old 15" Dell LCD from gawd only knows how long ago), but I do not. I have (oddly enough) a DVI cable -- but I left it at home. OOPS! I can tell you that I have an *HDMI* screen at home... big sonova[...] as well. It's a 20" widescreen, my biggest one by far -- Dell ST2010. I can juuuuuuust barely wedge a DVI->HDMI adapter in there (mine is rather bulky) and use that with the DVI cable. I did that once, reports are here, behavior was identical as to VGA. It wouldn't surprise me /entirely/ if this turned out to be an Xorg-in-Puppy sort of bug, although, TBH, I would be caught a little off guard at this point ;) Nevertheless, I will try to arrange for a DVI cable to be purchased tomorrow, or connive my way into taking home yet another LCD. I guess having five VGA-only screens and one VGA/HDMI one just isn't enough :P LOL. Actually -- FWIW -- here's my, er, collection... Dell ST2010 20" 1600*900 VGA/HDMI Dell somethingorother 17" 1280*1024 VGA HP vf52 15" 1024*768 VGA HP vs17 17" 1280*1024 VGA HP vs17c 17" 1280*1024 VGA Acer somethingorother 15" VGA (I forget the resolution, and I'm not 100% on the size... it's my newest and I've only used it once...) If I manage to bring home that Dell DVI-able screen I mentioned, I'll be adding this line to the above list -- Dell 1503FP 15" 1024*768 VGA/DVI We'll see what happens... Got the cable. Highway Robbery pricing at Best Buy, but that's Best Buy for you... ugh. *ahem* More info about the up-till-now, then some test results. Attachments are on their way as well :) Up till now I have been using a DVI-to-VGA adapter, exactly like this one --> http://www.ebay.com/itm/252221518771 I have two of those, and two other different ones that work exactly the same. I use that, and the first VGA cable my hand finds, and that gets the client to a screen ;) With the aforementioned $22 (there ought to be a law!) DVI-D Single Link cable from Best Buy, I get about the same behavior -- it's fine in text mode, graphics I get a single nonblinking cursor. That's with default video. Modesetting driver is same result, except that the cursor starts blinking when I get back to text mode. OpenChrome driver is about to be tested, along with whatever the default driver is. I will report back further information as soon as I have it... and there WILL be logs ;) Created attachment 120696 [details]
xerrs.log from initial bootup, DVI-D cable and monitor
Created attachment 120697 [details]
Xorg.0.log from initial bootup, DVI-D cable and monitor
Created attachment 120698 [details]
xerrs.log, DVI-D cable and monitor, openchrome driver manually specified in xorg.conf
Created attachment 120699 [details]
Xorg.0.log, DVI-D cable and monitor, openchrome driver manually specified in xorg.conf
Created attachment 120700 [details]
xerrs.log, DVI-D cable and monitor, openchrome driver specified through xorgwizard
Created attachment 120701 [details]
Xorg.0.log, DVI-D cable and monitor, openchrome driver specified through xorgwizard
...and, there's your logs. Behavior is identical between DVI setup and VGA+adapter setup. Next...? (In reply to Christopher from comment #99) Hi Christopher, > Got the cable. Highway Robbery pricing at Best Buy, but that's Best Buy for > you... ugh. > > *ahem* > > More info about the up-till-now, then some test results. Attachments are on > their way as well :) > > Up till now I have been using a DVI-to-VGA adapter, exactly like this one > --> http://www.ebay.com/itm/252221518771 > I have two of those, and two other different ones that work exactly the > same. I use that, and the first VGA cable my hand finds, and that gets the > client to a screen ;) > > With the aforementioned $22 (there ought to be a law!) DVI-D Single Link > cable from Best Buy, I get about the same behavior -- it's fine in text > mode, graphics I get a single nonblinking cursor. > Sorry for you having to pay $22 for a DVI single link cable at Best Buy. > That's with default video. > > Modesetting driver is same result, except that the cursor starts blinking > when I get back to text mode. > > OpenChrome driver is about to be tested, along with whatever the default > driver is. > > I will report back further information as soon as I have it... and there > WILL be logs ;) I spent about 2 hours so far in the car today analyzing why the DDC (I2C bus) is not working well. So far I have not found a solution or something for you to try, but I will keep analyzing the source code of the portion that deals with DDC. Regards, Kevin Brace No sweat on the cable -- Dad paid for it, and he's returning it and getting his Seasick Washingtons back. It'll be a week or so before the one I got on eBay for $1 (!) arrives from Kentucky, though -- since I'm keeping the monitor (he said I could) I'll be able to test again on that soon but not immediately. I'll be going back home from my Dad's tomorrow, so I won't be very responsive till Thursday, at the earliest. Travel time's only one little tiny hour, but it takes me a while to pack, unpack, and reconstruct everything the way it needs to be, you know? Hope you're not dealing with jet lag tho -- that can be nasty stuff. (In reply to Christopher from comment #108) Hi Christopher, > No sweat on the cable -- Dad paid for it, and he's returning it and getting > his Seasick Washingtons back. It'll be a week or so before the one I got on > eBay for $1 (!) arrives from Kentucky, though -- since I'm keeping the > monitor (he said I could) I'll be able to test again on that soon but not > immediately. > > I'll be going back home from my Dad's tomorrow, so I won't be very > responsive till Thursday, at the earliest. Travel time's only one little > tiny hour, but it takes me a while to pack, unpack, and reconstruct > everything the way it needs to be, you know? > > Hope you're not dealing with jet lag tho -- that can be nasty stuff. I think one of the major problem of OpenChrome code is that it relies on a predefined table to initialize which display output will be available. As far as I am concerned, this is a terrible way to initialize display outputs. I think the code should be rewritten to completely eliminate the predefined table, but I doubt I can get anyone else to support doing this. In other words, only I2C bus should be used to figure out which display is available. In your particular case, I do not own a comparable hardware to what you have, so it is extremely difficult to analyze what is going wrong. Over the past 2 months, I have posted about 10 or so patches not related to the bug you have observed. Unfortunately, I got no one with Git commit privilege to commit the patches. At this point, I feel like the OpenChrome project is going nowhere due to lack of interest and developer neglect. Regards, Kevin Brace Kevin, I apologize if I haven't been openly thankful enough here -- but I really am -- you are doing a GREAT job of helping me, so far, and I do not want you to give up. If I'm the only one in the world with a working OpenChrome driver for VX855 -- fine by me. If the devs don't care enough to support their own creation, that's *their* problem. It's not mine, and I don't think it ought to be yours, either. Let's do what we can, and if it becomes apparent that a fork is necessary, we might consider that as well. (In reply to Christopher from comment #110) Hi Christopher, > Kevin, I apologize if I haven't been openly thankful enough here -- but I > really am -- you are doing a GREAT job of helping me, so far, and I do not > want you to give up. > > If I'm the only one in the world with a working OpenChrome driver for VX855 > -- fine by me. If the devs don't care enough to support their own creation, > that's *their* problem. It's not mine, and I don't think it ought to be > yours, either. > > Let's do what we can, and if it becomes apparent that a fork is necessary, > we might consider that as well. Thank you very much for the words of encouragement. I will continue working on fixing the bug you observed and a few more I know exists (i.e., ACPI S3 State resume LVDS DFP screen disappearance bug I am still trying to fix it up completely.). Yeah, it has been pretty discouraging when I have been able to get my patches committed to the public Git repository. I have sent e-mails to several more senior xorg developers (both work at RedHat), so hopefully after a few days (i.e., many people do not resume work probably until January 4th), someone will intervene, and resolve the matter. Just to let you know, starting sometime around February, I may have to reduce my time I spend on OpenChrome probably until late May. Regarding what I have been working on for the past few days, I have been trying to disable the use of display output availability predefined table, and see what happens. Actually, disabling this table is not terribly difficult, but when I do this, even my laptop appears to have issues with screen detection. Ideally, screen detection should be done dynamically via polling 2 to 3 I2C buses available on various VIA Technologies chipsets (One for VGA, one or two for DFP and or TV.). I am now studying how the screen detection and I2C bus polling portion of the code works. I am working on this section because I strongly suspect (although I can be totally wrong) OpenChrome with your computer does not work correctly due to a problem with I2C bus, and in particular, I2C bus #2 and #3 (I2C bus #1 is for VGA. The I2C bus for VGA is typically called VESA DDC.) Regards, Kevin Brace I'm looking forward to what you come up with :) May I ask what happens at the beginning of February? Just curious. Promise :) (In reply to Christopher from comment #112) Hi Christopher, > I'm looking forward to what you come up with :) > > May I ask what happens at the beginning of February? Just curious. Promise :) Yeah, I have been doing some experiments on how the current code base of OpenChrome can wean off using a predefined table for display outputs (i.e., the two patches Xavier uploaded for you to test). After several days of frustrating debugging work, at least for my own VIA Technologies silicon-based laptop (Epic 1314 laptop - MSI VR321 laptop equivalent), I can now boot Lubuntu 12.04 without the use of a display output predefined table. OpenChrome correctly detects an LVDS-based DFP (i.e., laptop LCD screen) and an external VGA monitor, and automatically configure them. Basically, I had to struggle for several days on this issue because a large patch written by Christian Jung had a likely bug that will cause a segmentation fault when ran on devices "without" VT1632A TMDS transmitter (This external small chip is to provide DVI functionality for devices without an integrated TMDS transmitter like VN896 chipset.). http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=a8c2f04e2ef21e64f2e91dd6f3e237f80e8c80c6 Please note that I am not blaming anyone for the likely bug. This large patch was accepted in early January 2015 (almost 1 year ago), but due to the way it was written, it only ran if P4M800 Pro or closely related chipset (i.e., CN700 chipset) was running OpenChrome. The reality is, VT1632A can be hooked up to devices other than P4M800 Pro chipset, and in fact, I do own a dead VN896 chipset industrial computer with VT1632A attached to it for DVI output (I had to write this one off since it died so quickly after I purchased off ebay.) Again, I am trying to make the code more robust by basically doing automatic detection for pretty much all known VIA Technologies external transmitter / encoder devices. I hate to say this, but I think this will likely break some people's Linux-based computers with VIA Technologies integrated graphics since the predefined table probably prevents some computers from freezing during boot time. My view is that this is not nice, but I feel like this project has to cross this bridge of relying less and less on a predefined table at some point, and I feel like this is a good time to go over the hump. This will mean that people who still own VIA Technologies-based computers hopefully can do testing of the newer OpenChrome code base, and let the developers know (I guess I am practically the only one left at this point.) the results. For the next few weeks, I only have access to this laptop I am writing this message. I will like to see the stability of OpenChrome code improve substantially to Intel SandyBridge or later integrated graphics level device driver someday, but I suppose this will take many, many years to get there. So why is what I am working on currently relevant to your situation? It is relevant because I strongly suspect that the issue you are facing is related to display output detection, based on the error messages I have analyzed. In your case, you have VX855 chipset, so in some ways, the situation is better. VX855 chipset has an integrated TMDS transmitter for DVI output, and hardware programming documentation is readily available unlike other chipsets like VN896 chipset. I have soon look into how the integrated DFP (Digital Flat Panel) transmitters (i.e., LVDS and TMDS) are handled in OpenChrome for CX700, VX800, VX855, and VX900 chipsets, and see if I can come up with something for you to try. Of course, I will get a patch ready at that point. I cannot promise when this will be ready, so hopefully I will have something to show for in the next few weeks. Regards, Kevin Brace Immediate thought -- is there a way to 'catch' the driver before things freeze up, so that the table method can be used instead, specifically only as a fallback...? I also gather that you'll be on a trip or vacation or similar in February. If that's the case -- by all means ignore me till you get back and enjoy yourself while you're away. R&R is important. (In reply to Christopher from comment #114) Hi Christopher, > Immediate thought -- is there a way to 'catch' the driver before things > freeze up, so that the table method can be used instead, specifically only > as a fallback...? > This is my personal view, but since late '90s, pretty much all display detection is done automatically, at least in Windows. I am in the camp of people who think that xorg (X Window server) should be easier to use like Windows, hence, more and more of the hardware configuration job should be done automatically. This is why I started to work on weaning off the use of a predefined table for the display output. I am sure there are people who do not like this view, but if one wants to see more mass market adoption of Linux (or BSD), everything should be more automatic. In this sense, I am not a huge fan of having manual-based hardware configuration methods. That being said, if I can eventually, I will like to do away with VBE (VESA BIOS Extension) support since it does not work well with 64-bit OSes. > I also gather that you'll be on a trip or vacation or similar in February. > If that's the case -- by all means ignore me till you get back and enjoy > yourself while you're away. R&R is important. Actually, I am traveling right now. This is why I only have one device that I can use for OpenChrome testing, and it is my Epic 1314 laptop. I brought it for the current multi-week trip specifically to work on OpenChrome development. Back at where I live, I do have access to many more VIA Technologies integrated graphics-based computers, but for now, I only have one computer for testing purposes. I do have other activities in life, hence, I expect to reduce the time I spend on OpenChrome starting around late January until late spring. I am starting to read the code that handles DFP recognition for VX800 and later chipsets. Hopefully, I can make a patch for you to test in a few weeks. I am also trying to obtain Git repository access so that the code base can be updated more frequently. Regards, Kevin Brace Take your time, man! Vacations are for enjoying... Just a thought, but if VBE doesn't play well on 64 bits, why not keep it there for 32 bits? Only if it actually adds any value compared to the alternative, of course. (In reply to Mario Rugiero from comment #117) Hi Mario, > Just a thought, but if VBE doesn't play well on 64 bits, why not keep it > there for 32 bits? Only if it actually adds any value compared to the > alternative, of course. Personally, I do not like anything like VBE, but the way I see is, for historical reasons, it is there. I will like to get rid of it, but I am sure some will be opposed. Although I am probably not enough of an expert to debate the merits, I will be in the camp of not wanting to get rid of XAA code base, if that was possible. This is because there might be someone that might want to compile OpenChrome for old xorg. Off topic, but I have tried to compile the current OpenChrome code base for Ubuntu 8.04 LTS, and after some try, I did manage to find a way to somehow compile it. The reason I say it like this is because I had to fix some code in xorg header files in order for the compilation to go through. To my surprise, it does work, but unfortunately, the top GNOME task bar gets corrupted very quickly (obviously this is a bug), so it is not perfect at all. The current code base does require some changes that I will eventually commit as a patch for the compilation to go through without too much manual code editing. This will not happen for a while since it is not a super important issue to work on. Regards, Kevin Brace I'm not sure. If you want older X.org, why can't you just do with older Openchrome? The way I see it, if you can freeze one, you probably want to freeze everything. Also, as other projects, such as X.org, change, supporting all of the versions out there will rapidly become a huge burden, even more considering Openchrome is currently way understaffed, and it makes sense to me that a driver for X.org is coupled to X.org versions, it is not like we are coupling Openchrome with a specific version of GNOME or something like that. On the particular subject of XAA, I believe it is all or nothing: either it is currently *really* maintained, or it should go. If it were my job, I'd maintain it at most until one or two releases after X.org obsoletes it, to give users time, but after that I'd crop the whole code path, but probaly I'd just wait for EXA to be stable enough. However, it is not my job, so I won't be deciding anything ;) With regards to VBE, I'm not in a position to discuss its merits either. I was just mentioning that if the only reason to ditch it is that it doesn't work well with x86_64, then it could still be useful for x86. If a better alternative is around, I'm always on for keeping the shiny and ditching the rusty. Still, as you said, some will have the opposite view. (In reply to Christopher from comment #116) Hi Christopher, > Take your time, man! Vacations are for enjoying... I think I figured out the precise cause of your bug . . . I looked at how a VGA monitor gets detected in OpenChrome, and it appears that the code is running through a path where OpenChrome failed to detect a VGA monitor via I2C bus. So, I went back and compared the current development version OpenChrome Version 0.3.3 (i.e., the latest stuff you cloned it from the Git repository) versus OpenChrome Version 0.2.904 you claimed that worked fine. I am glad you compared it against OpenChrome Version 0.2.904 since the older version indeed detected monitors using I2C bus, but it was not assuming that only a certain I2C bus was for VGA monitor detection. What happens in your particular system is that the video display port you have is a DVI connector (precisely speaking, DVI-I connector). In VX855 chipset, due to its embedded market focus (Sarcastically, I call this "it is too hard to compete with Intel and AMD, so we will focus on embedded market" business model.), it does come with an integrated TMDS transmitter. DVI's digital portion uses Transition Minimized Differential Signaling (TMDS), a type of high speed signaling technology originally developed by Silicon Image, now Lattice Semiconductor. According to some VIA Technologies documents I found on the Internet, chipsets with an integrated TMDS transmitter do say that certain I2C buses are used for certain purposes. Probably because of this, when the code was completely rewritten in the past few years to prepare for OS kernel-based display resolution setting (People call this KMS or Kernel Mode Setting. The OS kernel device driver now takes care of display control rather than the DDX or Device Dependent X device driver.), the developer "assumed" that only I2C bus 1 is used for VGA monitor detection. The problem is, since VGA does come out of a DVI-I connector and I2C bus 2 is really recommended for use with DVI (according to their documentation I found on the Internet), now the VGA detection code really needs to look at I2C bus 2 as well, because of the way DVI-I connector is designed (it has legacy VGA and DVI, but only one I2C bus). The problem with VIA Technologies hardware programming documentation release policy is that they did release their integrated graphics programming documentation and chipset programming documentation, but they never released the chipset (i.e., VX855 chipset) data sheet. Hence, without the prior experience in the industry working on this type of hardware, it has been very difficult to figure out which I2C bus is connected to which display connector. Because I suspected that the bug you have experienced is an issue related to screen detection (I came up with this in late December 2015.), I have been looking around for their chipset data sheets to give me a physical understanding (Note: I am a digital hardware design background guy.) of what the display hardware looks like. I did find one document somewhat similar to VX855 chipset that did help me understand how they assigned chipset pins for certain display outputs. Just for proof, look at this log from the Git repository code you compiled. ___________________________________________________________________________ . . . [ 72.614] (II) Module "i2c" already built-in [ 72.614] (II) CHROME(0): ViaI2CInit [ 72.614] (II) CHROME(0): ViaI2CBus1Init [ 72.614] (II) CHROME(0): I2C bus "I2C bus 1" initialized. [ 72.614] (II) CHROME(0): ViaI2cBus2Init [ 72.614] (II) CHROME(0): I2C bus "I2C bus 2" initialized. [ 72.614] (II) CHROME(0): ViaI2CBus3Init [ 72.614] (II) CHROME(0): I2C bus "I2C bus 3" initialized. [ 72.614] (II) Loading sub module "ddc" [ 72.614] (II) LoadModule: "ddc" [ 72.614] (II) Module "ddc" already built-in [ 72.614] (II) CHROME(0): ViaOutputsDetect [ 72.614] (==) CHROME(0): LVDS-0 : Digital output bus width is 12 bits. [ 72.614] (==) CHROME(0): LVDS-0 : DVI Center is disabled. [ 72.614] (==) CHROME(0): LVDS Panel will not be forced. [ 72.614] (==) CHROME(0): Panel size is not selected from config file. [ 72.615] (II) CHROME(0): Output VGA-1 using monitor section Monitor0 [ 72.615] (**) CHROME(0): Option "PreferredMode" "1280x1024" [ 72.616] (II) CHROME(0): I2C device "I2C bus 1:ddc2" registered at address 0xA0. [ 72.623] (--) CHROME(0): Test for CRT with VSYNC [ 72.623] (II) CHROME(0): EDID for output VGA-1 [ 72.624] (II) CHROME(0): Output VGA-1 disconnected [ 72.624] (WW) CHROME(0): No outputs definitely connected, trying again... [ 72.624] (II) CHROME(0): Output VGA-1 disconnected . . . ___________________________________________________________________________ Here is the log with OpenChrome Version 0.2.904 (i.e., the one that worked). ___________________________________________________________________________ . . . [ 146.369] (II) LoadModule: "i2c" [ 146.369] (II) Module "i2c" already built-in [ 146.370] (II) CHROME(0): ViaI2CInit [ 146.370] (II) CHROME(0): ViaI2CBus1Init [ 146.370] (II) CHROME(0): I2C bus "I2C bus 1" initialized. [ 146.370] (II) CHROME(0): ViaI2cBus2Init [ 146.370] (II) CHROME(0): I2C bus "I2C bus 2" initialized. [ 146.370] (II) CHROME(0): ViaI2CBus3Init [ 146.370] (II) CHROME(0): I2C bus "I2C bus 3" initialized. [ 146.370] (II) Loading sub module "ddc" [ 146.370] (II) LoadModule: "ddc" [ 146.370] (II) Module "ddc" already built-in [ 146.370] (II) CHROME(0): I2C device "I2C bus 1:ddc2" registered at address 0xA0. [ 146.373] (II) CHROME(0): ViaOutputsDetect [ 146.373] (II) CHROME(0): VIATVDetect [ 146.375] (II) CHROME(0): ViaDFPDetect [ 146.375] (II) CHROME(0): I2C device "I2C bus 2:ddc2" registered at address 0xA0. [ 146.428] (II) CHROME(0): Manufacturer: DEL Model: a023 Serial#: 858928979 [ 146.428] (II) CHROME(0): Year: 2007 Week: 4 [ 146.429] (II) CHROME(0): EDID Version: 1.3 [ 146.429] (II) CHROME(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V [ 146.429] (II) CHROME(0): Sync: Separate [ 146.429] (II) CHROME(0): Max Image Size [cm]: horiz.: 34 vert.: 27 [ 146.429] (II) CHROME(0): Gamma: 2.20 [ 146.429] (II) CHROME(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display [ 146.429] (II) CHROME(0): Default color space is primary color space [ 146.429] (II) CHROME(0): First detailed timing is preferred mode [ 146.429] (II) CHROME(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 [ 146.429] (II) CHROME(0): blueX: 0.150 blueY: 0.060 whiteX: 0.312 whiteY: 0.329 [ 146.429] (II) CHROME(0): Supported established timings: [ 146.429] (II) CHROME(0): 720x400@70Hz [ 146.429] (II) CHROME(0): 640x480@60Hz [ 146.429] (II) CHROME(0): 640x480@75Hz [ 146.429] (II) CHROME(0): 800x600@60Hz [ 146.429] (II) CHROME(0): 800x600@75Hz [ 146.429] (II) CHROME(0): 1024x768@60Hz [ 146.429] (II) CHROME(0): 1024x768@75Hz [ 146.429] (II) CHROME(0): 1280x1024@75Hz [ 146.429] (II) CHROME(0): Manufacturer's mask: 0 [ 146.429] (II) CHROME(0): Supported standard timings: [ 146.429] (II) CHROME(0): #0: hsize: 1152 vsize 864 refresh: 75 vid: 20337 [ 146.429] (II) CHROME(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [ 146.430] (II) CHROME(0): Supported detailed timing: [ 146.430] (II) CHROME(0): clock: 108.0 MHz Image Size: 338 x 270 mm [ 146.430] (II) CHROME(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 [ 146.430] (II) CHROME(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 [ 146.430] (II) CHROME(0): Serial No: UH57271L327S [ 146.430] (II) CHROME(0): Monitor name: DELL E177FP [ 146.430] (II) CHROME(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 80 kHz, PixClock max 145 MHz [ 146.430] (II) CHROME(0): EDID (in hex): [ 146.430] (II) CHROME(0): 00ffffffffffff0010ac23a053373233 [ 146.430] (II) CHROME(0): 0411010368221b78eeee91a3544c9926 [ 146.430] (II) CHROME(0): 0f5054a54b00714f8180010101010101 [ 146.430] (II) CHROME(0): 010101010101302a009851002a403070 [ 146.430] (II) CHROME(0): 1300520e1100001e000000ff00554835 [ 146.430] (II) CHROME(0): 373237314c333237530a000000fc0044 [ 146.430] (II) CHROME(0): 454c4c204531373746500a20000000fd [ 146.430] (II) CHROME(0): 00384b1f500e000a2020202020200005 [ 146.430] (II) CHROME(0): EDID vendor "DEL", prod id 40995 . . . ___________________________________________________________________________ Here is the critical part of the OpenChrome Version 0.2.904 log. ___________________________________________________________________________ . . . [ 146.370] (II) Module "ddc" already built-in [ 146.370] (II) CHROME(0): I2C device "I2C bus 1:ddc2" registered at address 0xA0. [ 146.373] (II) CHROME(0): ViaOutputsDetect [ 146.373] (II) CHROME(0): VIATVDetect [ 146.375] (II) CHROME(0): ViaDFPDetect [ 146.375] (II) CHROME(0): I2C device "I2C bus 2:ddc2" registered at address 0xA0. [ 146.428] (II) CHROME(0): Manufacturer: DEL Model: a023 Serial#: 858928979 [ 146.428] (II) CHROME(0): Year: 2007 Week: 4 [ 146.429] (II) CHROME(0): EDID Version: 1.3 . . . ___________________________________________________________________________ You can clearly see that I2C bus 2 is detecting your Dell monitor, and properly obtaining EDID from the monitor. I will need to rewrite the code so that, for now, I2C bus 1 and 2 are both used for detecting a VGA monitor. In the long run, display detection code needs to be rewritten completely since display detection and allocation is done atomically by display type (i.e., VGA, TV, LVDS FP, DVI, etc.) currently. The rewritten code should complete display detection first, and then allocate display resources based on what was detected. I hope to get a patch for you to test, hopefully in the next several days (I already wrote the code, but have not tested it yet.). Give me as much as a week for the patch to be ready (I need to set up a different local repository on my computer.). Regards, Kevin Brace Hi Christopher,
I will start posting 7 patches over the next 2 days.
Before you apply the patch, please clone the latest (May 2015) source code from the Git repository.
$ git clone git://anongit.freedesktop.org/openchrome/xf86-video-openchrome
After that, download 7 patches to the source code, and compile it.
If my hypothesis about the cause of the bug is correct (i.e., I2C bus 2 can be connected to a VGA input, in addition to I2C bus 1), you should see something on the screen.
Please do not apply the patches to the existing patched version code since the patch command may get confused when you do this.
I am sure you know how to apply the patch, but just in case you forgot,
$ patch -p1 < 0001*.patch
If you apply the patch like this, obviously, I am assuming that the patch file is located under /xf86-video-openchrome.
To apply the next patch, you just change the "0001" to "0002" and so on and so forth.
The patches are far from perfect, at least in terms of permanently fixing the bug.
To really fix the bug, pretty much the entire display detection and resource allocation code needs to be rewritten.
That being said, the quality of the patch is high enough that I think it can be committed to the Git repository.
The permanent fix will have to be implemented at a later date.
Regards,
Kevin Brace
Created attachment 121084 [details] [review] Substitution of VIA_VM800 label with VIA_P4M800PRO label Replaces VIA_VM800 label with VIA_P4M800PRO label inside via_driver.c due to the fact that there is no such product as VM800 chipset from VIA Technologies. Of course, references to VIA_VM800 label in other files were also replaced as well. The VM800 chipset the source code refers to really is P4M800 Pro chipset. Also, the source code refers to a product called VN800 chipset, and this is similar (related) to P4M800 Pro chipset. The compiled device driver was tested on the following computer. - Epic 1314 laptop (MSI VR321 laptop equivalent, VN896 chipset) with Lubuntu 12.04 i386 Created attachment 121085 [details] [review] General improvement of via_i2c.c Added debug messages to via_i2c.c in order to aid the debugging effort. Adjusted bus timing related parameters for I2C bus 2 and 3. Created attachment 121086 [details] [review] Added debug messages to via_vt1632.c Added debug messages to via_vt1632.c in order to aid the debugging effort. Created attachment 121087 [details] [review] General improvement of via_tv_init function Added debug messages to via_tv_init function inside via_outputs.c in order to aid the debugging effort. Made small adjustments to better handle error conditions as well. Created attachment 121088 [details] [review] General improvement of via_dvi_init function Added debug messages to via_dvi_init function inside via_outputs.c in order to aid the debugging effort. Changed the function return type to boolean type. Made small adjustments to better handle error conditions as well. Created attachment 121089 [details] [review] Using I2C bus 2 to also detect a VGA monitor Previously, it was assumed that only I2C bus 1 was used to detect a VGA monitor. However, devices with a DVI-I connector do have VGA signals come out of the connector, but in many VIA Technologies chipsets, the I2C bus 2 is typically used to detect a DVI monitor. Therefore, I2C bus 2 also needs to be used to detect a VGA monitor. Created attachment 121090 [details] [review] Discontinuing the use of a predefined display output table This update will be a major one for OpenChrome. The internal predefined display output table previously used to initialize display outputs is no longer going to be used except for OLPC XO-1.5. This means that OpenChrome will go through scanning each I2C bus to determine what display output type is connected before initializing the display. This is a highly risky update that will likely break OpenChrome for some users. However, the general trend of computing industry has been going in the direction of automatically detecting and configuring connected display devices, and because of this, it is author's view that OpenChrome needs to stop relying on an outdated concept like the use of a predefined table to figure out which display output should be initialized. The compiled device driver was tested on the following computer. - Epic 1314 laptop (MSI VR321 laptop equivalent, VN896 chipset) with Lubuntu 12.04 i386 Hi Christopher,
I finished uploading the patches.
I spent pretty much all day working on this issue for Saturday . . .
Please try to boot your system with all the patches applied, and of course, the patches must be applied in the order they are numbered.
The second patch from the last one has a flaw where anything detected on the I2C bus 2 is considered VGA capable.
This is the major flaw of the patch, and it is my view that I will have to rewrite the code completely in order to remedy this situation.
That being said, it does work with my own laptop, so I loaded it for you to try.
The last patch is a controversial one where I "nuked" the predefined table for display output.
It is still in the code, but the code will ignore it for the purpose of determining which display output will be turned on.
Now the code will go through detecting all known external transmitters / encoders like VT1632A TMDS transmitter, VT1622 TV encoder, etc. in all VIA Technologies Chrome-based integrated graphics chipsets (CLE266 through VX900).
I do not know if my laptop has VT1636 LVDS transmitter, but the code appears to work fine with my laptop.
I would imagine this will cause some problems with some people, but I feel strongly that OpenChrome needs to stop using a predefined table as soon as possible.
The UMS code already has support for automatic detection of pretty much all known external transmitters (VIA Technologies and Chrontel for TV encoding), so I figured it is about time we stop using that predefined table.
Regards,
Kevin Brace
I'll test them as soon as I can -- my IRL world is a bit of a mess right now. What's relevant is that, for the first time in my life I'm having to figure out all the parameters of moving myself out of a household, in the midst of a severe drama storm, and it's all quite difficult. I may have some time today or tomorrow to test, though, and I'll see if I can get it to happen. No promises. (In reply to Christopher from comment #131) Hi Christopher, Since I am flying back from where I am staying right now on Tuesday, and I have a trade show I am attending on Wednesday, I will not be working on this matter until Thursday. I hope the patch works, and if it does, I will incorporate the results when I rewrite the display output detection and resource allocation portion of the code. Regards, Kevin Brace > I'll test them as soon as I can -- my IRL world is a bit of a mess right > now. What's relevant is that, for the first time in my life I'm having to > figure out all the parameters of moving myself out of a household, in the > midst of a severe drama storm, and it's all quite difficult. I may have some > time today or tomorrow to test, though, and I'll see if I can get it to > happen. No promises. Well, the drama storm moved away, and has been replaced with a more meteorological monster of a mess. I still have power... but that could change at any minute. When I'm dug out of all this snow and ice I'll get back on this. That will possibly be tomorrow, if things don't get any worse than they are now. I'll keep you posted... My version of "patch" doesn't seem to want to work. If I include the -p option, it errors out with: # patch -pl < 0001*.patch patch: **** strip count l is not a number If I do not include that option, it asks me to manually specify the file to patch, for each of two sections of code. Looking at the patch file, it appears to be human-readable text. I only wish I knew what I could safely delete in order to get this to work! (In reply to Christopher from comment #134) > # patch -pl < 0001*.patch > patch: **** strip count l is not a number Don't use an el, use a one. -p1, not pl. Oh, duh. I feel dumb now... someone did correct me on that before, awhile back, and I'd forgotten it. Whose idea was it to use this lousy font, anyways? :P I can barely read it, even on a *good* screen. Patches 0001 through 0003 work, but 0004 fails with an error. # patch -p1 < 0004*.patch bash: 0004*.patch: ambiguous redirect # I'll wait for the fix before I continue patching... looked at the code to see if I could find it myself -- Ha! might as well be Egyptian Hieroglyphics. Can't read a word. Wish I could. Learning C is on my list -- trouble is it's in the sub-list called "someday, maybe" ;) I do have a project I want to do, that I could do far more easily in C than in say QuickBASIC which is what I've got now -- but I don't seem to have enough interest to move that task into more urgent territory. Oh well... (In reply to Christopher from comment #136) Hi Christopher, > Oh, duh. I feel dumb now... someone did correct me on that before, awhile > back, and I'd forgotten it. Whose idea was it to use this lousy font, > anyways? :P I can barely read it, even on a *good* screen. > > Patches 0001 through 0003 work, but 0004 fails with an error. > > # patch -p1 < 0004*.patch > bash: 0004*.patch: ambiguous redirect > # > > I'll wait for the fix before I continue patching... looked at the code to > see if I could find it myself -- Ha! might as well be Egyptian > Hieroglyphics. Can't read a word. I tested the patches using the Git commit 47060a3d770b90ed96924b4260dce38bdafedfde as the head (Type: "git log"). I applied all 8 patches in a row, and none of them returned errors. Based on the error message you got, I suspect you have more then two patches named 0004-*.patch in your xf86-video-openchrome directory (folder). You should clone the current OpenChrome image in a new fresh working directory so that you do not have older patches you got previously from Xavier or me because this can cause confusion. I will replace patch 6 and 7 shortly since I made small improvements that will resolve an issue I was aware of. Regards, Kevin Brace Created attachment 121238 [details] [review] Using I2C bus 2 to also detect a VGA monitor Previously, it was assumed that only I2C bus 1 is used to detect a VGA monitor. I2C bus 2 is typically used to detect a DVI monitor via a DVI connector. For devices with a DVI-I connector, VGA signals come out of the connector. What this means is that I2C bus 2 also has to be used to detect a VGA monitor, in addition to I2C bus 1. Created attachment 121239 [details] [review] Determine the interface type for VGA detection The previous version of the code that took into consideration using I2C bus 1 and 2 to obtain EDID did not examine whether or not the monitor connected to is a digital or analog type. Since I2C bus 2 is often connected to a digital type interface, this meant that VGA monitor detection code was misdetecting the connected output type if I2C bus 1 did not detected a monitor (i.e., VGA monitor), but I2C bus 2 detected a monitor (likely a DVI monitor or LVDS flat panel). Now the code will look to see if the connected type is an analog type interface before recognizing it as a likely VGA monitor. Created attachment 121240 [details] [review] Reducing the use of a display output table This update will be a major one for OpenChrome. The use of an internal predefined display output table for known devices previously used to initialize display outputs will be reduced. What this means is that OpenChrome will go through scanning each I2C bus to determine which display output type is connected before initializing the display. In practice, the predefined display output table is still used, but OpenChrome is far less dependent on it. This is a highly risky update that will likely break OpenChrome for some users. However, the general trend of computing industry has been going in the direction of automatically detecting and configuring connected displays. It is author's view that OpenChrome needs to stop relying on an outdated concept like the use of a predefined table to figure out which display output should be initialized. The compiled device driver was tested on the following computer. - Epic 1314 laptop (MSI VR321 laptop equivalent, VN896 chipset) with Lubuntu 12.04 i386 Hi Christopher,
If you wanted to do a hard reset on the code you previously cloned from the Git repository, type,
git reset --hard ("Commit ID")
If you wanted to see the the previous commit ID, type,
git log
For example, if you wanted to reset the code to the current head, type,
git reset --hard 47060a3d770b90ed96924b4260dce38bdafedfde
This is the current head (as of January 23rd, 2016).
http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=47060a3d770b90ed96924b4260dce38bdafedfde
Now, make sure that no other patch files other than the ones I uploaded in the past few days specifically for you are in the /xf86-video-openchrome directory.
Download those 8 patches (I updated two of them, and added one of them just now.) to /xf86-video-openchrome.
From inside /xf86-video-openchrome directory, apply the patches.
patch -p1 < 0001*.patch
If you can, cut and paste the text when you apply the commands (You don't have to, but the use of cut and paste can reduce errors.) within the terminal.
Now repeat the above command 7 more times with "0001" incremented by 1 at a time (i.e., 0002, 0003, etc.).
Alternatively, you can hard code the entire *.patch file name like this.
patch -p1 < 0001-Substitution-of-VIA_VM800-label-with-VIA_P4M800PRO-l.patch
If you do this, you need to type in the entire file name 7 more times.
This is why I used a wildcard to make your life easier (I guess it did not work out too well.).
After you try it, please upload the Xorg.0.log file so that I can take a look at what happened.
I am cautiously optimistic that the fix will work.
You should use the DVI to VGA dongle rather than direct DVI connection since the fix I made only deals with VGA.
If straight DVI does not work, we will need to fix that in the near future.
I am hoping this fix will be included in the upcoming OpenChrome Version 0.3.4 release so that you do not have to ever suffer from the same issue in the future.
Regards,
Kevin Brace
(In reply to Christopher from comment #133) Hi Christopher, > Well, the drama storm moved away, and has been replaced with a more > meteorological monster of a mess. I still have power... but that could > change at any minute. When I'm dug out of all this snow and ice I'll get > back on this. That will possibly be tomorrow, if things don't get any worse > than they are now. > > I'll keep you posted... I was buried in snow where I was staying until Tuesday. I am now back in a warmer place although we are now going through what some call "Godzilla El Niño." I suppose our state will like to store all the rain water since we just went through a 4 year super drought. I just switched ISP (Internet Service Provider), and it appears that the provider I switched to is a rather amateur one . . . Not only they weren't able to activate my Internet service from Day 1, but they will not be able to come fix their equipment issue for another 9 more days . . . This will slow down my OpenChrome testing on various VIA Technologies integrated graphics chipset since most of them are desktop computers. For now, I will only have one laptop computer for testing purposes. Regards, Kevin Brace Got it to compile, patches and all. Now to repeat on the target machine, rather than this fancypants Dell laptop. Well, after arguing like **** with the computer (timezone & clock were set incorrectly), I got it to compile on the WYSE client. Did "make install", ran xorgwizard then manually edited xorg.conf so it would actually *work* -- and typed # xwin pressing ENTER afterwards. Cursor blinked for a sec, then a bunch of gobbledegook mess on the top 1/4 of the screen and a system that was so frozen hard I think it got freezer-burnt. Needless to say there won't be any logs out of *that*. Puppy gets amnesia when it gets a hard reboot. Oh well. Redid it today, following the guidelines of the Internet definition of insanity ;) I will attach a photo of the results on the screen shortly... maybe you can sort out what I'm seeing, when your ISP gets straightened out? Created attachment 121244 [details]
Photo of effect from patched driver
(In reply to Christopher from comment #144) Hi Christopher, > Well, after arguing like **** with the computer (timezone & clock were set > incorrectly), I got it to compile on the WYSE client. Did "make install", > ran xorgwizard then manually edited xorg.conf so it would actually *work* -- > and typed > > # xwin > > pressing ENTER afterwards. > > Cursor blinked for a sec, then a bunch of gobbledegook mess on the top 1/4 > of the screen and a system that was so frozen hard I think it got > freezer-burnt. > > Needless to say there won't be any logs out of *that*. Puppy gets amnesia > when it gets a hard reboot. > > Oh well. One thing I am wondering is, did the crash behavior change between pre-patch version compiled OpenChrome device driver and the patched version? It appears that the crash pattern is different since, if I am correct, you said previously that the display will go blank. I will still need Xorg.0.log to analyze what happened. I hope Xorg.0.log is obtainable, although it is quite possible that if you boot from a USB flash storage stick, it stores the log filed as a RAM disk. I also recommend using a minimalist xorg.conf since OpenChrome does not require the use of it post Ubuntu 10.04 LTS. In my VIA Technologies silicon laptop (C7-M processor and VN896 chipset), I do not use xorg.conf at all. Based on my own testing, the patched device driver works fine. Regards, Kevin Brace Behavior is indeed different. Before it would either fail with a nonblinking cursor, fail with a blinking cursor, or not last long enough to get out of text mode. I will try and boot it again (I rebooted to save the driver progress, so that I wouldn't have to compile it *again* and the image is what I got upon it coming back up and trying to GUI) and see if it can be caught and CTRL+ALT+BKSP'd before everything packs up and goes away. If I can't do that, I will have to reinstall a different way, compile the driver all over again, and get the files that way... the way it's installed now it runs in RAM which is bad for crash reports but better for the drive I'm using in it -- an SD card in an IDE adapter. (Hey, it fits in the housing! A 2.5" drive would not, and the system does not have enough oomph to spin up a mechanical hard drive of any kind.) We'll see what happens. I'll keep you posted :) (In reply to Kevin Brace from comment #147) > In my VIA Technologies silicon laptop (C7-M processor and VN896 chipset), I > do not use xorg.conf at all. > Based on my own testing, the patched device driver works fine. I mean to say, based on my own testing, the patched device driver works fine on my laptop (LVDS flat panel + external VGA connector). Of course, you have a different hardware configuration than my laptop, so it might not work. As far as I can tell, I do not really have a desktop mainboard that has VIA Technologies chipset with DVI. I did recently obtain a Wyse thin client with a DVI connector, but it does not have USB flash memory stick boot capability (apparently, it can boot from a 44 pin PATA 2.5" hard drive). I used to have a 3.5" industrial computer board that had an external TMDS transmitter for DVI (VT1632A), but it never worked (it won't even boot). Regards, Kevin Brace What WYSE client do you have? Mine is a "Cx0 series" -- specifically a C90LE. I have a couple spare "disk on module" units that can plug into that 44pin connector, and if you're in the USA, email me your mailing address (don't post it here!) and I will send you one with Puppy preinstalled. In the meantime, I can confirm that as soon as the display comes up the system hangs, screen full of nasty. I can also confirm that the logs are not written to disk at that point. I have one idea that may make it so that I don't have to install the ugly way -- I'm trying to avoid that because it dramatically increases wear on the SD card, and I can't afford another at this time. 64gb SDXC cards are not cheap, particularly in my income bracket! I'll know if it worked, in the next ten to fifteen minutes. (In reply to Christopher from comment #148) Hi Christopher, > Behavior is indeed different. Before it would either fail with a nonblinking > cursor, fail with a blinking cursor, or not last long enough to get out of > text mode. > > I will try and boot it again (I rebooted to save the driver progress, so > that I wouldn't have to compile it *again* and the image is what I got upon > it coming back up and trying to GUI) and see if it can be caught and > CTRL+ALT+BKSP'd before everything packs up and goes away. > > If I can't do that, I will have to reinstall a different way, compile the > driver all over again, and get the files that way... the way it's installed > now it runs in RAM which is bad for crash reports but better for the drive > I'm using in it -- an SD card in an IDE adapter. (Hey, it fits in the > housing! A 2.5" drive would not, and the system does not have enough oomph > to spin up a mechanical hard drive of any kind.) > > We'll see what happens. I'll keep you posted :) I will say that based on dealing with OpenChrome for a while, when my Lubuntu 12.04 i386 boots back from hibernation, it does display some junk on the screen somewhat similar to what you saw. Of course, I do not like this, and I plan to remedy this down the road (at this point, it is a low priority since it is not a fatal bug). I would imagine it is merely displaying whatever in the RAM considering that we are dealing with an integrated graphics based system here. When the computer boots up, the RAM that was not really used during the boot up is undefined. DRAM (Dynamic RAM) used for pretty much all computer working memory requires constant refreshing (i.e., one refresh command per 7.8 micro seconds typical for recent DRAM devices) to maintain the stored contents. If a refresh command was not issued for a while (i.e., not maintaining one refresh command per 7.8 micro seconds average), than the contents of the RAM can change randomly (i.e., DRAM is made out of capacitors, and capacitors leak charge). Regards, Kevin Brace I can confirm that my little trick worked. Puppy boot option "pmedia=" is sometimes used to tell Puppy where to look to find itself. I had previously set pmedia=ataflash (to indicate an IDE or SATA flash-based install medium). Changing it to pmedia=atahd makes Puppy thinks it's installed to a platter drive, which makes it write things differently (more often). It's okay to run that way for a little while but I don't make a habit of it. One Xorg.0.log comin' up! Created attachment 121253 [details]
Xorg.0.log from crashing patched driver
For the sake of completeness -- I've managed to figure out some of the potential issues and get rid of them. One, bit-depth has been corrected to 16 rather than 24. Two, I disabled GLX. Results in all cases are the same: a screenful of gunk. (In reply to Christopher from comment #154) Hi Christopher, > For the sake of completeness -- I've managed to figure out some of the > potential issues and get rid of them. > > One, bit-depth has been corrected to 16 rather than 24. > > Two, I disabled GLX. > > Results in all cases are the same: a screenful of gunk. You should continue to use 24 bit or 32 bit color. I do not use 16 bit color at all, although in theory, it should work. Furthermore, I am concerned that the OS crashes after loading GLX. ______________________________________________________________________ . . . [ 169.253] (II) Module "extmod" already built-in [ 169.253] (II) LoadModule: "glx" [ 169.260] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so ______________________________________________________________________ I feel like there is an issue other than loading GLX. If possible, it will be preferable if you can use the OS environment virtually identical to what you had in September 2015. I am also wondering if you got the pre-patched version OpenChrome from the Git repository, will the OS get to the previous point of where you were? (i.e., Screen was not recognized, but you were able to get access to Xorg.0.log.) And, after you confirm that it got to that point, if you can install the patched version OpenChrome then we are now performing "before and after" analysis. I appreciate getting the Xorg.0.log though since without it, there is not much I can do to begin with. Regards, Kevin Brace I have been told numerous times that the hardware physically does not have enough wires to support anything higher than 16-bit color. Not an issue for me, and I'm an artist! (Well, we *are* known to be a bit persnickety... ;) ) I seem to recall that GLX-disabling in xorg.conf doesn't always work. I may also have a bad glx.so and not know it, but I find that quite unlikely because I'd have probably heard it mentioned on the Puppy Forum by now. Still, worth checking into. IIRC I have been using the same Pup the whole time. X-Tahr 1b3 is identical to TahrPup 6.0.2, with the sole exceptions that JWM and ROX-Filer have been replaced with XFCE and Thunar. Xorg.0.log and Xerrs.log attachments from previous reportings do exist from the Git build at the time, and are labeled as such. As Xerrs.log is stored in /tmp, it gets deleted at powerdown. Did some more testing work on this. A bit of background. May have explained this before. If so, I apologize. There are two ways of installing Puppy Linux. One is a "frugal" install and the other is a "full" install, in the lingo we use. A "full" install is a traditional Linux unpack-n-set-up-all-over-a-partition install. (Windows does it the same way, of course.) A "frugal" install mimics a LiveCD -- the SquashFS file containing the primary filesystem is copied over (sometimes there's an extra one for drivers) along with the initrd.gz (init f/s) and vmlinuz (kernel) files, and a bootloader is applied (GRUB if you're smart, grub4dos if you're me) -- and that's it. When Puppy boots from a "frugal" install, it unpacks the SFS file(s) into RAM and runs from there, saving changes to a separate changelog sort of file (or, more recently, folder) that we call a "savefile" (or "savefolder"). I've been using a "frugal" install of Puppy, which is actually the preferred and suggested method, for all of the testing so far, and involving persistence by way of a savefolder. I decided to plow that under today and go for a "full" install, to see if it behaved differently enough that it would perhaps aid in debugging. It did -- although, not in the way I'd hoped -- I didn't get /tmp/Xerrs.log. That said, one new Xorg.0.log coming up! I think it got farther this time, too... log looks longer. It also didn't futz the screen. I got a blinking cursor, then a smaller nonblinking cursor at which it hung. Dunno. Created attachment 121285 [details]
Xorg.0.log from crashing patched driver, "full" install
Hi Christopher,
I am writing this from a tablet computer, so it will be short.
Thank you very much for further troubleshooting the bug.
I read the Xorg.0.log you just attached, and it appears that VT1632A TMDS transmitter is attached to VX855 chipset.
Several weeks ago when I was changing the code so that OpenChrome relies less and less on a predefined display output table, I noticed that one developer (Christian Jung) donated several hundred lines of code to support VT1632A in January 2015.
Interestingly, VT1632A initialization was invoked only when P4M800 Pro and related chipsets (i.e., VN800 and CN700 chipsets) were in use.
The reason why DVI did not work at all previously is due to this.
I removed this restriction so that VT1632A is initialized regardless of which chipset is in use.
Actually, there was a showstopper bug in the donated code, but I did already fixed that issue (I forgot to mention this in one of the patch I uploaded for you to try.).
VT1632A is detectable via I2C bus, and the donated code does that.
It appears that using I2C bus 2 for VGA detection has number of problems at this point.
Earlier today, I was testing your patches with an ASRock mainboard with P4M900 chipset (I do not recall the exact name, but it is something like P4VM900-SATA2.), and it did cause a freeze of the system.
However, the same patches worked fine with K8M800 chipset (ABIT KV-80).
I will try to make adjustments to the I2C bus timings to see if it improves the situation.
The patches that will deal with this situation might take several days since I have some stuff planned for the next several days.
I ended up writing quite a bit.
Regards,
Kevin Brace
(In reply to Christopher from comment #156) Hi Christopher, > I have been told numerous times that the hardware physically does not have > enough wires to support anything higher than 16-bit color. Not an issue for > me, and I'm an artist! (Well, we *are* known to be a bit persnickety... ;) ) Every VIA Technologies integrated graphics supports 32-bit color. Of course, the performance is not meant to be that high due to cost and other reasons, so maybe that is how that urban legend got started. That being said, using 16 bit color reduces screen refresh bandwidth requirement by half, and for CLE266 chipset, this can be substantial. For VX855 chipset, since we are using DDR2-533 or 667 DDR2 SDRAM (single channel), I strongly doubt that this has much performance hit. You should not notice too much performance differences due to the much higher memory bandwidth of DDR2 SDRAM. Regards, Kevin Brace I did some research and came across a PDF from Dell (which now owns WYSE) referring to the C10LE -- one of several Cx0 models, the differences between which being capacities of RAM and internal storage as well as preinstalled OS. It does explicitly refer to the system as having up to 32bpp bit depth, so I sit corrected :) I should also note that my HP t5630w (which carries the same motherboard, CPU, and chipset as the t5145, t5540, t5545, and t5630 non-w)which is an entirely different offering of course -- it has the same CPU as this dang WYSE thing, but a VX800 chipset instead of the VX855. It works almost flawlessly with openchrome. It's a little slow to bring up the display (sequence is -- screen of gunk > black screen + console cursor > black screen + console and mouse cursors > full desktop, with ghost of console cursor remaining) but it DOES work. I suspect that the plodding-ness of it is the CPU rather than the chipset... VIA CPUs just kind of suck. Last thing. The full install display fail went a little differently. No screen full of junk -- it went to a black screen w/ blinking cursor, then a black screen w/o cursor. Get yourself a Bluetooth keyboard for that tablet :P they're cheap on eBay I hear... or, better yet, get an ASUS netbook. I personally can recommend the ASUS 1000HE -- I've had mine since 2009 and it's been positively amazing. You might find this page useful on the WYSE Cx0 series and what it can do --> http://www.parkytowers.me.uk/thin/wyse/cx0/index.shtml ...and this simpler one on the HPs I mentioned --> http://www.parkytowers.me.uk/thin/hp/t5540/index.shtml Hi Christopher,
Can you try the DVI cable if you still have it? (If you did not return it to Best Buy?)
This is because VT1632A TMDS transmitter for DVI was detected by OpenChrome, so I will like to see what happens when you attach a monitor with DVI input.
Regarding the freeze issue I experienced yesterday with ASRock P4VM900-SATA2 mainboard, it appears to be monitor specific.
Off topic, but I collected ABIT IP-95 mainboard from a electronics junkyard today.
I do not own a mainboard with P4M890 chipset, so this one will be used for OpenChrome validation purposes in the future.
Regards,
Kevin Brace
I could've sworn I told you -- but it appears, looking back in the comments, that I have a liar for a memory ;) I *DID* try DVI, shortly before plowing under the frugal install. The display --near as I could tell-- just went to sleep rather than displaying all that crap like in the photo. It's a different display* and it doesn't put messages up on an overlay, it just has a couple "trouble" LEDs that are nearly useless for anything. If you need me to, I can try again with the full install and possibly (no guarantees!) get a log out of it this time. *Up till recently my screen of choice was an HP vs17 or vs17c -- they're identical except for the (quite tiny) label AFAICT so I get mixed up as to which is which. Recently I switched to an HP vf52, which is an XGA (1024x768) display rather than SXGA (1280x1024). The DVI monitor is a circa-2007 Dell XGA pile of crap LCD that requires a proprietary fat ugly lunker of a power brick as well -- not that the screen's any lighter as a result, either... (In reply to Christopher from comment #163) Hi Christopher, > I could've sworn I told you -- but it appears, looking back in the comments, > that I have a liar for a memory ;) > > I *DID* try DVI, shortly before plowing under the frugal install. The > display --near as I could tell-- just went to sleep rather than displaying > all that crap like in the photo. It's a different display* and it doesn't > put messages up on an overlay, it just has a couple "trouble" LEDs that are > nearly useless for anything. > > If you need me to, I can try again with the full install and possibly (no > guarantees!) get a log out of it this time. > > *Up till recently my screen of choice was an HP vs17 or vs17c -- they're > identical except for the (quite tiny) label AFAICT so I get mixed up as to > which is which. Recently I switched to an HP vf52, which is an XGA > (1024x768) display rather than SXGA (1280x1024). The DVI monitor is a > circa-2007 Dell XGA pile of crap LCD that requires a proprietary fat ugly > lunker of a power brick as well -- not that the screen's any lighter as a > result, either... I have not been feeling that well for the past few days, and I have other commitments, so I have not worked on fixing bugs of OpenChrome for the past few days. I will have to say that I will need to reduce my time spent on OpenChrome development starting today . . . Starting today, please don't expect daily progress on fixing this bug. Of course, this was planned for a while (I did announce this in December or January.). Obviously, I am not giving up on fixing the bug. That being said, I do need these files for me to continue debugging the bug. - Xorg.0.log from the full install with VGA cable (via DVI to VGA dongle) - Xorg.0.log from the full install with DVI cable You can probably stick to Dell monitor, but if you wanted to, you can upload the Xorg.0.log from different LCD monitors with VGA input. Your bug is one that needs to be eradicated before we can release OpenChrome Version 0.3.4 or 0.3.5. Regards, Kevin Brace Hi Christopher, I am not a huge fan of thin clients, but I did obtain two Wyse models recently. The first one is Wyse V10L of VX0 series. The second one is Wyse C00X of Cx0 series. I believe the second one is identical to your model, and it was brand new (Unopened; it was manufactured in 2010.). Both of do have the VT1632A TMDS transmitter for DVI output (DVI-I). The reason I said I am not a huge fan of it is because it appears that the installation process is rather different than conventional Linux-based OS with a hard drive or SSD. I know you are used to doing it, but I have never done this type of installation I obtained two of them for a total of $33, well below my monthly computer related equipment purchase "allowance." Regards, Kevin Brace Created attachment 121407 [details]
General improvement of via_dp_detect function
Added debug messages to via_dp_detect function inside via_outputs.c in order to aid the debugging effort. Made small adjustments to better handle error conditions as well.
Created attachment 121408 [details] [review] Adjusting I2C Bus 2 timings Due to freezes observed in several platforms, the timing parameters for I2C Bus 2 will be adjusted. Created attachment 121409 [details] [review] General improvement of via_dp_detect function Added debug messages to via_dp_detect function inside via_outputs.c in order to aid the debugging effort. Made small adjustments to better handle error conditions as well. Created attachment 121410 [details] [review] Adjusting I2C Bus 2 timings Due to freezes observed in several platforms, the timing parameters for I2C Bus 2 will be adjusted. Hi Christopher, I doubt these 2 new patches will make a difference, but you can apply them, and see what happens. As discussed in Comment #164, I do need these files for me to continue debugging the bug. - Xorg.0.log from the full install with VGA cable (via DVI to VGA dongle) - Xorg.0.log from the full install with DVI cable You can probably stick to Dell monitor, but if you wanted to, you can upload the Xorg.0.log from different LCD monitors with VGA input. As discussed previously, I will need to reduce my time spent on OpenChrome until early June 2016. I do also have other bugs I am trying to get rid of, so some of my precious time I have will be spent on those issues as well. Regards, Kevin Brace A Cx0-series client is what I have. Mine is an Oct 2009 version, labeled C90LE, but I don't believe that there were any substantial revisions, and the various versions deal primarily with variations in RAM, storage capacity (IDE DiskOnModule is the medium), and operating system. I will note that mine has 2gb RAM installed at this time (with no issues AFAICT), and that I'm using a 64gb SD card in an IDE adapter, along with a short-ish 44wire, 44pin cable (~4" long, and I'll note that there is no cable equivalent to an 80 wire 40 pin cable, for 44pin "notebook" style connections, sadly) to connect the adapter to the board, as both have male connections. To install Puppy the way I do it, which is not as advanced as it sounds -- we call it a Manual Frugal Install over in Puppy-land -- it goes like this: (1) Boot Puppy from any install. You can do this on any computer that can access the install medium. LiveCD, LiveUSB (flash or HDD), hard drive install, etc, doesn't matter. (2) Once you get to a graphical interface, mount the install-to medium and copy over Puppy's core files (vmlinuz, initrd.gz, puppy_*.sfs, and zdrv_*.sfs if it exists -- for one or two Pups out there, you'll also see an adrv_*.sfs; copying this is non-essential, but recommended; it's extra applications). (3) Run the Grub4Dos wizard. For X-Tahr and other XFCE based Pups, this is under the Control Panel option in the Menu. (In particular, X-Tahr uses the XFCE Whisker Menu, and it's the little icon immediately to the right of the search box, that you're looking for.) For JWM based Pups, it's somewhere in the schmoo of the Setup section of the Menu. Usually. Might be System on some Pups, and some have it in BOTH places. Puppy is kind of a mess at times! (4) Edit the Grub4Dos-produced menu.lst (that would be "menu dot list", mind you!) -- you will, at least, need to find a line specifying "pfix=ram" and edit that part of that line to read "pmedia=ataflash pfix=ram" for IDE/SATA flash disks (such as SSDs or a CompactFlash or SD card in an adapter), or "pmedia=atahd pfix=ram" for platter drive based systems. You also want the line in the menu entry above that to have a matching "pmedia=" statement just before "pfix=fsck" -- which you definitely want to keep. I tend to eliminate everything other than the header at the top, the main entry and the "RAM Mode" entry, and the "additionals" section's reboot and halt entries. As far as I'm concerned, the rest is cruft. (I can upload a sample menu.lst if you're confused.) (5) Unmount the install-to medium, stick it in the target system, and fire 'er up. You may be able to do this in other Linuces (that would be the proper Latin cognate of that word :P ), or even in Windows, by mounting the ISO manually and copying from there. I will note that Windows is well known amongst Puppians to have capitalization issues. ALL SFS FILES MUST BE NAMED COMPLETELY IN LOWERCASE LETTERS OR PUPPY WON'T BOOT. Also -- use a savefolder, when prompted. Savefiles corrupt over time (spontaneously!) and the Puppy community as a whole does not know exactly why. Keeping that "pfix=fsck" remark in the menu.lst file helps a lot as well, but it doesn't eliminate savefile corruption -- using it with a savefolder, though, does. I should also note that I *NEVER* expected you to work on this thing every single day -- that in my mind would make for a lot of very boring and tedious days! Take your time, man, you're not holding me up. No, seriously. I know you've got a life. Live it. Don't worry too much about me! SERIOUSLY. Oh, and I'll get you those logs probably tomorrow morning (it's 11:30ish here still, as I type this) and I'll put the patches in and report back ASAP. I've a friend of a friend who's having a 50th birthday party late tomorrow afternoon, so I won't be able to do all that much necessarily... but I'll do what I can and the rest will wait till Sunday. I'll keep you posted :) Well, that's interesting... I'm no longer getting a /var/log/Xorg.0.log. It's refusing to exist! Ain't that a stinker. Well, that ain't good. I've confirmed that it's not saving the X logs. Which means that, each time I test I have to redo the install. That's not good, because that means that, for each and every log, I have to install the SD card and adapter in a different computer, boot it, install, transfer the card+adapter back to the WYSE, boot it, recompile openchrome, let it fail to bring up a screen, cut it off, pull *just* the card, and copy over the log -- and then repeat the process from start all over again for the next log. Ugh. I'm not sure I signed up for that much work. Not to mention that the computer I have to use, my only other good thin client with IDE, is that HP -- and I want to sell it, make a little money for myself. I have to admit that right now I'm trying to hold back a portion of my vocabulary that can't be used in front of a TV camera ;) (In reply to Christopher from comment #173) > I have to admit that right now I'm trying to hold back a portion of my > vocabulary that can't be used in front of a TV camera ;) I admire your choice of words. :) Last update for a bit, unless something different happens -- I don't want to spam ya! I've asked a dude on the Puppy forum to whip me up a script that does a "full" install of Puppy to USB (which the standard installer won't do) so that I can do this fairly easily. I'll let you know how that goes. My friend (one of the devs, actually, 01micko is what he goes by) provided me with the script but I've yet to have it run through entirely. Not his fault, he's sharp. Should be up and running again in the next couple of days tho. Gave up waiting for 01micko to get back to me, did a full install. About to attach the Xorg.0.log from the patched driver over VGA. I'll test DVI after dinner. Created attachment 121544 [details]
Xorg.0.log from crashing patched driver, "full" install -- does not include 2 most recent patches
Here's the log, FINALLY. Note that this doesn't include the two most recent patches you've posted.
Something's going on here. What I'm doing is, booting Puppy till it dies, then putting the SD Card I'm using into my laptop, after removing it from the IDE adapter. The next time I boot, I get a bunch of "no space left on device" messages and a kernel panic, and after that it doesn't seem to want to write to the card any more. WTF...? Might ask my local guru dude about this as well. (In reply to Christopher from comment #179) Hi Christopher, > Something's going on here. > > What I'm doing is, booting Puppy till it dies, then putting the SD Card I'm > using into my laptop, after removing it from the IDE adapter. > > The next time I boot, I get a bunch of "no space left on device" messages > and a kernel panic, and after that it doesn't seem to want to write to the > card any more. > > WTF...? > > Might ask my local guru dude about this as well. I am still around. After you figure out what is going on, let me take a look at the Xorg.0.log. The Xorg.0.log you attached very recently did not look good. It was crashing prior to loading OpenChrome. Regards, Kevin Brace (In reply to Kevin Brace from comment #180) > > I am still around. > After you figure out what is going on, let me take a look at the Xorg.0.log. > The Xorg.0.log you attached very recently did not look good. > It was crashing prior to loading OpenChrome. > > Regards, > > Kevin Brace Actually, I need to correct myself. It was crashing when it calls another device driver. OpenChrome is being called, but the crash does not appear to be related to OpenChrome. It was complaining that mouse and keyboard were not found. Regards, Kevin Brace So... wait, what? Is it trying to pull in a driver that isn't openchrome, instead of openchrome? eg modesetting, vesa. Or is there another driver that's *supposed* to be there but isn't doing its thing? or what? I'm totally confused. (In reply to Christopher from comment #182) Hi Christopher, > So... wait, what? Is it trying to pull in a driver that isn't openchrome, > instead of openchrome? eg modesetting, vesa. Or is there another driver > that's *supposed* to be there but isn't doing its thing? or what? > > I'm totally confused. I think xorg server that is calling another device driver. You may want to go back to your original configuration when you were able to run the compiled OpenChrome. Regards, Kevin Brace That was with a different version of Puppy, though, that's even MORE outdated... we're talking late 2012 for last known good config here. (In reply to Christopher from comment #184) Hi Christopher, > That was with a different version of Puppy, though, that's even MORE > outdated... we're talking late 2012 for last known good config here. In my personal case, I am use Lubuntu 12.04 i386 as my standard development platform. I will say that it will be safer if you stick to the PuppyLinux based on Ubuntu 12.04 for now. It is just my personal recommendation until the situation stabilizes. Regards, Kevin Brace The WYSE Cx0 system I have is right now only being used for bugfixing here. I have another project that may involve it once openchrome works on it -- but I won't know till then if it's a suitable platform for my project. If it's not, I have alternatives... I'm like that, I have a bunch of 'tinkering' machines ;) I do hope you're not giving up, though... (In reply to Christopher from comment #186) > The WYSE Cx0 system I have is right now only being used for bugfixing here. > I have another project that may involve it once openchrome works on it -- > but I won't know till then if it's a suitable platform for my project. If > it's not, I have alternatives... > > I'm like that, I have a bunch of 'tinkering' machines ;) > > I do hope you're not giving up, though... Hi Christopher, The good news. I was just able to push a patch into the OpenChrome repository. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=35c6f0c1410247c4eba5fbc2e017561778c3c90d I took a lot of figuring out to get to the first patch I was able to push into the repository (I have never done open source software development. I am an unemployed Silicon Valley digital hardware design engineer, so I do not specialize in Linux graphics device driver development.). I am now in the driver's seat (no pun intended), and finally, it is nice to be in the driver's seat for the first time (again, no pun intended). I will personally celebrate today (a big deal for me) on my own. What this means is that, in the future, you will be able to obtain updated source code quickly without having to apply so many patches like where you are today. While I will not be able to promise that the future OpenChrome Version 0.3.4 will fix your bug, at some point, newer version of PuppyLinux should have the newer OpenChrome code. I am hoping that future OpenChrome Version 0.3.5 will fix your bug, and hopefully PuppyLinux developers will take the updated code. Regards, Kevin Brace Woohoo! Congrats, sir. If I may, without being too weird -- however you celebrate, have a second one for me ;) (Sorry, if that IS too weird. I have Asperger's, and I'm particularly sleepy as it's half past midnight over here, so I'm even more prone to it at the moment than usual...) (In reply to Christopher from comment #188) > Woohoo! Congrats, sir. > > If I may, without being too weird -- however you celebrate, have a second > one for me ;) > > (Sorry, if that IS too weird. I have Asperger's, and I'm particularly sleepy > as it's half past midnight over here, so I'm even more prone to it at the > moment than usual...) Hi Christopher, Thank you for celebrating the first commit I was able to perform with me. (^_^) I just did a commit partially related to your bug (Fixing DVI detection code crash, Commit 6964b889d77422ed16972b0ba849d9d5c6574daa). There will be two more commits related to DVI coming up in the next few days. You may want to rebuild the image of PuppyLinux for SD card after those two commits are in. Sounds like a plan. As for my end of things, we may have an explanation for what is going on with the SD card. Card is SDXC, basically by necessity. Laptop is a 2010 Dell e4310, which has either a Ricoh R5U241 or a Ricoh R5U242A chip running the SD slot. I suspect the '241 is the chip in my laptop but actual confirmation -- which, sadly, must be done by eyeball -- will have to wait until I am inclined next to operate on the system ;) Nevertheless, as chips supporting SDXC only came out in early 2010 (per Wikipedia) -- it is likely my laptop sees the card as an SDHC card, not an SDXC card, and gets a little confused -- causing major problems. I'm working on getting a card reader -- but, unfortunately, it's going to be a challenge with my kind of cashflow to have it happen before next month. I literally don't even have a dollar right now. I'll keep you posted. Hey, maybe I'll find something under the couch cushions tomorrow :P Hi Christopher, I have done a few more relatively unimportant commits. That being said, if you were to do any testing, you should use DVI for now. I will eventually merge the patches I asked you to test into the master branch (i.e., main development branch), but since they are still unproven, I am reluctant to commit them at this point. That being said, please do not use any of the patches that were uploaded for specifically dealing with this bug. They are obsolete, and use of them will only cause problems for you. In order to update your local git repository, please run the following commands from the terminal when you are in your xf86-video-openchrome directory (folder). git reset --hard 47060a3d770b90ed96924b4260dce38bdafedfde git pull These 2 commands will update your local Git repository. Just for your reference, commit 47060a3d770b90ed96924b4260dce38bdafedfde was the last commit before I did my first commit. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=47060a3d770b90ed96924b4260dce38bdafedfde After you update your local Git repository, I will create several patches you can try. These patches should enable the use of VGA via DVI to VGA dongle (The functionality of these patches is similar to some of the patches you have already tried, though.). Probably best to hold off until I get a proper SDXC card reader here. I hope I can get the money for that this weekend... have to beg a friend but it's only $3 for one on eBay, if I order from within the US. I'll likely do that if I can get the dough from him... shorter wait that way than from HK, especially since the HK $1 ones don't come with trackable shipping so it can take MONTHS. (In reply to Christopher from comment #192) When you are ready, I will upload two patches that will want you to test. Again, it is similar to some of the previous patches, but you will have to use new patches since I just updated the code in the repository. Off topic, but the latest commit make OpenChrome to compile with xorg 1.7 (i.e., Ubuntu 10.04 LTS, Lubuntu 10.04, etc.) without errors or warnings. I do not plan to make commits for the next few days due to my schedule. > Probably best to hold off until I get a proper SDXC card reader here. I hope > I can get the money for that this weekend... have to beg a friend but it's > only $3 for one on eBay, if I order from within the US. I'll likely do that > if I can get the dough from him... shorter wait that way than from HK, > especially since the HK $1 ones don't come with trackable shipping so it can > take MONTHS. Got the card reader this morning -- tested, working, at least initially. Time will tell the rest ;) Go ahead and upload the patches when you get the chance, I'll test tomorrow (Sunday) if I can. (In reply to Christopher from comment #194) Hi Christopher, > Got the card reader this morning -- tested, working, at least initially. > Time will tell the rest ;) > > Go ahead and upload the patches when you get the chance, I'll test tomorrow > (Sunday) if I can. Okay, I will get the patch ready by Monday. I want to do a few cosmetic change commits before I work a patch for you to try. Created attachment 121871 [details] [review] Using I2C bus 2 to detect a VGA monitor Previously, it was assumed that only I2C bus 1 is used to detect a VGA monitor. I2C bus 2 is typically used to detect a DVI monitor via a DVI connector. However, for devices with a DVI-I connector, VGA signals come out of the connector as well. What this means is that I2C bus 2 also has to be used to detect a VGA monitor, in addition to I2C bus 1. Furthermore, EDID obtained from the monitor via I2C bus will be used to determine whether or not it is an analog type (i.e., VGA monitor). Signed-off-by: Kevin Brace <kevinbrace@gmx.com> Hi Christopher,
I uploaded the patch for you to try.
I developed with OpenChrome Git repository commit in mind.
If the patch works out for you, it will likely get committed into the repository.
I am very close to OpenChrome Version 0.3.4 release (Most changes I wanted to put into the code before Version 0.3.4 release have been committed.), and whether or not the fix I came up here as a patch will go into Version 0.3.4 depends on how the modified code performs.
This is what I want to you to test.
- DVI to VGA adapter configuration
- DVI configuration (use DVI cable)
Here is the detailed instructions on how to compile and install OpenChrome.
https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001753.html
If possible, you may want to try Ubuntu 12.04 based Puppy Linux rather than Ubuntu 14.04 based Puppy Linux since I use Lubuntu 12.04 for development and initial testing, at least for now.
I do check the code with Ubuntu 10.04 LTS and Lubuntu 10.04 as well to make sure it doesn't break anything, but I do not really test it against Ubuntu 14.04 based OSes at this point.
You can try Ubuntu 14.04 based OSes later.
For patch application, put the patch inside xf86-video-openchrome and run this command.
$ patch -p1 < ("Name of the patch")
Created attachment 121872 [details] [review] Using I2C bus 2 to detect a VGA monitor Previously, it was assumed that only I2C bus 1 is used to detect a VGA monitor. I2C bus 2 is typically used to detect a DVI monitor via a DVI connector. However, for devices with a DVI-I connector, VGA signals come out of the connector as well. What this means is that I2C bus 2 also has to be used to detect a VGA monitor, in addition to I2C bus 1. Furthermore, EDID obtained from the monitor via I2C bus will be used to determine whether or not it is an analog type (i.e., VGA monitor). Reported-by: Christopher <laserhawk64@gmail.com> Signed-off-by: Kevin Brace <kevinbrace@gmx.com> I just made a change to the description section. You should get credit for all the time and hard work you put into the testing process. Other than that, there is no change in the functionality of the patch. I hope the patch works. Please make sure you get the latest code from the OpenChrome Git repository since I did a few insignificant commits today. The detailed instructions link I shared in the previous post explains how to do it (i.e., git reset --hard . . . followed by git pull). Sonovabatchfile ;) The system I was using to full-install Puppy decided that it didn't need a working IDE controller any more. I thought that I could 'fool' Puppy's installer -- but of course there's a 'sanity check' that prevents Puppy from installing the 'wrong' version -- a necessary procedure here for obvious reasons. ...and the installer doesn't run in text mode... ...and I don't have another system I can use to install, as I don't have any other IDE based systems that I can attach a cable to, and I lack an IDE<->SATA adapter. I don't DARE do what I did for the card reader --borrow from a friend-- as I only have one friend I can borrow from and I've been leaning on him too heavily lately as it is. ARGH! "You know, Roseanne Roseannadanna -- it's always somethin'!" ;) I'll be back when I get this sorted. Hi Guys, Returning from my holiday and looking at this thread from the start to the end takes me several hours to do so although I have to skip some content for your chat becuase it is so long. As I replied the mail to Kevin, I prefer to put my more time on OpenChrome and has several guys invovled on this project. So I hope I can provide some useful informaiton on this bug too. So is this bug fixed or not? Does I2C 2 probe EDID information from DVI interface? Thanks, Frank (In reply to HuangRan from comment #201) Hi Frank, > Hi Guys, > > Returning from my holiday and looking at this thread from the start to > the end takes me several hours to do so although I have to skip some content > for your chat becuase it is so long. > As I replied the mail to Kevin, I prefer to put my more time on > OpenChrome and has several guys invovled on this project. So I hope I can > provide some useful informaiton on this bug too. > So is this bug fixed or not? Does I2C 2 probe EDID information from DVI > interface? > > Thanks, > Frank The way the code works right now with the patch is that I2C bus 1 and 2 are used for VGA related monitor detection. xserver's API returns a structure that tells the caller if the monitor type is analog or digital. I use this information to see if I2C bus 1 or 2 is connected to an analog monitor (i.e., VGA monitor). I read the Intel DDX UMS code, and they apparently do this. As for DVI, I2C bus 2 or 3 are used for communicating with the monitor and an external TMDS transmitter chip. In other words, I2C bus 2 can be used for VGA, DVI, or even a TV encoder chip. The code that handles an external TMDS transmitter for DVI (i.e., VT1632A chip) is still relatively unproven. It was donated in early 2015, but there was a bug in it, and I help fix it with the person who reported it (Bug 93675). I do own about 10 or so VIA Technologies IGP based mainboards / computers at my place, but I do not really have a functional mainboard / computer with DVI coming out of it at this point that is not a thin client. Created attachment 121881 [details] attachment-11453-0.html Hi Kevin, Glad to receive your response so quickly. For I2C probe EDID information, generally there are several the I2C HW pair lines as you said. And they can be routed to VGA connector/DVI connector, even for HDMI connector. It depends on HW schematic. So for this Wyse C90LE case, do we know which I2C HW pair lines are used for chipset? If there is no EDID information probed out, we can try a fixed mode to see if that is the reason for this issue. I know how to do it in DRM instead of UMS driver. And I think there is a way to try a fixed mode in UMS driver too. Thanks, Frank 发件人: Openchrome-devel [mailto:openchrome-devel-bounces@lists.freedesktop.org] 代表 bugzilla-daemon@freedesktop.org 发送时间: 2016年2月22日 17:36 收件人: openchrome-devel@lists.freedesktop.org 主题: [Openchrome-devel] [Bug 91966] No signal to monitor with X and openchrome using VX855 chipset graphics Comment # 202 <https://bugs.freedesktop.org/show_bug.cgi?id=91966#c202> on bug 91966 <https://bugs.freedesktop.org/show_bug.cgi?id=91966> from <mailto:kevinbrace@gmx.com> Kevin Brace (In reply to HuangRan from comment #201 <https://bugs.freedesktop.org/show_bug.cgi?id=91966#c201> ) Hi Frank, > Hi Guys, > > Returning from my holiday and looking at this thread from the start to > the end takes me several hours to do so although I have to skip some content > for your chat becuase it is so long. > As I replied the mail to Kevin, I prefer to put my more time on > OpenChrome and has several guys invovled on this project. So I hope I can > provide some useful informaiton on this bug too. > So is this bug fixed or not? Does I2C 2 probe EDID information from DVI > interface? > > Thanks, > Frank The way the code works right now with the patch is that I2C bus 1 and 2 are used for VGA related monitor detection. xserver's API returns a structure that tells the caller if the monitor type is analog or digital. I use this information to see if I2C bus 1 or 2 is connected to an analog monitor (i.e., VGA monitor). I read the Intel DDX UMS code, and they apparently do this. As for DVI, I2C bus 2 or 3 are used for communicating with the monitor and an external TMDS transmitter chip. In other words, I2C bus 2 can be used for VGA, DVI, or even a TV encoder chip. The code that handles an external TMDS transmitter for DVI (i.e., VT1632A chip) is still relatively unproven. It was donated in early 2015, but there was a bug in it, and I help fix it with the person who reported it (Bug 93675 <https://bugs.freedesktop.org/show_bug.cgi?id=93675> ). I do own about 10 or so VIA Technologies IGP based mainboards / computers at my place, but I do not really have a functional mainboard / computer with DVI coming out of it at this point that is not a thin client. _____ You are receiving this mail because: * You are the assignee for the bug. I have some HP T5550 (VX900) thin clients that used to previously work under the 0.2.x branch, but stopped working under 0.3.x with the same issue described in this bug (no displays are detected). This thin client has 2 DVI ports, a DVI-I and a DVI-D. Up to this point no monitors are detected using either DVI port with DVI cable or with a DVI-I to VGA adapter and connected via VGA cable. The distribution I'm using for testing is Thinstation (5.3). I have pulled the latest code from GIT and have applied the latest VGA detection patch ( attachment 121872 [details] [review] ) on top. I'm happy to report that with the latest GIT pull and VGA patch applied the monitor is detected and functional via VGA, but unfortunately not on either DVI port (the same monitor is used in all tests). The driver has been built with debugging and via_regs_dump enabled. I am attaching 3 logs. DVI on the DVI-D port DVI on the DVI-I port VGA on the DVI-I port with VGA adapter Keep me posted if I can assist further! Created attachment 121897 [details]
DVI on the DVI-D port on HP T5550
Created attachment 121898 [details]
DVI on the DVI-I port on HP T5550
Created attachment 121899 [details]
VGA on the DVI-I port with VGA adapter HP T5550
(In reply to Justin Chevrier from comment #204) Hi Justin, > I have some HP T5550 (VX900) thin clients that used to previously work under > the 0.2.x branch, but stopped working under 0.3.x with the same issue > described in this bug (no displays are detected). This thin client has 2 DVI > ports, a DVI-I and a DVI-D. Up to this point no monitors are detected using > either DVI port with DVI cable or with a DVI-I to VGA adapter and connected > via VGA cable. The distribution I'm using for testing is Thinstation (5.3). > > I have pulled the latest code from GIT and have applied the latest VGA > detection patch ( attachment 121872 [details] [review] [review] ) on top. I'm happy > to report that with the latest GIT pull and VGA patch applied the monitor is > detected and functional via VGA, but unfortunately not on either DVI port > (the same monitor is used in all tests). The driver has been built with > debugging and via_regs_dump enabled. I am attaching 3 logs. > > DVI on the DVI-D port > DVI on the DVI-I port > VGA on the DVI-I port with VGA adapter > > Keep me posted if I can assist further! Thank you very much for testing the patch. You did the testing the way I would have done it myself, and posted the exact log files I wanted (i.e., DVI-D, DVI from DVI-I, and VGA from DVI-I). Interesting that I2C bus 1 is not used, and instead DVI-I is connected to I2C bus 2 in HP T5550 (Hence, the patch partially works since the code will now look for I2C bus 2 when detecting a VGA monitor.). That being said, I feel bad that DVI on I2C bus 3 is not working. That code was donated in early 2015, but I suspect that it did not really go through rigorous testing before getting incorporated into the master branch. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=a8c2f04e2ef21e64f2e91dd6f3e237f80e8c80c6 Someone else reported a bug (crash) with the donated code, so with the help of the reporter, we were able to fix the bug. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=a8c2f04e2ef21e64f2e91dd6f3e237f80e8c80c6 That being said, the original reporter of this bug, Christopher, was able to get the VT1632A detected on his thin client (He used an older version patch. The one you tried and the patch Christopher tried are essentially functionally equivalent.). https://bugs.freedesktop.org/attachment.cgi?id=121285&action=edit In his system, VT1632A is on I2C bus 2. I do not mean to make fun of Christopher, but he frequently runs into equipment trouble (^_^), so this has slowed down the debugging effort (Don't take it personally, Christopher!). I am glad that you appear to have full control of the local storage of your thin client (i.e., you are able to install some kind of Linux based OS on the SSD), so this might speed up the debugging effort. Currently, OpenChrome suffers from what I call, "weird known device table" problem, and this weird table gives hints on which display devices to detect. This is what the table looks like. _____________________________________________________________________________ /*** VX900 ***/ {"Simmtronics SIMM-PC VX900i", VIA_VX900, 0x1019, 0x3126, VIA_DEVICE_CRT}, {"ECS VX900-I", VIA_VX900, 0x1019, 0x7C8E, VIA_DEVICE_CRT}, {"Foxconn L740", VIA_VX900, 0x105B, 0x0CFD, VIA_DEVICE_LCD | VIA_DEVICE_CRT}, {"HP T5550 Thin Client", VIA_VX900, 0x1106, 0x7122, VIA_DEVICE_CRT}, {"Biostar Viotech 3200+", VIA_VX900, 0x1565, 0x120A, VIA_DEVICE_CRT}, {"ASRock PV530", VIA_VX900, 0x1849, 0x7122, VIA_DEVICE_CRT}, {"Fujitsu Futro A300", VIA_VX900, 0xA0A0, 0x080F, VIA_DEVICE_CRT}, /* keep this */ {NULL, VIA_UNKNOWN, 0x0000, 0x0000, VIA_DEVICE_NONE} _____________________________________________________________________________ Yes, your thin client is in the table, but for some reason, the previous developers who made this table in the first place marked HP T5550 as only supporting VGA. Please note that I am not a fan of this weird table, and the use of it will be discontinued in the near future (not with the upcoming Version 0.3.4). It is not totally clear if VX900 natively supports DVI. The register bits used to handle DVI are "reserved" in VX900 (Source: VX900 Series Chrome9 HD Open Graphics Programming Manual). This is what I will do. I will commit the patch you tested to the repository since it fixes the DVI to VGA adapter bug. I finally got confirmation that the lack of the use of I2C bus 2 was the root cause of DVI to VGA adapter display bug (I suspected this since early January, but was not able to get a confirmation due to Christopher's equipment troubles.). This feature was working in OpenChrome Version 0.2.904, and OpenChrome Version 0.2.904 was used by Ubuntu 10.04 LTS and 12.04 LTS. I personally want Canonical to retire OpenChrome Version 0.2.904, and hope that the commit of this patch will do it. Regarding VX900's native support for DVI (I am assuming that VX900 chipset actually has an integrated TMDS transmitter.), I will make a patch that will temporarily activate LCD screen for HP T5550 or disable the use of this weird table for certain models with integrated TMDS transmitters like VX900 chipset. I hope this will make OpenChrome to run through the code that detects DVI using its integrated TMDS transmitter. Hi Christopher and Justin,
This is what the description portion of the commit will look like.
If you do not want your name to appear in the commit message, let me know and I will remove it before making the commit.
_________________________________________________________________________
Using I2C bus 2 to detect a VGA monitor
Previously, it was assumed that only I2C bus 1 is used to detect a VGA
monitor. I2C bus 2 is typically used to detect a DVI monitor via a DVI
connector. However, for devices with a DVI-I connector, VGA signals come
out of the connector as well. What this means is that I2C bus 2 also has
to be used to detect a VGA monitor, in addition to I2C bus 1. Furthermore,
EDID obtained from the monitor via I2C bus will be used to determine whether
or not it is an analog type (i.e., VGA monitor).
Reported-by: Christopher <laserhawk64@gmail.com>
Tested-by: Justin Chevrier <jchevrier@gmail.com>
Signed-off-by: Kevin Brace <kevinbrace@gmx.com>
_________________________________________________________________________
I will wait until both of you sign off or want to opt out.
After the commit is made, I will make a patch activating VX900 chipset's integrated transmitters.
Hi Kevin, Thank you for the in depth response and additional detail (as well as putting the effort into improving this driver!). The environment I have set up for testing makes use of PXE boot so I don't need to write anything to local storage which makes testing fairly fast and straight forward. Certainly I'm in a position to test additional patches going forward. Regarding the "Using I2C bus 2 to detect a VGA monitor" patch, no problem including my name as tested by. Just to make it formal: Tested-by: Justin Chevrier <jchevrier@gmail.com> > Regarding VX900's native support for DVI (I am assuming that VX900
> chipset actually has an integrated TMDS transmitter.), I will make a patch
> that will temporarily activate LCD screen for HP T5550 or disable the use of
> this weird table for certain models with integrated TMDS transmitters like
> VX900 chipset.
> I hope this will make OpenChrome to run through the code that detects DVI
> using its integrated TMDS transmitter.
I tweaked the T5550 entry (I've attached the patch) and as you suspected enabling the LCD device allowed the monitor connected via DVI to be detected and function via the DVI-I port (log attached). The DVI-D connector remained non-functional. The monitor connected with a VGA cable via the DVI to VGA adapter was still detected, but no longer displayed anything (log attached).
Created attachment 121922 [details] [review] Modified T5550 Entry Created attachment 121923 [details]
DVI on the DVI-I port on HP T5550 with modified ID
Created attachment 121924 [details]
VGA on the DVI-I port with VGA adapter HP T5550 with modified ID
Hi Christopher, Is it okay if I include your name and e-mail address in the commit message? ____________________________________________________________ . . . Reported-by: Christopher <laserhawk64@gmail.com> . . . ____________________________________________________________ Also, see Comment 209 for the full commit message. If you do not want your name and e-mail address included, I will do a commit without your information. (In reply to Justin Chevrier from comment #211) Hi Justin, > > Regarding VX900's native support for DVI (I am assuming that VX900 > > chipset actually has an integrated TMDS transmitter.), I will make a patch > > that will temporarily activate LCD screen for HP T5550 or disable the use of > > this weird table for certain models with integrated TMDS transmitters like > > VX900 chipset. > > I hope this will make OpenChrome to run through the code that detects DVI > > using its integrated TMDS transmitter. > > I tweaked the T5550 entry (I've attached the patch) and as you suspected > enabling the LCD device allowed the monitor connected via DVI to be detected > and function via the DVI-I port (log attached). The DVI-D connector remained > non-functional. The monitor connected with a VGA cable via the DVI to VGA > adapter was still detected, but no longer displayed anything (log attached). Well, at least there is some good news that the weird known device table was the culprit as I have guessed. It now appears that DVI-I's DVI portion comes from VX900's integrated TMDS transmitter, and VT1632A TMDS transmitter chip is connected to I2C bus 3. When the code to support VT1632A was donated, it had a strange assumption that VT1632A detection was done only when P4M800 Pro, VN800, or CN700 chipset is present. I took out this assumption, but to complicate the situation, I2C bus 3 is not a hardware based I2C implementation like I2C bus 1 and 2. I do not know how proven the I2C bus 3 controlling code really is. If your thin client's VT1632A was connected to I2C bus 2, it would have been a different story, as I have seen 2 different people able to get OpenChrome to recognize VT1632A on I2C bus 2 (i.e., OpenChrome is able to get vendor ID match on I2C bus 2) recently. I will likely develop a patch that will use look into what is being sent over I2C bus 3 since OpenChrome is not getting vendor ID match over I2C bus 3 in your situation. Without vendor ID match, OpenChrome will assume that VT1632A is not connected. As for the DVI to VGA adapter not working well, again, that is bad. I will try to think of a something for you to try in the next few days. Created attachment 121940 [details] [review] Added debug messages to via_vt1632_probe Added debug messages to via_vt1632_probe function inside via_vt1632.c. Signed-off-by: Kevin Brace <kevinbrace@gmx.com> Created attachment 121941 [details] [review] Using I2C bus 3 functions that are likely work The code to detect VT1632A DVI transmitter supports detection on I2C bus 2 and 3. The code to detect VT1632A on I2C bus 3 ran through a certain code path, but this was previous used only when P4M800 Pro, VN800, or CN700 chipset was present. Now all devices will go through this code path when dealing with I2C bus 3. Signed-off-by: Kevin Brace <kevinbrace@gmx.com> Hi Justin, I added 2 patches for you to try. These patches are primarily for DVI-D port that is connected to VT1632A in your HP T5550. I am trying to see if the code that detects VT1632A can even see it on I2C bus 3. VT1632A does have vendor and device ID inside the device, and the detection code looks for these IDs. It might take some time to come up something for you to try regarding the VGA coming out of DVI to VGA adapter not working. Let me know what happens. Created attachment 121951 [details]
DVI on the DVI-D port on HP T5550 with ID, 121940, 121941
Comment on attachment 121951 [details]
DVI on the DVI-D port on HP T5550 with ID, 121940, 121941
Applying the 2 patches on top of the ID patch I posted allowed the DVI-D port to output video, although the logs show nothing regarding EDID data from the monitor (log attached).
Created attachment 121952 [details]
DVI on the DVI-D port on HP T5550 with ID, 121940, 121941
Let's try this again. Applying the 2 patches on top of the ID patch I posted allowed the DVI-D port to output video, although the logs show nothing regarding EDID data from the monitor (log attached).
Hi Justin, Very early this morning (I live in PST zone), I noticed that the code that handles obtaining EDID information from the monitor for VT1632A does not support I2C bus 3 (It only can support I2C bus 2 for now.). I will get a patch that will correct this, and it should be available in about 6 to 7 hours from now. That being said, I2C bus 3 does not appear to be working correctly since it does not see VT1632A on I2C bus according to the log. ____________________________________________________________ . . . (II) CHROME(0): Entered via_dvi_init. (--) CHROME(0): VT1632A not found on I2C Bus 2 or I2C Bus 3. (II) CHROME(0): Exiting via_dvi_init. . . . ____________________________________________________________ We will likely not want to use attachment 121941 [details] [review] for now (only use attachment 121940 [details] [review] for now). Created attachment 121957 [details] [review] Altering external DVI transmitter (VT1632A) monitor detection method Changed the way DVI monitor is detected if it is connected to VT1632A DVI trasmitter. Now I2C bus 3 can be used with VT1632A. The detection algorithm is still far from perfect, but hopefully good enough for now that it can coexist with an integrated DVI (TMDS) transmitter present in CX and VX series chipsets (i.e., CX700 and VX900 chipsets). Signed-off-by: Kevin Brace <kevinbrace@gmx.com> Hi Justin, I altered the external DVI (TMDS) transmitter detection monitor detection method that hopefully works with I2C bus 3. I know the I2C bus 3 appears still broken, and you obviously should not be using attachment 121941 [details] [review] (attachment 121940 [details] [review] is okay), but assuming that you can get I2C bus 3 to detect VT1632A, attachment 121957 [details] [review] should allow it to be registered as a monitor with xorg xserver. If I2C bus 3 is not working, then I can also come up with a way to adjust its timing parameters. Hi Justin, Reading through the log file you titled, "VGA on the DVI-I port with VGA adapter HP T5550 with modified ID," it appears that the OS is recognizing the monitor (EDID is being returned correctly) and the monitor is identifying the interface as an analog type (i.e., VGA). I know you reported to me that VGA coming out of DVI to VGA adapter was not working, but can it be a situation where you have to manually switch to the other signal source? A typical monitor with 2 or more monitor interfaces typically have a button that allows you to switch this. Some models switch signal source automatically, but others don't. As for the log file you titled, "DVI on the DVI-I port on HP T5550 with modified ID," the monitor is identifying the interface as a digital type (i.e., DVI). Let me know how you think. (In reply to Kevin Brace from comment #226) > I know you reported to me that VGA coming out of DVI to VGA adapter was not > working, but can it be a situation where you have to manually switch to the > other signal source? > A typical monitor with 2 or more monitor interfaces typically have a button > that allows you to switch this. That is a fair question, but I can confirm that the monitor was set to the right input type (VGA). The reason I'm 100% confident is that when transferring the Xorg.0.log file from the thin client to my workstation I switch to another VT on the thin client (the VGA port comes back when switching to another VT) and I transfer from the thin client. I do this each time I get a log. In addition, when testing each patch I ensure only one cable (DVI or VGA) is connected to the thin client at a time. An additional point that may be relevant is that when in this state (EDID is detected but nothing is displayed on the VGA port) the monitor detects an input signal (aka it doesn't go into power saving), but it's just a blank screen. (In reply to Justin Chevrier from comment #227) Hi Justin, > That is a fair question, but I can confirm that the monitor was set to the > right input type (VGA). The reason I'm 100% confident is that when > transferring the Xorg.0.log file from the thin client to my workstation I > switch to another VT on the thin client (the VGA port comes back when > switching to another VT) and I transfer from the thin client. I do this each > time I get a log. In addition, when testing each patch I ensure only one > cable (DVI or VGA) is connected to the thin client at a time. > > An additional point that may be relevant is that when in this state (EDID is > detected but nothing is displayed on the VGA port) the monitor detects an > input signal (aka it doesn't go into power saving), but it's just a blank > screen. Thank you for answering that question. I just wanted to confirm the problem exactly. I have been working on the DVI related bugs of OpenChrome and preparation for Version 0.3.4 for about 2 weeks straight. I will like to take a few days break on this issue, and work on investigating other bugs for the next few days. I will still monitor the messages posted here everyday. Created attachment 121990 [details]
DVI on the DVI-D port on HP T5550 with ID, 121940, 121957
Here is the log for the DVI-D connector with 121957 applied (and without 121940).
Thanks again.
Sorry, without 121941 (121940 as still applied). Boy, I get all the fun stuff. (Ugh.) The viafb driver is broken on my Neoware CA19, at least as implemented in TahrPup. Within one second of being invoked, the system hangs, frozen solid. Not following up on that... but that means that until I can get 01micko's previously mentioned full-install-to-USB bash script up and running, I'm dead in the water... and he's completely awol right now, has been for a couple weeks now I think. I've emailed my local Linux guru friend but I'm not optimistic. I *do* have one other system, but it's not at all useful -- it's a different WYSE (an Sx0-series) with a 366MHz Geode (!) inside, and it turns off the IDE as soon as the kernel fires up, unless said kernel has had some adjustments made to it... and recompiling kernels is waaaaaaaaaay over my little head! > I *do* have one other system, but it's not at all useful -- it's a different > WYSE (an Sx0-series) with a 366MHz Geode (!) inside, and it turns off the > IDE as soon as the kernel fires up, unless said kernel has had some > adjustments made to it... and recompiling kernels is waaaaaaaaaay over my > little head! It is a AMD Geode LX/GX platform, you need use https://cgit.freedesktop.org/xorg/driver/xf86-video-geode/ latest driver to try. Thanks, Frank That's not the problem. The problem is that there is a kernel module (correction, not the kernel itself, but rather the driver for the CS5536 "companion chip"*) that needs modifications compiled into it in order to (re)activate the IDE header after the BIOS cuts it off. The necessary alterations are on this page, in the last section at the very bottom -- http://www.parkytowers.me.uk/thin/wyse/s10/Linux.shtml -- however, manual patching is still, quite honestly, well beyond my abilities. I don't code ;) On top of that, I'm not 100% sure where in Puppy I would put the patched driver. I would assume that I'd have to modify initrd.gz which would be kind of a pain, as it's actually a CPIO archive, rather than the GZIP archive it claims to be by way of extension. (It might actually be both, a CPIO nested inside of a GZIP. I'm not actually sure.) Even then, there's a pretty sizable chance that I won't be able to do what I need to do... I seem to recall having some significant issues getting that particular system to boot in the first place. Hi Justin, Thank you very much for trying out the patch. It appears that I2C bus 3 is not showing anything. _____________________________________________________________________ . . . (II) CHROME(0): Entered via_dvi_init. (--) CHROME(0): VT1632A found on I2C Bus 3. (II) CHROME(0): I2C device "I2C Bus 3:VT1632A" registered at address 0x10. (II) CHROME(0): Entered via_vt1632_probe. (II) CHROME(0): Vendor ID: 0x0000 (II) CHROME(0): Device ID: 0x0000 (--) CHROME(0): VT1632A DVI transmitter not detected. (II) CHROME(0): Exiting via_vt1632_probe. (II) CHROME(0): I2C device "I2C Bus 3:VT1632A" removed. (II) CHROME(0): Exiting via_dvi_init. . . . _____________________________________________________________________ If VT1632A were found, it will display Vendor ID of 0x1106 and Device ID of 0x3192. Instead, you got 0x0000 back for both. If I were to speculate, what this can mean is that I2C bus 3 is not functioning in HP T5550, or is not present. It appears that something is connected to I2C bus 1, so maybe if I2C bus 1 is used for dealing with VT1632A and DVI-D. I will try to get a patch in the next few days that will utilize I2C bus 1 for VT1632A detection. (In reply to Christopher from comment #231) Hi Christopher, > Boy, I get all the fun stuff. (Ugh.) > > The viafb driver is broken on my Neoware CA19, at least as implemented in > TahrPup. Within one second of being invoked, the system hangs, frozen solid. > > Not following up on that... but that means that until I can get 01micko's > previously mentioned full-install-to-USB bash script up and running, I'm > dead in the water... and he's completely awol right now, has been for a > couple weeks now I think. > > I've emailed my local Linux guru friend but I'm not optimistic. > > I *do* have one other system, but it's not at all useful -- it's a different > WYSE (an Sx0-series) with a 366MHz Geode (!) inside, and it turns off the > IDE as soon as the kernel fires up, unless said kernel has had some > adjustments made to it... and recompiling kernels is waaaaaaaaaay over my > little head! I was able install Puppy Linux on a USB flash memory stick yesterday. For the sake of staying with a comparable environment, I choose Precise Puppy 5.7.1 retro. I still have not figured out how Git can be installed since Puppy Precise does not appear to use APT as its package manager. Anyway, I can test the patch to see if VGA out of DVI to VGA adapter (I still like calling it "dongle.") as soon as Git is installed, and OpenChrome package dependencies are resolved. If you know how to solve these 2 issues, let me know since that will save a lot of time. Hi Christopher, Oh, I forgot. The box I am using is Wyse Cx0. Specifically, C00X 128F/512R model. Yes, indeed the VGA out of DVI to VGA adapter works with OpenChrome Version 0.2.904. My test environment is X-Tahr 1b3, based on TahrPup 6.0.2 (X-Tahr is here --> http://www.murga-linux.com/puppy/viewtopic.php?t=99849 ). You will need to boot Puppy in another computer and install the OS to an internal drive (so that you get the option of a full install, which you only get when Puppy thinks you're using an internal platter drive), then transfer that drive to the WYSE Cx0 you have. The Cx0 series clients cannot power a platter drive, but if you lie to the Puppy Universal Installer (telling it your SSD is a platter drive) it will be none the wiser. When you put down the bootloader, if you use grub4dos make sure to edit menu.lst so that both the line with "pfix=fsck" and the line with "pfix=ram" have those statements immediately preceded by "pmedia=usbhd" (if using USB) or "pmedia=atahd" (if plugging into the Cx0's internal 44pin IDE header). Alternately, I can post the bash script that 01micko has been working on for me -- he popped up two days ago to say he was back and would look, but I haven't heard a peep since. If that script can be made to work, we will have a workable way to do a full install to USB, which right now the Puppy Universal Installer will absolutely not ever ever do. ---------- Puppy indeed does not have aptitude -- we have 'petget' instead. PET packages are our preferred format; PET stands for "Puppy's Extra Treats" (rather cornier than Jiffy Pop, but not my doing). The good news is that Puppy is a derivative distro -- if you type (sans quotes) "petget /root/git.deb" and then [ENTER], PetGet will install the package "git.deb" quite obligingly, even though it's not a PET. At least in TahrPup, PetGet will run in text mode, although it's messy because it echoes everything to stdout... go figure. 95% or so of Ubuntu Precise Pangolin DEBs will install and run in Precise Puppy, without breaking anything, although they may occasionally require dependent libs that have been stripped out of Puppy to be (re) installed. 95% or so of Ubuntu Trusty Tahr DEBs will run in TahrPup, with the same behavior and caveat. (In reply to Christopher from comment #237) Hi Christopher, > Puppy indeed does not have aptitude -- we have 'petget' instead. PET > packages are our preferred format; PET stands for "Puppy's Extra Treats" > (rather cornier than Jiffy Pop, but not my doing). The good news is that > Puppy is a derivative distro -- if you type (sans quotes) "petget > /root/git.deb" and then [ENTER], PetGet will install the package "git.deb" > quite obligingly, even though it's not a PET. At least in TahrPup, PetGet > will run in text mode, although it's messy because it echoes everything to > stdout... go figure. > > 95% or so of Ubuntu Precise Pangolin DEBs will install and run in Precise > Puppy, without breaking anything, although they may occasionally require > dependent libs that have been stripped out of Puppy to be (re) installed. > > 95% or so of Ubuntu Trusty Tahr DEBs will run in TahrPup, with the same > behavior and caveat. I tried to install git-core via Puppy Package Manager, but even after I install it, the Console (urxvt) does not recognize Git. How did you install Git, and go through resolving dependencies for xserver-xorg-video-openchrome? I cannot test OpenChrome until those issues are resolved, and I have not found any resources online to resolve the matter. Hi Christopher, I made several DVI related improvements to the code in the past 2 days. I hate to say this, but I am skeptical that VT1632A based DVI is will work at this point. However, I am fairly optimistic that VGA coming out of a DVI to VGA adapter will work now. That being said, I still have not resolved the PuppyLinux Git installation issue, so I have not been able to tackle the VT1632A based DVI issue. At least with my newly acquired Sylvania gnet 13001 netbook (I spent $35 for this on ebay.), VGA coming out of a DVI to VGA adapter now works thanks to the improved code, and I can also do cloned screen with the flat panel and a VGA monitor. DVI also works, but I am pretty sure DVI and flat panel will not work simultaneously at this point. If you have the time, please let me know the results. Still waitin' on help with that bash script. Till I get that running I'm stuck. I don't remember how I installed Git but I'll take a look late tonight if I remember -- which I should. It'll be around 10pm Eastern US time... I'm probably not going to be on that computer until then. Glad to hear the progress, though! ...and, for me, VGA out through the adapter is perfectly fine. I don't need actual DVI... (In reply to Christopher from comment #240) Hi Christopher, > Still waitin' on help with that bash script. Till I get that running I'm > stuck. > > I don't remember how I installed Git but I'll take a look late tonight if I > remember -- which I should. It'll be around 10pm Eastern US time... I'm > probably not going to be on that computer until then. > > Glad to hear the progress, though! ...and, for me, VGA out through the > adapter is perfectly fine. I don't need actual DVI... I assume that the bash script you are talking about is being provided by another developer. The external TMDS transmitter for DVI not working is one of the major reason why OpenChrome has not been upgraded officially to Version 0.3.4. I confirmed yesterday that, at least with my equipment, DVI to VGA adapter is working. The equipment in question is a circa 2008 Sylvania netbook with a DVI-I connector. Until yesterday, DVI to VGA adapter was not working correctly, but I figured out what was going wrong (I2C bus misdetection), so now the netbook flat panel and VGA can work in a clone mode. Those fixes were committed early today. > I assume that the bash script you are talking about is being provided by
> another developer.
Yes, a Puppy developer, I've mentioned him before -- 01micko is his name. He's been mostly AWOL the past couple weeks, unfortunately, and I don't know anyone else who has both the time and the bash-script skills required to pound some functionality into the thing.
Hi Justin, I am still working on the DVI related bugs. That being said, which HP thin client are you using? According to Xorg.0.log you have uploaded, you are using HP T5550. If you can, can you open up the thin client cover, and look at the small chip near the DVI connector. If you are using HP T5550, it appears that HP decided to use a chip from Silicon Image, and OpenChrome does not currently support devices from Silicon Image. Only VT1632A by VIA Technologies is supported at this point. Hi Justin, Does the HP T5550 mainboard look like this one? http://www.parkytowers.me.uk/thin/hp/t5570/board.shtml Hi Justin, Assuming that SiI 164 is used by HP T5550 (it appears so), VT1632A is actualy a clone of SiI 164. Fortunately, VT1632A is mostly register compatible with SiI 164. That being said, the I2C bus 3 was not seeing anything, so this issue needs to be resolved first. Hi Kevin, Yes, the motherboard looks like that. The exact model I have is an HP t5565z. I have opened it up and confirmed that it is in fact a Silicon Image chip. The exact markings are: Sil164CTG64. Just as an aside, VGA now works out of the box with the latest Git. Nice! (In reply to Justin Chevrier from comment #246) Hi Justin, > Hi Kevin, > > Yes, the motherboard looks like that. The exact model I have is an HP t5565z. > > I have opened it up and confirmed that it is in fact a Silicon Image chip. > The exact markings are: Sil164CTG64. > > Just as an aside, VGA now works out of the box with the latest Git. Nice! Just for my reference, can you possibly upload the Xorg.0.log for both DVI coming out of DVI-I connector and VGA coming out of DVI to VGA adapter? I assume that DVI coming out of DVI-I is working. Regarding supporting SiI 164, VT1632A itself is mostly register compatible with SiI 164, but vendor ID and device ID differ. I will imagine that the support for SiI 164 will be attempted on one or two versions after OpenChrome Version 0.3.4. Hi Kevin First, thanks for reassuming the development of this project. I have an HP-T5550 and I wonder if VGA connected to DVI-I port of T5550 supposed to work at current master (commit b8eb2ab)? I have built current master and tested it but result is same as original openchrome 0.3.3. I am attaching the log file. I donot know if they will be helpfull, but I have enabled some register dump and I2C scanning options in xorg.conf. (Pls. see head of the log file.) My SW platfom is a custom Linux mostly based on a previous snapshot of Thinstation 5.2. I have performed tests with two different CRT monitors, two different DVI-I to VGA adaptors and with a Y-cable (DVI-I to DVI and VGA). All have same logs (except few bencmark differences). Both monitors work OK with recent via (semi ?) opensource KMS driver. You can check it at http://manu.agat.net/5.76.52.92-opensource-009-005f78-20150730.tar.gz Created attachment 122261 [details]
VGA (crt) connected to DVI-I port of T5550 via DVI-I to VGA adapter (Xorg.0.log)
I'm tired of remaining completely silent, and 01micko (Puppy dev who was helping me before disappearing) seems to be either too busy or too uninterested to help me. While I'm awaiting notification from him that I'm clear to post his nonfunctional script to the forum for others to fix, since he either won't or can't -- I've decided I'm going to, at least as a temporary measure, do a "frugal" install of the target Puppy (X-Tahr 1b3 as usual) to the test machine (WYSE Cx0, my example being an upgraded C90LE). My abilities to test and report back will be limited to "it works" or "it doesn't", until I get that script working -- to be clear, that means no logfiles -- but at least I'll know *something* and be able to provide *some* feedback. The upshot of course is that if the report back is that everything works, I'll have something to smile about, which after the past couple weeks, I kind of need. (Nothing to do with this stuff -- trust me -- just, life as of late has handed me a whole fruit orchard's worth of lemons... small lemons, mind you, but they really do all add up! Well, that, and I've gone and run myself out of sugar... ;) ) Still doesn't work, still freezes solid at a screen fulla garbage. *sigh* In the process I also discovered that my 64gb SD card and its IDE adapter have died. The adapter won't boot from a card, and the card works fine until power is removed or the system is rebooted -- at which point it goes all scrambled eggs inside. Oh well, there goes my disposable income for next month... :( ...and, since I did not perform a Full install -- since I can't -- no logs this time. Sorry... just how it goes... (In reply to Kevin Brace from comment #247) > Just for my reference, can you possibly upload the Xorg.0.log for both DVI > coming out of DVI-I connector and VGA coming out of DVI to VGA adapter? > I assume that DVI coming out of DVI-I is working. > Regarding supporting SiI 164, VT1632A itself is mostly register compatible > with SiI 164, but vendor ID and device ID differ. > I will imagine that the support for SiI 164 will be attempted on one or two > versions after OpenChrome Version 0.3.4. DVI via DVI-I only works if I apply my patch ( attachment 121922 [details] [review] ) that adds a "VIA_DEVICE_LCD" to the big table. If I apply the patch DVI on DVI-I works, but VGA does not. Created attachment 122293 [details]
Stock Git at b8eb2ab. VGA plugged into DVI-I via adapter (works)
Created attachment 122294 [details]
Stock Git at b8eb2ab. DVI plugged into DVI-I (does not work):
Created attachment 122295 [details]
Git at b8eb2ab with ID patch. VGA plugged into DVI-I via adapter (does not work):
Created attachment 122296 [details]
Git at b8eb2ab with ID patch. DVI plugged into DVI-I (works)
(In reply to Justin Chevrier from comment #252) Hi Justin, > (In reply to Kevin Brace from comment #247) > > DVI via DVI-I only works if I apply my patch ( attachment 121922 [details] [review] > [review] ) that adds a "VIA_DEVICE_LCD" to the big table. If I apply the > patch DVI on DVI-I works, but VGA does not. I will have more time to spend on Thursday and Friday on analyzing what is going on, but that being said, it appears that without "VIA_DEVICE_LCD" option specified in the known device ID table, DVI / LVDS interface does not work. Over the past few days, I was experimenting with removing the notorious device ID table completely, and obviously, I was encountering hidden problem and bug of the device driver that was overlooked by the previous developers. After analyzing the code, it is my view that this table is primarily used for remembering which known device supports DVI / LVDS interface, and other than that, it really does not have any useful purpose anymore. One of the reason I have made some progress in fixing this DVI related bug is due to myself obtaining a netbook with a DVI connector coming out of the laptop. This DVI is from the integrated TMDS inside VX700 chipset. It appears that its functionality, in terms of register mapping, is equivalent to the one that comes with VX900 chipset. For now, DVI works since the netbook laptop I used is registered with the known device table. Of course, if I remove the known device table, flat panel connected to the LVDS interface does not work. That being said, monitors connected to VGA interface (via DVI to VGA adapter) and DVI do get automatically detected, and works fine. I am trying to figure out right now how to make the DVI / LVDS interface detection code work without this table, and it might take maybe a few days to a week to figure this out. (In reply to John Friend from comment #248) Hi John, > Hi Kevin > > First, thanks for reassuming the development of this project. > > I have an HP-T5550 and I wonder if VGA connected to DVI-I port of T5550 > supposed to work at current master (commit b8eb2ab)? I have built current > master and tested it but result is same as original openchrome 0.3.3. I am > attaching the log file. I donot know if they will be helpfull, but I have > enabled some register dump and I2C scanning options in xorg.conf. (Pls. see > head of the log file.) My SW platfom is a custom Linux mostly based on a > previous snapshot of Thinstation 5.2. > > I have performed tests with two different CRT monitors, two different DVI-I > to VGA adaptors and with a Y-cable (DVI-I to DVI and VGA). All have same > logs (except few bencmark differences). > > Both monitors work OK with recent via (semi ?) opensource KMS driver. You > can check it at > http://manu.agat.net/5.76.52.92-opensource-009-005f78-20150730.tar.gz Is it possible you can upload an unmodified Xorg.0.log? For some reason, it appears that the DDX (i.e., OpenChrome) is not seeing the monitor via I2C bus. Furthermore, if you are using those DVI-Y-cable, you may want to connect only one device at a time (i.e., VGA only or DVI only) for now. Regarding HP T5550's DVI, it is coming from VX900 chipset's integrated TMDS transmitter, so Justin's modification to the code is the only way to get it working for now. I am in the process of trying to figure out how to get OpenChrome to perform automatic detection of DVI / LVDS interface, but it may take a week or so since I did encounter several problems in the past few days (I am working on the fix.). I do not want to start blaming the previous developers, but I did not write the code, so I am still in the process of figuring out what they are doing (I would not have written such code if I were doing the development.). Regarding the VIA Technologies developed 2D graphics device driver, I have not taken a look at it, so I do not have too many things to say. In general, OpenChrome developers have not relied on VIA Technologies historically, and VIA Technologies has not had a good track record of working with open source development community (This was written extensively over at Phoronix. Do a search about VIA Technologies over at Phoronix, and you can probably find several articles about what happened.). I am not personally against them, so if they wanted to reach out to OpenChrome developers (There are current 2 people working on OpenChrome and obviously I am one of them. The other person is trying to develop DRM / KMS module so that it can be incorporated in the Linux kernel sometime in the future.) I am okay with that. (In reply to Christopher from comment #251) Hi Christopher, > Still doesn't work, still freezes solid at a screen fulla garbage. > > *sigh* > > In the process I also discovered that my 64gb SD card and its IDE adapter > have died. The adapter won't boot from a card, and the card works fine until > power is removed or the system is rebooted -- at which point it goes all > scrambled eggs inside. > > Oh well, there goes my disposable income for next month... :( > > ...and, since I did not perform a Full install -- since I can't -- no logs > this time. Sorry... just how it goes... Can you try a USB flash memory stick? I was able to boot Puppy Linux 5.7.1 from an 8 GB flash memory stick. That being said, the problem with Git installation pretty much halted the progress on that front . . . I will use a different stick, and try the newer Puppy Linux soon. I /was/ using a USB stick... couldn't get the **** thing to boot from IDE. I suspect that my backup card may be damaged, in addition to the one I've been using. I'll know more when I can get a replacement card, which will be at the beginning of April. Worth noting as well -- I was using a passive DVI->VGA adapter. I was not trying straight DVI. As for Puppy -- Precise 5.7.1 is still based on Ubuntu Precise Pangolin, aka Ubuntu 12.04. It is not until TahrPup, based on Ubuntu Trusty Tahr / 14.04, that problems are encountered -- the versions of openchrome prior to 0.3.3 seem to work fine; it's that specific version which is the threshold, IIRC. Hi Kevin/All, Yesterday, I received several thin clients which I bought two weeks ago as I said. That includes Wyse V90LE(VX700), Wyse C90LE(VX855) and HP T510(VX900). Attached is the picture for your reference. For those boards, the same aspect for those boards is that they had DVI-I interface(VGA+DVI-D). Especially for HP T510 board, it has an "DVI-I + DVI-D" dual ports. I thought for this issue, Kevin have helped solve the "no output" with current UMS driver for DVI port, so can you let me know which commit id can work for current DVI-I port? I see that both of Wyse V90LE and Wyse C90LE boards have an VT1632A TMDS transmitter on it. And for HP T510 board, it does not have such an transmitter chip. So which patch is working for which chip? Thanks, Frank By the way, Kevin, how did you guys solve the "small space" issue for hard disk? I found only 2GB/4GB on board SSD hard disk is available. So right now, I am trying to buy some IDE->CF or SATA interface to hang a IDE/SATA hard disk to do the debugging work. Thanks, Frank (In reply to HuangRan from comment #262) > By the way, Kevin, how did you guys solve the "small space" issue for hard > disk? I found only 2GB/4GB on board SSD hard disk is available. So right > now, I am trying to buy some IDE->CF or SATA interface to hang a IDE/SATA > hard disk to do the debugging work. > > Thanks, > Frank And by the way, I found Ubuntu 12.04 can not be installed on those thin clients successfully. Does Lubuntu 12.04 installation work fine? Thanks, Frank Created attachment 122335 [details]
Thin client boards(Wyse C90LE, V90LE, HP T510)
Created attachment 122336 [details]
Thin client boards(Wyse C90LE, V90LE, HP T510)
Hi everyone, I made several important changes to the code, so please retest the latest code from the repository. All the patches posted here are now obsolete. In particular, I decided to remove the notorious known device table, so now everything is auto-detection based except OLPC XO-1.5. If everything works for you, DVI-I coming out of the integrated TMDS transmitter should work. I observed this with my Sylvania gnet 13001 netbook (VX700 chipset) and Lubuntu 12.04. For this particular system, VGA (from DVI to VGA adapter), DVI (from DVI-I connector), and LVDS (flat panel) all work. For this system, the only limitation is that DVI and LVDS cannot work simultaneously for now, although VGA and LVDS do work simultaneously. Making DVI and LVDS to work simultaneously will likely require extensive modifications to the code, and I am not interested in doing this for OpenChrome Version 0.3.4. I hope the latest change to the code will improve the DVI support. Let me know how it goes. (In reply to HuangRan from comment #263) Hi Frank, > > And by the way, I found Ubuntu 12.04 can not be installed on those thin > clients successfully. Does Lubuntu 12.04 installation work fine? > > Thanks, > Frank In general, Lubuntu 12.04 install demands about 4.4 GB or so empty space for installation. In practice, it occupies about 2 GB when it is first installed. I believe the Lubuntu 12.04 installer is borrowed from Ubuntu, hence, it appears to require 4.4 GB of storage capacity even though Lubuntu does not really use 4.4 GB. (In reply to HuangRan from comment #262) Hi Frank, > By the way, Kevin, how did you guys solve the "small space" issue for hard > disk? I found only 2GB/4GB on board SSD hard disk is available. So right > now, I am trying to buy some IDE->CF or SATA interface to hang a IDE/SATA > hard disk to do the debugging work. > > Thanks, > Frank I have not really solved the problem of how I will be dealing with these thin clients. So far, I got as far as trying out Puppy Linux 5.7.1 on Wyse C00X using a USB flash memory stick. However, I have not been able to use Git correctly on it, so the progress on that front has stalled . . . I really use a regular laptop (Epic 1314 laptop which is an equivalent of MSI VR321 laptop) with a large enough hard drive (40 GB) as the main development platform. (In reply to HuangRan from comment #261) Hi Frank, > Hi Kevin/All, > > Yesterday, I received several thin clients which I bought two weeks ago > as I said. That includes Wyse V90LE(VX700), Wyse C90LE(VX855) and HP > T510(VX900). Attached is the picture for your reference. > For those boards, the same aspect for those boards is that they had DVI-I > interface(VGA+DVI-D). Especially for HP T510 board, it has an "DVI-I + > DVI-D" dual ports. > I thought for this issue, Kevin have helped solve the "no output" with > current UMS driver for DVI port, so can you let me know which commit id can > work for current DVI-I port? > I see that both of Wyse V90LE and Wyse C90LE boards have an VT1632A TMDS > transmitter on it. And for HP T510 board, it does not have such an > transmitter chip. So which patch is working for which chip? > > Thanks, > Frank Wow, you now have several thin clients! Regarding DVI, you should try the latest code that I just committed for improved DVI support, but I can say that DVI coming out of VT1632A is fairly unproven at this point. This is due to the fact that the code to support it was donated in January 2015, and I do not think it was tested adequately before it was committed. That being said, I will be very interested in seeing if it will work with the current code. Regarding HP T510, it is VX900 chipset based, so the DVI-I "should" work. Actually, it appears that HP T510 has another DVI connector (DVI-D), but the signals come from SiI 164 chip made by Silicon Image. Many VIA Technologies chipsets have a thing called DVP, (Digital Video Port) and apparently, SiI 164 is connected to DVP. At this point, OpenChrome does not support this chip, although SiI 164 and VT1632A are really register compatible except vendor and device IDs, so we should be able to support it in the future. If you read through some comments here, the OpenChrome was not able to detect SiI 164 through I2C bus. Hi Kevin,
> In general, Lubuntu 12.04 install demands about 4.4 GB or so empty space for
> installation.
> In practice, it occupies about 2 GB when it is first installed.
> I believe the Lubuntu 12.04 installer is borrowed from Ubuntu, hence, it
> appears to require 4.4 GB of storage capacity even though Lubuntu does not
> really use 4.4 GB.
Within my thin clients, the maximum size of the flash memory is 4GB. And that is why I prefer to use a ATA/SATA/CF devices instead.
But here is a question to ask about the installation. When I am trying to install Lubuntu/Ubuntu, when I select "Install Ubuntu" from the option on the screen, it will not enter into the final installation screen and the display reports "frequency out of range". So have you met this issue before with the installation?
I am using a USB stick with Lubuntu/Ubuntu ISO file to do that. But when I try this USB stick installation with other boards(i.e., AMDs), the installation works fine.
Thanks,
Frank
Hi Kevin, > > I have not really solved the problem of how I will be dealing with these > thin clients. > So far, I got as far as trying out Puppy Linux 5.7.1 on Wyse C00X using a > USB flash memory stick. The problem of using USB memory stick is the system is very slow even the OS can be installed on that. > However, I have not been able to use Git correctly on it, so the progress on > that front has stalled . . . > I really use a regular laptop (Epic 1314 laptop which is an equivalent of > MSI VR321 laptop) with a large enough hard drive (40 GB) as the main > development platform. Yup, just as I said, I prefer to use a ATA/SATA/CF device to do the development work. Thanks, Frank Hi Kevin,
Yup. Definitely I want to give a try with your new patches. But as I replied in previous information, I can't install Ubuntu/Lubuntu 12.04 on those thin clients!
For HP T510, as you said, I have seen SiI164 chip on the board. So do you mean that SiI164 is also an TMDS transmitter chip which is similar as VT1632A and can convert TMDS to DVI-I? So for the first DVI port of T510, if my understanding is correct, it does not using any transmitter.
Thanks,
Frank
>
> Wow, you now have several thin clients!
> Regarding DVI, you should try the latest code that I just committed for
> improved DVI support, but I can say that DVI coming out of VT1632A is fairly
> unproven at this point.
> This is due to the fact that the code to support it was donated in January
> 2015, and I do not think it was tested adequately before it was committed.
> That being said, I will be very interested in seeing if it will work with
> the current code.
> Regarding HP T510, it is VX900 chipset based, so the DVI-I "should" work.
> Actually, it appears that HP T510 has another DVI connector (DVI-D), but the
> signals come from SiI 164 chip made by Silicon Image.
> Many VIA Technologies chipsets have a thing called DVP, (Digital Video Port)
> and apparently, SiI 164 is connected to DVP.
> At this point, OpenChrome does not support this chip, although SiI 164 and
> VT1632A are really register compatible except vendor and device IDs, so we
> should be able to support it in the future.
> If you read through some comments here, the OpenChrome was not able to
> detect SiI 164 through I2C bus.
> Within my thin clients, the maximum size of the flash memory is 4GB. And
> that is why I prefer to use a ATA/SATA/CF devices instead.
> But here is a question to ask about the installation. When I am trying to
> install Lubuntu/Ubuntu, when I select "Install Ubuntu" from the option on
> the screen, it will not enter into the final installation screen and the
> display reports "frequency out of range". So have you met this issue before
> with the installation?
> I am using a USB stick with Lubuntu/Ubuntu ISO file to do that. But when
> I try this USB stick installation with other boards(i.e., AMDs), the
> installation works fine.
>
I tried Ubuntu 10.04, it can be installed successfully. And after the bootup, it shows VESA driver is used in UMS mode.
So is it the DDX driver(xf86-video-openchrome) 0.3.3 which make Ubuntu/Lubuntu 12.04 installation failed? And how you guys solve this issue?
Thanks,
Frank
> I tried Ubuntu 10.04, it can be installed successfully. And after the
> bootup, it shows VESA driver is used in UMS mode.
> So is it the DDX driver(xf86-video-openchrome) 0.3.3 which make
> Ubuntu/Lubuntu 12.04 installation failed? And how you guys solve this issue?
>
Hi Kevin,
I gave a try with Ubuntu 10.04 with the latest DDX code on HP T510 platform DVI-D port, unfortunately it does not show the desktop. I attached the log.
But for DVI-I port, I have tried both DVI-D and VGA for this integrated port, from the Xorg.0.log, it shows when DVI-D is used, EDID is probed out, but still, it can not enter into the desktop too. For VGA, no desktop on the display is shown.
Thanks,
Frank
Created attachment 122366 [details]
DVI-D port output for HP510 platform
Created attachment 122367 [details]
DVI-I(using DVI) Xorg log for HP T510
Hi Christopher,
Okay, I figured out (at least for me) a satisfactory way to test OpenChrome on Wyse C00X with Puppy Linux.
I am using Precise Puppy 5.7.1 for testing purposes, and I have been pretty frustrated not being able to use Git on my Precise Puppy despite having already installed it on that system (in a USB flash storage device).
This is how I did it.
1. Build OpenChrome on the regular development system with debug messages activated (normal operating procedure)
2. Copy openchrome_drv.so located in /usr/lib/xorg/modules/drivers to a USB flash storage device
3. Copy libchromeXvMC.so.1.0.0 and libchromeXvMCPro.so.1.0.0 located in /usr/lib to a USB flash storage device
4. Boot Puppy Linux
5. Set Puppy Linux up to save the session when it shuts down (important)
6. Copy openchrome_drv.so in a USB flash storage device to an active Puppy Linux session's /usr/lib/xorg/modules/drivers
7. Copy libchromeXvMC.so.1.0.0 and libchromeXvMCPro.so.libchromeXvMC.so.1.0.0 and libchromeXvMCPro.so.1.0.01.0.0 located in a USB flash storage device to an active Puppy Linux session's /usr/lib
8. Shut down the Puppy Linux session (the RAM disk's content should automatically be save to the attached USB flash storage device)
9. Boot Puppy Linux
Optionally, the Puppy Linux's original openchrome_drv.so, libchromeXvMC.so.1.0.0, and libchromeXvMCPro.so.1.0.0 can be saved, but it is not absolutely necessary.
One important thing to note is that the OS used to build OpenChrome should be similar to the version of Puppy Linux used.
For Precise Puppy, I used Lubuntu 12.04 i386.
I have not tested Tahrpup due to the fact that I currently do not have an active development environment comparable to Ubuntu 14.04.
Based on my own testing this is what happened.
Regarding Wyse C00X, VGA is now working.
Obviously, I used a DVI to VGA adapter for this.
Indeed, the lack of the use of I2C bus 2 for VGA monitor detection was the culprit of this bug you reported.
That being said, DVI is still not working.
I have been making substantial changes to OpenChrome code base (i.e., removal of the large known device table and VESA BIOS Extension based display mode setting support), and unfortunately, the code stability is very fluid at this point.
Obviously, it is my policy not to do a commit that will break the code, and at least with my own test environment, the code happened to be working.
However, several other people have reported regression of the code,
I am in the process of fixing the code, although this is somewhat stalled at this point since I am trying to integrate newer save / restore code hoping to fix long standing standby mode resume bugs.
The code for this was written last year, and I was looking for a chance for integration at some point.
Personally, I had to get rid of "rot" in the code (i.e., the large known device table and VESA BIOS Extension based display mode setting support) since the display resource detection code was doing lots of strange things.
I have some good ideas on how to improve the display detection moving forward.
Christopher, regarding the instability you have reported, I strongly suspect the SD card reader you are using is the culprit, not the current OpenChrome code base.
As for myself, I used a large enough (i.e., 4 GB or larger) USB 2.0 flash storage device instead of an SD card.
I often get them at an electronics related trade shows for free, so I decided to use one since I already have more than enough such devices at my place.
Anyway, this is the best USB flash storage device Puppy Linux installation instructions I have found on the Internet.
http://www.murga-linux.com/puppy/viewtopic.php?t=54566
I do not plan to close this bug any time soon since DVI related bugs remain, but at least for the moment, the current OpenChrome code's display detection capability is comparable to OpenChrome Version 0.2.904 (i.e., in the box device driver for Precise Puppy).
The DVI coming from an external transmitter chip (VT1632A) is still broken, and I plan to fix this in the very near future.
Pardon me for not mentioning it sooner -- but rcrsn51 -- who made that HowTo -- has also made one for a utility of his, called "ISOBooter". That HowTo is here, you will probably need actual bash to run it (IIRC Ubuntu defaults to dash, which is of course different) -- http://www.murga-linux.com/puppy/viewtopic.php?t=67235 My humblest apologies for not being more active lately, I'm still trying to get that script working, and -- aside from that -- I've been struggling with some IRL stuff, plus my mother's birthday is in less than a week! Worth noting, though -- my most recent attempt was using a USB flash drive... I seem to recall stating that fairly clearly, although I could be wrong as I have not looked back through the comments to check. I can't imagine what the difference would be to the OS... a filesystem is a filesystem is a filesystem -- or so I'd think... Also, again, Precise 5.7.1 is KNOWN WORKING prior to this issue being raised -- as it has an older (pre-0.3.x) version of openchrome. The problems do not start until TahrPup / Ubuntu Trusty Tahr 14.04. I have independently verified, through accident in fact, that this is true of at least two Ubuntu derivatives -- Linux Mint "Rosa" will bring up a desktop using the "vesa" driver, but as left-click crashes and restarts the WM, it's not functional. Linux Lite won't even bring up a desktop; it crashes similar to TahrPup -- black screen, no text -- but I couldn't extract enough useful information out of them to do anything meaningful; their devs don't care to mingle with the common folk (sadly) which means a lot of people are stranded without real answers. The best advice I got was "use this version that's more than one major revision behind" which is, when you think about it, a little daft. I'll retest --again, from flash drive-- later, but I really don't see that being much of a difference from the SD card. Which I still have to order a replacement of... ugh... (In reply to Christopher from comment #278) Hi Christopher, > Pardon me for not mentioning it sooner -- but rcrsn51 -- who made that HowTo > -- has also made one for a utility of his, called "ISOBooter". > > That HowTo is here, you will probably need actual bash to run it (IIRC > Ubuntu defaults to dash, which is of course different) -- > http://www.murga-linux.com/puppy/viewtopic.php?t=67235 > > My humblest apologies for not being more active lately, I'm still trying to > get that script working, and -- aside from that -- I've been struggling with > some IRL stuff, plus my mother's birthday is in less than a week! > > Worth noting, though -- my most recent attempt was using a USB flash > drive... I seem to recall stating that fairly clearly, although I could be > wrong as I have not looked back through the comments to check. I can't > imagine what the difference would be to the OS... a filesystem is a > filesystem is a filesystem -- or so I'd think... > > Also, again, Precise 5.7.1 is KNOWN WORKING prior to this issue being raised > -- as it has an older (pre-0.3.x) version of openchrome. The problems do not > start until TahrPup / Ubuntu Trusty Tahr 14.04. I have independently > verified, through accident in fact, that this is true of at least two Ubuntu > derivatives -- Linux Mint "Rosa" will bring up a desktop using the "vesa" > driver, but as left-click crashes and restarts the WM, it's not functional. > Linux Lite won't even bring up a desktop; it crashes similar to TahrPup -- > black screen, no text -- but I couldn't extract enough useful information > out of them to do anything meaningful; their devs don't care to mingle with > the common folk (sadly) which means a lot of people are stranded without > real answers. The best advice I got was "use this version that's more than > one major revision behind" which is, when you think about it, a little daft. > > I'll retest --again, from flash drive-- later, but I really don't see that > being much of a difference from the SD card. Which I still have to order a > replacement of... ugh... Yes, I do understand that OpenChrome that came with Precise Puppy 5.7.1 was working when you reported the bug. The thing is, the code I have been working with for the past few months and the code that was used in OpenChrome Version 0.2.904 are totally different. When James Simmons (the OpenChrome developer who pretty much did most code commits for the past 5 years) released OpenChrome Version 0.3.0, he totally rewrote the code, in order to support KMS (Kernel Mode Setting), in addition to the traditional UMS (User Mode Setting). Just for your basic knowledge if you are not familiar with this KMS and UMS lingo, in KMS, the DRM module (Direct Rendering Manager) handles screen mode setting. KMS support was added in Linux kernel 2.6.28 if I am correct (only supported Intel IGP at the time) and ATI Technologies / AMD Radeon KMS support was added in Linux kernel 2.6.29. Looking at both OpenChrome and the newer KMS supporting DRM module, it appears that most of James' development resources (i.e., time) went towards implementing the KMS supporting DRM module. The code I have been struggling with is what is called UMS. In UMS, display mode setting code in inside OpenChrome itself (i.e., openchrome_drv.so). I do know several previous developers are not happy when I write anything that appears mildly critical of them (I guess it is a sensitive issue to them.), but that being said, James definitely broke the display detection code when he rewrote the code for OpenChrome Version 0.3.x. He assumed that only I2C bus 1 is used for VGA detection. In addition to this, Xavier Bachelot made some changes to the code where OpenChrome was no longer detecting "analog" type interfaces (i.e., VGA interface). This is why the VGA coming from DVI to VGA adapter worked with Version 0.2.9xx, but not with Version 0.3.3. OpenChrome Version 0.3.3 code was no longer probing I2C bus 2 for VGA detection, in addition to not looking for an analog type interface, and that is the root cause of the problem. It appears that OpenChrome "happened" to probe I2C bus 2 for VGA monitor in Version 0.2.9xx, but my personal opinion is that it just happened to work (I do not think it was that well written.). What I am trying to do now is, I am trying to rewrite the display detection completely (i.e., but not from the ground up, as that will take too much time), and hopefully that will result in a more reliable code. This is why I removed the "rot" from the code recently, as this stuff was getting in my way of rewriting the code. I personally did not want to do this much code rewriting at this point since I wanted to release OpenChrome Version 0.3.4 quickly, but at this point, I feel like I will be in for the long haul (i.e., several months) before I can release a new version. I will likely call this OpenChrome Version 0.4.0, and will likely cancel Version 0.3.4. Hi Christopher,
Another thing I wanted to say is, I am cautiously optimistic that if you compile the latest OpenChrome code in the repository in Ubuntu 14.04 or similar environment (i.e., Xubuntu 14.04, etc.), and transfer it the way I wrote down the instruction a few comments ago to Tahrpup version of Puppy Linux, it will likely work, at least if you limit the use to VGA via DVI to VGA adapter.
That being said, I am currently trying to integrate improved standby resume code that is not really related to this bug (This was being worked on prior to the bug report you filed.).
After that, I plan to do a major rewriting of the display detection code.
The thing is, the previous developers (This appears to be a sensitive issue to the previous developers.) appeared to not have been using what is known as "strapping" settings to aid the display detection.
This is somewhat documented in several public documents I have obtain legally, but it somewhat buried in the documents, so if one is not paying attention, one might miss it.
What this "strapping" thing is that it is a simple resistor array that allows the chip to obtain bare minimum information about the chip at system power up.
A few pins are used to tell the chip what screen resolution is the native screen resolution of the flat panel.
Currently, at least for flat panel detection, the code is reading back the CRTC (CRT Controller; "CRT" == that old "tube" we all used until about 10 years ago) settings that directly handles screen resolution, and this is probably a very bad practice.
This is the reason why the screen detection is somewhat weird at the moment since the last couple of commits I have made.
In the process of getting rid of the code "rot," I happened to break the code.
Fascinating! Feel free to be technical with me -- I have The Google and Wiki and the ability to ask questions if needed ;) Although my background is mostly hardware at the wires-and-chips level, and rooted somewhat in chips from the mid-Seventies through about the mid- to late Eighties, I'm always interested in hearing about code and what it does how, because that's a real weak point of mine -- I have basically useless coding knowledge. (remember MS QuickBASIC PDS 7.1...? Yeah, that. Sadly.) I'd love to take that and make it useful... the more I soak up, the more I know. As for CRTs and other quaint-sounding equipment -- I'm quite familiar with retro tech. I'll keep it short by mentioning simply that I have two Commodore 64s I keep meaning to fix -- memory issues, the DRAMs in those are known to get a bit addled after a while -- and I'm working on building a Signetics 2650 based homebrew board as well. The 2650, by the way, is an interesting CPU that I don't think got its due attention -- not much was done with it. A pity, since it's got on-chip serial! (...and, lucky for me, it got used as a pinball game controller a little -- the official hobbyist's ROM image from Signetics, PIPBUG it was called, still exists if you look for it, because of that. It's actually Googleable!) I could say oh so much more but that's best kept off the comment thread as (a) I get tremendously long-winded with this stuff and (b) it's off-topic anyways. If you're interested... you have my email. (I'd love to get some schematic checking done on that 2650 homebrew ;) ) Hi Kevin, Besides my HP510 platform, I verified latest UMS code on my Wyse V90LE platform and found DVI port can not go into desktop. I attached the log. Thanks, Frank Created attachment 122490 [details]
X log for latest UMS on Wyse V90LE platform DVI port
(In reply to HuangRan from comment #282) Hi Frank, > Hi Kevin, > > Besides my HP510 platform, I verified latest UMS code on my Wyse V90LE > platform and found DVI port can not go into desktop. > I attached the log. > > Thanks, > Frank Does VGA at least work if you use a DVI to VGA adapter for Wyse V90LE? I think what needs to happen is to set the settings for DVP1 (Digital Video Port 1) correctly so that frame buffer contents from the correct IGA (display controller) is sent to DVP1. I plan to rewrite the display and output control code so that the chip strapping is used effectively to figure out what configuration the underlying system has. I now have a way to test VT1632A related code with my Wyse C00X thin client, so I will work on this in the next few days (After I do a few commits, including the DRM / KMS fix for AGP.). (In reply to HuangRan from comment #282) Hi Frank, > Hi Kevin, > > Besides my HP510 platform, I verified latest UMS code on my Wyse V90LE > platform and found DVI port can not go into desktop. > I attached the log. > > Thanks, > Frank Does VGA work if you use a DVI to VGA adapter? I think what I will have to do is to set DVP1 (Digital Video Port 1) correctly, so that the correct IGA (display controller) is the source of DVP1. I will work on this in the next few days after I do a few commits, including the DRM / KMS fix for AGP you and I worked on. Hi Kevin, (In reply to Kevin Brace from comment #284) > Does VGA at least work if you use a DVI to VGA adapter for Wyse V90LE? Not working for VGA port(I use a DVI-I->VGA converter) now. Attached is the log. It seems VT1632 probing is still working even VGA port is used from DVI-I. And there is no EDID probe process for VGA port. > I think what needs to happen is to set the settings for DVP1 (Digital Video > Port 1) correctly so that frame buffer contents from the correct IGA > (display controller) is sent to DVP1. What does Digital Video Port be used for? > I plan to rewrite the display and output control code so that the chip > strapping is used effectively to figure out what configuration the > underlying system has. > I now have a way to test VT1632A related code with my Wyse C00X thin client, > so I will work on this in the next few days (After I do a few commits, > including the DRM / KMS fix for AGP.). Thanks, Frank Created attachment 122518 [details]
X log for latest UMS on Wyse V90LE platform VGA port
Hi Kevin, You can compare two logs(X log for latest UMS on Wyse V90LE platform DVI port, X log for latest UMS on Wyse V90LE platform VGA port). Obviously when I am using DVI port, the edid is probed out and be there. But when I am using VGA port, the driver still try to use VT1632 for VGA port which is not correct... Thanks, Frank (In reply to HuangRan from comment #288) Hi Frank, > Hi Kevin, > > You can compare two logs(X log for latest UMS on Wyse V90LE platform DVI > port, X log for latest UMS on Wyse V90LE platform VGA port). Obviously when > I am using DVI port, the edid is probed out and be there. But when I am > using VGA port, the driver still try to use VT1632 for VGA port which is not > correct... > > Thanks, > Frank If I reverse the last few commits, and I may also disable VT1632A detection portion after that. This might improve the situation. (In reply to HuangRan from comment #288) Hi Frank, > Hi Kevin, > > You can compare two logs(X log for latest UMS on Wyse V90LE platform DVI > port, X log for latest UMS on Wyse V90LE platform VGA port). Obviously when > I am using DVI port, the edid is probed out and be there. But when I am > using VGA port, the driver still try to use VT1632 for VGA port which is not > correct... > > Thanks, > Frank 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. (In reply to Kevin Brace from comment #290) > Try that code ("git reset --hard 802544370dd827ed3488965e39804e3cb630888a"), > and see what happens. Again, please use 'git checkout 802544370dd8' instead. There is no need to throw away data, just move about in history. Please learn to use the tool correctly. > (In reply to Kevin Brace from comment #290) >> Try that code ("git reset --hard >> 802544370dd827ed3488965e39804e3cb630888a"), >> and see what happens. > > Again, please use 'git checkout 802544370dd8' instead. There is no need to > throw away data, just move about in history. Please learn to use the tool > correctly. 'git reset --hard HEAD' and 'git reset --hard HEAD~1' fixes most problems with Git :) Speaking from experience, one can spend countless hours in the man pages and then grepping stack overflow trying to figure out how to do the simplest of task. Sometimes its easier to simply do the simple stuff, like run concurrent clones or reset a repo to avoid fighting with the tool with the merges. Jeff 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. 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. (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. Just a thought -- a monitor shows up on a VGA connector as a set of 68-ohm resistors on the Red Green and Blue lines to their respective grounds. Is the stuff you're working with low-level enough that you can detect whether the thing is there based on that, at least for analog displays...? Hi Frank, In your situation with Wyse V90LE, it appears that OpenChrome is not able to obtain EDID from I2C bus 1 or 2. __________________________________________________________________________ . . . [ 49.929] (II) CHROME(0): NativeMode: 640 407 [ 49.929] (II) CHROME(0): Printing probed modes for output LVDS-1 [ 49.929] (II) CHROME(0): Modeline "640x407"x59.7 20.25 640 664 720 800 407 410 420 424 -hsync +vsync (25.3 kHz) [ 49.929] (--) CHROME(0): Probing for a VGA monitor on I2C Bus 1. [ 49.929] (II) CHROME(0): I2C device "I2C Bus 1:ddc2" registered at address 0xA0. [ 49.936] (--) CHROME(0): Did not detect a VGA monitor on I2C Bus 1. [ 49.936] (--) CHROME(0): Probing for a VGA monitor on I2C Bus 2. [ 49.936] (II) CHROME(0): I2C device "I2C Bus 2:ddc2" registered at address 0xA0. [ 49.940] (--) CHROME(0): Did not detect a VGA monitor on I2C Bus 2. [ 49.940] (--) CHROME(0): Now perform manual detection of a VGA monitor. [ 49.940] (II) CHROME(0): EDID for output VGA-1 [ 49.943] (II) CHROME(0): Entered via_vt1632_detect. . . . __________________________________________________________________________ If OpenChrome is not able to obtain EDID via I2C bus 1 or 2, the chance of VGA working is very slim (It is possible it can work if the manual detection succeeds, but I have never seen this actually working.). I do not know why EDID is not appearing on I2C bus 1 or 2 for Wyse V90LE. Hi Kevin, With my experiment with drm-openchrome kernel(KMS enabled if using this kernel) just now, I found DVI-D from DVI-I interface on V90LE is working for latest DDX(xf86-video-openchrome) code. That is good! The failure case I mentioned before is using non drm-openchrome kernel. At least, right now, we found a working way to make V90LE worked with DVI-D port. Furthermore, on V90LE, VT1632 chip is used. So I think current code for VT1632 takes effect although I am not doing debugging to verify this point. But for VGA port on V90LE, the case is still same. No EDID is probed out. As you wrote below, it seems I2C bus didn't probe EDID for current VGA port from DVI-I interface. Thanks, Frank (In reply to Kevin Brace from comment #297) > > > Hi Frank, > > In your situation with Wyse V90LE, it appears that OpenChrome is not able to > obtain EDID from I2C bus 1 or 2. > > __________________________________________________________________________ > . . . > [ 49.929] (II) CHROME(0): NativeMode: 640 407 > [ 49.929] (II) CHROME(0): Printing probed modes for output LVDS-1 > [ 49.929] (II) CHROME(0): Modeline "640x407"x59.7 20.25 640 664 720 > 800 407 410 420 424 -hsync +vsync (25.3 kHz) > [ 49.929] (--) CHROME(0): Probing for a VGA monitor on I2C Bus 1. > [ 49.929] (II) CHROME(0): I2C device "I2C Bus 1:ddc2" registered at > address 0xA0. > [ 49.936] (--) CHROME(0): Did not detect a VGA monitor on I2C Bus 1. > [ 49.936] (--) CHROME(0): Probing for a VGA monitor on I2C Bus 2. > [ 49.936] (II) CHROME(0): I2C device "I2C Bus 2:ddc2" registered at > address 0xA0. > [ 49.940] (--) CHROME(0): Did not detect a VGA monitor on I2C Bus 2. > [ 49.940] (--) CHROME(0): Now perform manual detection of a VGA monitor. > [ 49.940] (II) CHROME(0): EDID for output VGA-1 > [ 49.943] (II) CHROME(0): Entered via_vt1632_detect. > . . . > __________________________________________________________________________ > > > If OpenChrome is not able to obtain EDID via I2C bus 1 or 2, the chance of > VGA working is very slim (It is possible it can work if the manual detection > succeeds, but I have never seen this actually working.). > I do not know why EDID is not appearing on I2C bus 1 or 2 for Wyse V90LE. Hi Kevin, (In reply to Kevin Brace from comment #295) > > 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. That's true. for LVDS, sometimes, there is no I2C bus. So there is no need for EDID probe. The resolution information sometimes is in BIOS(vBIOS table). So the graphics driver just need try to get that from BIOS and do the mode setting. I have not gotten such a board which has the LVDS interface to try. By the way, in next few days, I will spend some time on current HDMI issue for KMS driver. Stay tuned... Thanks, Frank (In reply to Christopher from comment #296) Hi Christopher, > Just a thought -- a monitor shows up on a VGA connector as a set of 68-ohm > resistors on the Red Green and Blue lines to their respective grounds. > > Is the stuff you're working with low-level enough that you can detect > whether the thing is there based on that, at least for analog displays...? Christopher, I am not an analog guy, and in fact I struggle in anything analog (^_^; The typical method used for detecting a VGA monitor is to use I2C bus or what is also called VESA DDC (Display Data Channel) to obtain EDID (Extended Display Identification Data). EDID tells the graphics device driver about screen resolution support. In the case of OpenChrome and other Linux graphics device drivers, the EDID identifying the interface type as analog type is used to determine whether or not the device driver is trying to detect a VGA interface. OpenChrome apparently used to do this, and then one day Xavier removed it for some reason. However, when I tried to fix your DVI to VGA adapter problem, not looking into the analog or digital type for the interface type became a problem (for hardware that does not have DVI like my laptop), so after looking at other graphics device driver source code, I put the interface type check back in. However, at least for some VIA hardware, they do have a hardware level VGA interface presence detection circuit (this is what people call mixed signal IC design) that can actual probe the presence of a VGA monitor. The problem of relying on this is that it is not clear if every VIA past hardware supports it (OpenChrome tries to support all the way back to CLE266 chipset which was released around 2003). I will imagine that the existence of this feature is to support VGA hot plugging. (In reply to HuangRan from comment #299) Hi Frank, > Hi Kevin, > > That's true. for LVDS, sometimes, there is no I2C bus. So there is no need > for EDID probe. The resolution information sometimes is in BIOS(vBIOS > table). So the graphics driver just need try to get that from BIOS and do > the mode setting. > I have not gotten such a board which has the LVDS interface to try. > By the way, in next few days, I will spend some time on current HDMI issue > for KMS driver. Stay tuned... > > Thanks, > Frank 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. 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. 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? 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")). Hi Kevin, (In reply to Kevin Brace from comment #301) > 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 > 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
Forgive my ignorance Kevin... I picked up a couple of additional thin
clients for testing. I'm trying to determine what needs to be done for
them.
That leads to the question (I think someone else brought it up).... Is
this 100+ thread all related to OpenChrome and VX855 chipset? It seems
to be all over the place, and I am having trouble determining what
applies and what I need to do.
If the thread is drifting, could you help keep folks focused on the
problem at hand to help ensure problems and solutions can be located
without much fuss?
My apologies for speaking out of turn.
Jeff
(In reply to Jeffrey Walton from comment #303) Hi Jeffrey, > > Forgive my ignorance Kevin... I picked up a couple of additional thin > clients for testing. I'm trying to determine what needs to be done for > them. > > That leads to the question (I think someone else brought it up).... Is > this 100+ thread all related to OpenChrome and VX855 chipset? It seems > to be all over the place, and I am having trouble determining what > applies and what I need to do. > > If the thread is drifting, could you help keep folks focused on the > problem at hand to help ensure problems and solutions can be located > without much fuss? > > My apologies for speaking out of turn. > > Jeff You are quite right that the topic of discussion related to this bug report has been drifting towards areas not necessarily related to VX855 chipset. I have been thinking of that for the past few days, and thank you very much for bringing that up. As for some comments I have made here, for many ordinary users of VIA IGP and Linux (and BSD), only a new release of OpenChrome will solve their woes since 99% of users never will compile the device driver from source code. I was explaining my intention of when I can release a new version of OpenChrome, and with the several commits I made today, I think it is in a good enough condition to be released since I resolved the lingering issue of how to detect a flat panel automatically. As for the original reporter who reported the bug (Christopher), he has been having storage related issues (that is my take on it), but I have independently confirmed that VGA signal coming out of DVI to VGA adapter is now working with my own Wyse C00X thin client using Puppy Linux 5.7.1. It was an I2C related issue of the newer generation code (Version 0.3.x code base) that was the problem. DVI coming out of Wyse C00X may or may not be working, but if someone wants to file a bug report regarding this, please do so. So, for the sake of keeping the discussion related primarily to the bug that was originally reported, I will close this bug. For people who reported problems with VX900 chipset, please file a new bug report when I release OpenChrome Version 0.4.0, hopefully in the next few days or weeks. The, er, 'storage situation' (somewhat apt) *may* be resolved -- I have had some help with the script that has gone very well. I believe I've been able to make a successful install (FINALLY!) to the SD card that's been giving me issues... I meant to test it yesterday, when I made the prospective install, but did not have the opportunity. I will make a note to test it tonight or tomorrow. If I can boot it again, I will test and report back, for sure. If not, I will report that instead. Either way, I should be heard from again in the next few days -- if I forget, a tickler won't hurt anything ;) BTW, Kevin, if it would be easier for you to test on your end, let me know and I'll tell you how I've been doing it. It will sound a lot more complicated than it really is ;) FWIW, I have been using neither git nor any network connection on the WYSE system itself. Oh -- and before I forget -- thank you Kevin, and ALL thread participants here, for helping me (and each other) with this mess. I really do appreciate all of your work :) (In reply to Christopher from comment #305) Hi Christopher, > The, er, 'storage situation' (somewhat apt) *may* be resolved -- I have had > some help with the script that has gone very well. I believe I've been able > to make a successful install (FINALLY!) to the SD card that's been giving me > issues... I meant to test it yesterday, when I made the prospective install, > but did not have the opportunity. I will make a note to test it tonight or > tomorrow. If I can boot it again, I will test and report back, for sure. If > not, I will report that instead. Either way, I should be heard from again in > the next few days -- if I forget, a tickler won't hurt anything ;) > > BTW, Kevin, if it would be easier for you to test on your end, let me know > and I'll tell you how I've been doing it. It will sound a lot more > complicated than it really is ;) FWIW, I have been using neither git nor any > network connection on the WYSE system itself. > > Oh -- and before I forget -- thank you Kevin, and ALL thread participants > here, for helping me (and each other) with this mess. I really do appreciate > all of your work :) It took a lot of effort to figure out why your Puppy Linux was not booting, but I am hoping that you can get it working if you compile and install the latest OpenChrome code. After OpenChrome Version 0.4.0 is released, you are going to have to convince Puppy Linux developers to download the latest code, and replace the buggy Version 0.3.3 code with the latest one. As far as my own testing goes, the current OpenChrome works with Ubuntu 10.04 LTS based OSes, along with Ubuntu 12.04 LTS based OSes. The Version 0.3.3 that came with Ubuntu 14.04 LTS based OSes should also be replaced with the latest one. If the Puppy Linux developers are willing to replace the buggy OpenChrome that came with Ubuntu 10.04 LTS with the latest version, that will be good for those who use that version of Puppy Linux. If you wanted the straight DVI to work, you can file a new bug report since this one got so long that it is hard to manage the thread. Christopher, thanks for filing the bug report, and spending your own time on the testing. (In reply to HuangRan from comment #302) Hi Frank, I will post a reply to your comment over at Openchrome-devel mailing list since the topic has been drifting away from the original bug report. We can continue the discussion there. Hi Christopher, I retested the latest OpenChrome master branch code with Wyse C00X and Puppy Linux 5.7.1 (Precise Puppy). I can confirm that VGA via DVI to VGA adapter works, but DVI is not working. I will likely try to fix the DVI issue with OpenChrome Version 0.4.x release in the near future since it is an important feature to get it working. That's all. On my hardware, this bug is still present. I am running from a USB flash drive at this time, NOT the SD card, as the SD-to-IDE adapter I have been using is not working properly.
Procedure I used, which can be used on ANY such system --
On networked system, opened terminal within 'openchrome' git directory, ran commands...
# git reset --hard
# git pull
Copied directory to a flash drive, which already had the build deps on it. Booted from another drive (which has many Puppies on it, for testing, etc, purposes) into X-Tahr 1b3, based on TahrPup 6.0.2. I booted without pupsave ("RAM Mode") which means that the boot media was not mounted once booted.
CTRL+ALT+BKSP as soon as I saw the black screen replacing the text screen, dropping me back into text mode. Manually mounted sda1 (boot drive) and sdb1 (deps+openchrome files drive). cd'd to sda1/xtahr/ and ran...
# sfs_load devx_tahr_6.0.2.sfs
...to load "devx" SquashFS file with development & compilation software inside.
cd'd to deps directory on sdb1 (deps+openchrome drive) and used "petget" to install each package, ENTERing through the dialogs and pressing CTRL+C after the last one to exit petget (otherwise it sits there till the end of time, waiting for the display to open when it never will)...
# petget libmirclient7_0.1.8+14.04.20140411-0ubuntu1_i386.deb
# petget libmirclient-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb
# petget libmirplatform_0.1.8+14.04.20140411-0ubuntu1_i386.deb
# petget libmirprotobuf0_0.1.8+14.04.20140411-0ubuntu1_i386.deb
# petget libmirprotobuf-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb
# petget libprotobuf8_2.5.0-9ubuntu1_i386.deb
# petget libprotobuf-dev_2.5.0-9ubuntu1_i386.deb
# petget mircommon-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb
...and cd'd back up one. Ran copy command...
# cp -r /xf86-video-openchrome /root/
...as I find that the driver will not compile while resident on the USB drive, but *MUST* be copied over. (No idea why, looks to me to be something to do with timestamps.) cd'd into /root/xf86-video-openchrome, ran commands, with expected output...
# ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug
# make
# make install
Upon completion, ran...
# xorgwizard
At "this is about to test XORG" screen, pressed [ESC] to drop back to # prompt, and manually edited xorg.conf and one other file...
# mp /etc/X11/xorg.conf
# mp /etc/X11/xorg.conf.VIA_VX855
...both are identical now, replacing the driver name "modesetting" with the driver name "openchrome" -- xorgwizard is stubborn :P Afterward, cd'd into /etc/X11 and removed some extraneous cruft that could potentially cause confusion...
# rm xorg.conf.t2
# rm xorg.conf-auto-armsystem
# rm Xorg.conf-generic-laptop
...etc. Finally, ran command...
# xwin
Screen blanked, then popped up with the usual nasty garble. (He's dead, Jim...) System did not respond to CTRL+ALT+BKSP, per usual, so held down power button until poweroff occurred. Opened Chromium on networked system, navigated to https://bugs.freedesktop.org/show_bug.cgi?id=91966, and began typing ;)
Kevin -- if you want to try in X-Tahr yourself -- no reason not to -- the download is here (direct link) -- http://smokey01.com/rg66/X-tahr/testing/X-tahr-1b3.iso
You will need the TahrPup 6.0.2 'devx' from here (direct link) -- http://distro.ibiblio.org/puppylinux/puppy-tahr/iso/tahrpup%20-6.0-CE/devx_tahr_6.0.2.sfs
Download the listed package deps, above, from pkgs.org. I'm not going to bother providing links for those, I'm too lazy :P sorry.
(In reply to Christopher from comment #309) Hi Christopher, > On my hardware, this bug is still present. I am running from a USB flash > drive at this time, NOT the SD card, as the SD-to-IDE adapter I have been > using is not working properly. > > Procedure I used, which can be used on ANY such system -- > > On networked system, opened terminal within 'openchrome' git directory, ran > commands... > > # git reset --hard > # git pull > > Copied directory to a flash drive, which already had the build deps on it. > Booted from another drive (which has many Puppies on it, for testing, etc, > purposes) into X-Tahr 1b3, based on TahrPup 6.0.2. I booted without pupsave > ("RAM Mode") which means that the boot media was not mounted once booted. > > CTRL+ALT+BKSP as soon as I saw the black screen replacing the text screen, > dropping me back into text mode. Manually mounted sda1 (boot drive) and sdb1 > (deps+openchrome files drive). cd'd to sda1/xtahr/ and ran... > > # sfs_load devx_tahr_6.0.2.sfs > > ...to load "devx" SquashFS file with development & compilation software > inside. > > cd'd to deps directory on sdb1 (deps+openchrome drive) and used "petget" to > install each package, ENTERing through the dialogs and pressing CTRL+C after > the last one to exit petget (otherwise it sits there till the end of time, > waiting for the display to open when it never will)... > > # petget libmirclient7_0.1.8+14.04.20140411-0ubuntu1_i386.deb > # petget libmirclient-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb > # petget libmirplatform_0.1.8+14.04.20140411-0ubuntu1_i386.deb > # petget libmirprotobuf0_0.1.8+14.04.20140411-0ubuntu1_i386.deb > # petget libmirprotobuf-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb > # petget libprotobuf8_2.5.0-9ubuntu1_i386.deb > # petget libprotobuf-dev_2.5.0-9ubuntu1_i386.deb > # petget mircommon-dev_0.1.8+14.04.20140411-0ubuntu1_i386.deb > > ...and cd'd back up one. Ran copy command... > > # cp -r /xf86-video-openchrome /root/ > > ...as I find that the driver will not compile while resident on the USB > drive, but *MUST* be copied over. (No idea why, looks to me to be something > to do with timestamps.) cd'd into /root/xf86-video-openchrome, ran commands, > with expected output... > > # ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug > # make > # make install > > Upon completion, ran... > > # xorgwizard > > At "this is about to test XORG" screen, pressed [ESC] to drop back to # > prompt, and manually edited xorg.conf and one other file... > > # mp /etc/X11/xorg.conf > # mp /etc/X11/xorg.conf.VIA_VX855 > > ...both are identical now, replacing the driver name "modesetting" with the > driver name "openchrome" -- xorgwizard is stubborn :P Afterward, cd'd into > /etc/X11 and removed some extraneous cruft that could potentially cause > confusion... > > # rm xorg.conf.t2 > # rm xorg.conf-auto-armsystem > # rm Xorg.conf-generic-laptop > > ...etc. Finally, ran command... > > # xwin > > Screen blanked, then popped up with the usual nasty garble. (He's dead, > Jim...) System did not respond to CTRL+ALT+BKSP, per usual, so held down > power button until poweroff occurred. Opened Chromium on networked system, > navigated to https://bugs.freedesktop.org/show_bug.cgi?id=91966, and began > typing ;) > > Kevin -- if you want to try in X-Tahr yourself -- no reason not to -- the > download is here (direct link) -- > http://smokey01.com/rg66/X-tahr/testing/X-tahr-1b3.iso > > You will need the TahrPup 6.0.2 'devx' from here (direct link) -- > http://distro.ibiblio.org/puppylinux/puppy-tahr/iso/tahrpup%20-6.0-CE/ > devx_tahr_6.0.2.sfs > > Download the listed package deps, above, from pkgs.org. I'm not going to > bother providing links for those, I'm too lazy :P sorry. Obviously, I will not dismiss your complaint that things aren't working with Puppy Linux 6.0.x. That being said, it is my view that there might be something else that is beyond my control (i.e., software code I did not write or fix) that might be contributing to the problem. Why do I think like this? It is because the current code base (i.e., master branch code head) has been tested with many (about 8) different generations of VIA chipsets starting from CLE266 chipset (EPIA-CL and EPIA-M) all the way to VX855 chipset (Wyse C00X). Furthermore, the code has been tested with both Ubuntu 10.04 LTS and Lubuntu 12.04 (mainly i386, but on occasions, AMD64). Yes, Ubuntu 14.04 LTS based OS is missing, and this is due to various small issues I have encountered (Lubuntu 14.04 power management applet issue and Xubuntu 14.04.4 build dependency issue) that has hampered (discouraged) my use of Ubuntu 14.04 LTS based OSes. For now, I am focused on releasing OpenChrome Version 0.4.0 within a week. I will take a look at your issue after the new OpenChrome is released. I hope that is okay. As the line from an old TV show would go -- "Vat eez dees 'ubuntu' yoo speek ov?" (If you don't get it at first -- read it, out loud or otherwise, imagining yourself to be a stereotypical German of some sort of distinguished military position. My apologies for the apparent ethnic insensitivity...) You don't need Ubuntu for this. You don't need any Linux other than Puppy, in fact (presuming that git works on Windows and Mac, which I'm sure it does) -- and even then, only on the target system. For the record, I believe what I did to get Git is to install the package providing support for it from the Puppy Package Manager, as present within X-Tahr 1b3 on a system where graphics actually work (in my case, a Dell e4310 laptop)... In any case... Please re-read my report of what I did, given in my last comment, as if it were a set of instructions. Follow them, and let me know what happens at the end -- does it still work for you? Not so much? "Survey sez!" The people want to know... or at least one of them does ;) Links and pointers to all build dependencies (environment included) are at the bottom of that comment, with most of the rest being the procedure... everything you need should be there, though. While I await your report back, I will hold onto $20 of my disposable income for this month --a pronounced difficulty-- so that, should your attempt to follow those instructions come out differently --or not happen at all-- I can at least have some way of verifying that I've not somehow managed to get faulty hardware. It's happened before, once (and with a very different system and circumstance) -- but once is all it takes ;) Paraphrasing a line from a truly awful comedy film (my father likes it -- and that's all that needs to be said) by the name of 'Arthur' -- "I look forward to your next comment with great eagerness." ;) Kevin -- can you confirm whether or not, having followed my procedure, you get the same result? If so, you will save me expending roughly half of my disposable income for this month, which would be rather nice... (In reply to Christopher from comment #312) Hi Christopher, > Kevin -- can you confirm whether or not, having followed my procedure, you > get the same result? If so, you will save me expending roughly half of my > disposable income for this month, which would be rather nice... I will likely be taking some time off until Thursday regarding OpenChrome coding. I worked very hard over the past 2 months or so, and I feel like I need a break from coding. Regarding whether or not you should spend your own money that you cannot really afford to spend, you probably should hold onto the money for now. Thanks for your understanding. Enjoy your well-earned vacation ;) I have the money -- it's just what it gets spent on that matters. That said, I'll take your advice for now -- mostly because I'd rather spend it on something else ;) Hi Christopher, I think I am getting out of trying to figure out Puppy Linux. I find Puppy Linux very frustrating to use compared to Lubuntu, and sometimes, it takes a lot of effort just to figure out some basic stuff that works so easily in Lubuntu. As far as I am concerned, the bug is already fixed since I confirmed that VGA coming from DVI to VGA adapter is now working with Puppy Linux 5.7.1 (Precise Puppy). As for Puppy Linux 6.0, I tried Puppy Linux 6.0.5, and the network stack is broken. I had to try it with 4 different computers, and none of them will recognize the Realtek PCIe gigabit Ethernet or USB wireless LAN. I do not want to keep spending time on figuring out a different version of Puppy Linux that works since I do not really like Puppy Linux to begin with. I am sorry to say this, but this whole business of trying to figure out Puppy Linux is causing tremendous irritation, and I am not interested in continuing to go through this. At this point, my recommendation will be for you to contact Puppy Linux developers to download OpenChrome Version 0.4.0, and replace the buggy Version 0.3.3 and 0.2.90x with Version 0.4.0. I am serious about what I am writing here, and I am not playing games with you. That's all I want to say for now. I'm confused. There is no need for a network stack with the instructions I supplied, only a USB drive or two. The term you are looking for is "sneakernet" ;) Puppy at the command line is very limited, as it's primarily a graphical operating system. Given that, and that the way Puppy works 'under the hood' is very different (or so I'm told) from most Linuxes -- yes, it can be confusing. Very well. I will pay the $20 for another WYSE client, to verify whether or not the original complaint (which was on TahrPup 6.0.2 and X-Tahr 1b2... 1b3 had not yet been released) has been filled. While that forces me to put off for next month, another project I had wanted to accomplish, it's not a big deal. I'll keep you posted. (In reply to Christopher from comment #316) Hi Christopher, > I'm confused. There is no need for a network stack with the instructions I > supplied, only a USB drive or two. The term you are looking for is > "sneakernet" ;) > > Puppy at the command line is very limited, as it's primarily a graphical > operating system. Given that, and that the way Puppy works 'under the hood' > is very different (or so I'm told) from most Linuxes -- yes, it can be > confusing. > > Very well. I will pay the $20 for another WYSE client, to verify whether or > not the original complaint (which was on TahrPup 6.0.2 and X-Tahr 1b2... 1b3 > had not yet been released) has been filled. > > While that forces me to put off for next month, another project I had wanted > to accomplish, it's not a big deal. > > I'll keep you posted. Please understand that I do not like using Puppy Linux at all. It is a huge pain to use it in the first place, and from now on, I will not spend time trying to figure out how to operate it in the first place. I will keep a copy of Puppy Linux 5.7.1 (precise puppy) for testing purposes only, just to test VGA coming from DVI to VGA adapter and straight DVI sometime in the future when I fix the code. If the network stack of Puppy Linux 6.0.x worked, I probably should have tried it a little more, but I am giving up on it. Very late last night, I managed to figure out how to build OpenChrome on Xubuntu 14.04.4 LTS. Due to a bug in their packager, building the dependency should have ripped the OS apart if I done it normally, but this time, I managed to workaround the problem. I compiled OpenChrome Version 0.4.0 against it, and confirmed that the code works with X Server 1.15. The chipset I tested was CN896 chipset. Hence, I now have confirmation that OpenChrome Version 0.4.0 works with Trusty Tahr based OS (Ubuntu 14.04 LTS). Christopher, at this point, I will have to say that there is something going wrong within your environment, and I am not really interested in trying to figure out what that is since I have other bug fix projects I also need to work on (There are other bugs other users want to see repaired.) I have spent enormous amount of time trying to fix your bug since November 2015, I do not really want to be blamed for not coming up with a solution since the bug you reported is related to the lack of probing I2C bus 2, and this bug was already fixed last month. Furthermore, in the future, please upload the Xorg.0.log every time you do a new testing rather than just saying that stuff did not work. Without Xorg.0.log, I have no visibility into what is going on. You also need to really ensure that openchrome_drv.so located at /usr/lib/xorg/modules/drivers is really the latest one (i.e., compare it against timestamp). I will not fix any issues anything older than Version 0.4.0 from now on. For any testing, please use Version 0.4.0 from now on. If compiling OpenChrome is such a problem, please ask the Puppy Linux developers to do it, and create a new image of with OpenChrome Version 0.4.0. Eventually, this problem will solve itself (hopefully) since some Linux distributions started to switch to OpenChrome Version 0.4.0. Arch Linux has already put the code into their testing repository, and hopefully other distributions will do so in the near future. In the case of Canonical, Ubuntu 16.04.1 LTS will probably get OpenChrome Version 0.4.0 (but not 16.04 LTS), so if a future version of Puppy Linux is built from 16.04.1 LTS, you will see a fix (at least for VGA from a DVI to VGA adapter). > If compiling OpenChrome is such a problem, please ask the Puppy Linux
> developers to do it, and create a new image of with OpenChrome Version
> 0.4.0.
Often its helpful to file a bug report or feature request asking the
updated driver be picked up. Christopher should probably take a
proactive role.
I've seen a few of them for OpenChrome under Debian, Ubuntu and
Fedora. For these distros, the package name is:
* Debian - xserver-xorg-video-openchrome
* Ubuntu - xserver-xorg-video-openchrome
* Fedora - xorg-x11-drv-openchrome
Eventually, the current OpenChrome developers (is that just Kevin
now?) will get to know the distros and package maintainers, and an
offline email will do. Until the relationships are forged, its
probably best to stick to bug trackers.
My apologies for speaking out of turn.
Jeff
@ Jeffrey -- I've been proactive. I've been sidelined --only recently-- by an issue related tangentially to this bug (install issues), and I'm working actively with a member of the Puppy community to fix that. It's just not fixed yet. @ Kevin -- I'm still confused, at least a little bit. I'm not blaming you for anything at this point -- indeed, I'm very thankful for all you've done for me -- except for this one somewhat frustrating bit of not doing what I've asked to confirm whether it is indeed my environment or not. You insist -- but you will not offer proof. I understand that you are frustrated. I can relate! But I still need to know whether or not it's the environment for certain -- and until that is tested, all we have is speculation and assumption. You've tested it on a different OS and a different chipset, and it works. That's great. That's amazing. That's wonderful. But it's not my OS and it's not my hardware. I'm using a TahrPup 6.0.2 based Pup, not Tahr 6.0.5. I'm using the VX855 chipset, not CN896. You don't need a network stack to follow my instructions as provided, except to download packages and code to a flash drive on another, Internet-connected system that is not the target machine. All you need as far as the Wyse Cx0 is concerned are -- my instructions, a bootable drive with Puppy, and either a folder on that drive or a second drive containing current openchrome code, the "devx" for Puppy, and the additional packages that satisfy build deps. The Wyse client itself need never connect to a network for these purposes, and indeed mine has not yet done that in the time I've owned it. Nevertheless, as reported previously, I've ordered another WYSE Cx0 from eBay -- specifically, a C90LEW. I believe that the only changes in the design between C90LE and C90LEW relate to internal Disk-On-Module and RAM capacity when shipped... we will see what happens with that when it arrives. If it is my environment, I suspect I know what the issue is and replacing the client will fix that. At some point I replaced the thermal material under the heatsink with much better stuff, which is unfortunately somewhat conductive -- it could be a short there, or it could be the one single surface-mount passive I knocked off in the process of undoing one of the spring-pins for the heatsink. I did not previously report this damage, because the client operates 100% fine in every other respect that I have tested it with. Usually, in my experience, motherboard damage is either inconsequential or fatal. Nevertheless -- testing is the only way to know for sure; I will do the testing, since you've made it clear that you will not. Again -- I do appreciate all of what you've done. "It's been a long road, getting from there to here..." ;) and I honestly cannot thank you enough for all of the help you've given me. When I can next report back with a logfile, I will do so... until then I will probably be silent. It may be a week or two... but I'm not gone yet, I'm just resting ;) Hi Christopher, I don't know which port your issue is with. At my side, on Wyse C90LE platform, VGA port from DVI-I is working for OpenChrome UMS 0.4.0. I have verified it on Ubuntu 12.04 LTS. Thanks, Frank (In reply to Christopher from comment #319) > @ Jeffrey -- I've been proactive. I've been sidelined --only recently-- by > an issue related tangentially to this bug (install issues), and I'm working > actively with a member of the Puppy community to fix that. It's just not > fixed yet. > > @ Kevin -- > > I'm still confused, at least a little bit. I'm not blaming you for anything > at this point -- indeed, I'm very thankful for all you've done for me -- > except for this one somewhat frustrating bit of not doing what I've asked to > confirm whether it is indeed my environment or not. You insist -- but you > will not offer proof. I understand that you are frustrated. I can relate! > But I still need to know whether or not it's the environment for certain -- > and until that is tested, all we have is speculation and assumption. > > You've tested it on a different OS and a different chipset, and it works. > That's great. That's amazing. That's wonderful. > > But it's not my OS and it's not my hardware. > > I'm using a TahrPup 6.0.2 based Pup, not Tahr 6.0.5. I'm using the VX855 > chipset, not CN896. > > You don't need a network stack to follow my instructions as provided, except > to download packages and code to a flash drive on another, > Internet-connected system that is not the target machine. All you need as > far as the Wyse Cx0 is concerned are -- my instructions, a bootable drive > with Puppy, and either a folder on that drive or a second drive containing > current openchrome code, the "devx" for Puppy, and the additional packages > that satisfy build deps. The Wyse client itself need never connect to a > network for these purposes, and indeed mine has not yet done that in the > time I've owned it. > > Nevertheless, as reported previously, I've ordered another WYSE Cx0 from > eBay -- specifically, a C90LEW. I believe that the only changes in the > design between C90LE and C90LEW relate to internal Disk-On-Module and RAM > capacity when shipped... we will see what happens with that when it arrives. > > If it is my environment, I suspect I know what the issue is and replacing > the client will fix that. At some point I replaced the thermal material > under the heatsink with much better stuff, which is unfortunately somewhat > conductive -- it could be a short there, or it could be the one single > surface-mount passive I knocked off in the process of undoing one of the > spring-pins for the heatsink. I did not previously report this damage, > because the client operates 100% fine in every other respect that I have > tested it with. Usually, in my experience, motherboard damage is either > inconsequential or fatal. > > Nevertheless -- testing is the only way to know for sure; I will do the > testing, since you've made it clear that you will not. > > Again -- I do appreciate all of what you've done. "It's been a long road, > getting from there to here..." ;) and I honestly cannot thank you enough for > all of the help you've given me. > > When I can next report back with a logfile, I will do so... until then I > will probably be silent. It may be a week or two... but I'm not gone yet, > I'm just resting ;) By the way, I have verified OpenChrome UMS 0.4.0 driver on HP T510(VX900) platform. And on this platform, VGA from DVI-I port is working fine. So, to sum up, for OpenChrome UMS driver, both HP T510 and Wyse C90LE(VX855) platforms, VGA port from DVI-I is working. But DVI-D from DVI-I is not working. But for OpenChrome KMS driver plus DDX 0.4.0, DVI-D from DVI-I is working fine for HP T510 and Wyse C90LE. So I believe Kevin will fix DVI-D port issue for next step. And obviously KMS mode setting for DVI-D port is a good reference to fix this issue. Thanks, Frank Hi Frank Did you check T510 (VX900) VGA port from DVI-I using an LCD or CRT (tube) monitor ? Because I still can not get signal from T5550 using CRT monitor and I will file a new bug upon Kevin's suggestion. (In reply to Christopher from comment #319) Hi Christopher, > @ Jeffrey -- I've been proactive. I've been sidelined --only recently-- by > an issue related tangentially to this bug (install issues), and I'm working > actively with a member of the Puppy community to fix that. It's just not > fixed yet. > Yes, I strongly recommend that Puppy Linux incorporate OpenChrome Version 0.4.0 with Puppy Linux 5.7.1 (precise puppy) and 6.0.5 (tahrpup). If they still maintain it, they should also replace the OpenChrome that came with Ubuntu 10.04 LTS based Puppy Linux as well. OpenChrome Version 0.4.0 works fine with Ubuntu 10.04 LTS except Lubuntu 10.04 and CLE266, KM400, KM400A, KN400, and P4M800 (software cursor display bug). > @ Kevin -- > > I'm still confused, at least a little bit. I'm not blaming you for anything > at this point -- indeed, I'm very thankful for all you've done for me -- > except for this one somewhat frustrating bit of not doing what I've asked to > confirm whether it is indeed my environment or not. You insist -- but you > will not offer proof. I understand that you are frustrated. I can relate! > But I still need to know whether or not it's the environment for certain -- > and until that is tested, all we have is speculation and assumption. > If I have to, I can present proof that the OpenChrome Version 0.4.0 works with Puppy Linux 5.7.1. The "proof" was originally done for a pre-release version of OpenChrome Version 0.4.0, but I can retest it with OpenChrome Version 0.4.99 (I altered the version update policy within the past 24 hours.) I can upload the Xorg.0.log if I have to, and I probably have to spend time on this. I will explain to you shortly, but please remember that I have other bugs I have to fix other than your bug. > You've tested it on a different OS and a different chipset, and it works. > That's great. That's amazing. That's wonderful. > > But it's not my OS and it's not my hardware. > Yes, but from my own experience of being a developer for OpenChrome for several months already, to some extent, VIA Technologies IGP (Integrated Graphics Processor) display controller and 2D accelerator hardware apparently do not change that much from chipset to chipset. That makes sense; while people do not think very highly of their IGPs, it is still a very complex piece of digital hardware (i.e., multi-million gate ASIC, especially Chrome9). There is a fair amount of continuity in their designs (this is called "design reuse" in the ASIC design community), hence, if things work with one version, there is a good chance it will work with another close generation one. > I'm using a TahrPup 6.0.2 based Pup, not Tahr 6.0.5. I'm using the VX855 > chipset, not CN896. > P4M900 / VN896 / CN896 are apparently all related and VIA publicly called the IGP inside Chrome9 HC. I do not know what HC stands for. Chrome9 is supposedly a modern IGP that can obtain Windows Vista Basic logo from Microsoft (i.e., a marketing prerequisite for selling the chipset to PC and mainboard vendors since 2007). VX800 is a second product in the family of highly integrated chipset where traditional northbridge (CPU interface, memory controller, AGP / PCI Express controller, etc.) and southbridge (PCI, PCI Express, USB, PATA, SATA, ACPI, etc.) were integrated together along with a Chrome9 based IGP. The IGP inside VX800 was called Chrome9 HC3. Looking at the documents VIA has made public, it appears that VX855 is primarily an upgrade to their video playback engine compared to VX800 (i.e., H.264 support). What I am trying to say here is that, while CN896 and VX855 seem unrelated, they are generationally close. Also, while you may be mostly concerned of the Puppy Linux version number, the underlying graphics server is still X.org X Server. Even for X Server, they do try to preserve backward compatibility between versions as much as possible. As a result, based on my own testing of VIA hardware with OpenChrome, I have confirmed that OpenChrome Version 0.4.0 works fine with X Server Version 1.7 or later and Linux kernel 2.6.32 or later. Please note the "later" part. Because X.org tries to preserve backward compatibility as much as possible. it has been reported here and there that OpenChrome Version 0.4.0 appears to be working pretty well with various X Servers and Linux kernels (I hope it will work with BSD as well.). https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002177.html https://lists.freedesktop.org/archives/openchrome-users/2016-April/007260.html Arch Linux was the first Linux distribution to take in OpenChrome Version 0.4.0 after release, and apparently it is now in their "extra" repository along with stuff from Intel and Nouveau (reverse engineered open source NVIDIA graphics display driver). https://www.archlinux.org/packages/extra/i686/xf86-video-openchrome/ If you sort it by "Last Updated," you can see that other than the "Big 3" of x86 platform graphics, we are the other 2 actively maintained graphics device driver (the other is r128) based on the last updated date. https://www.archlinux.org/groups/i686/xorg-drivers/ What I am trying to say is that OpenChrome Version 0.4.0 has been tested fairly extensively already by many VIA silicon hardware owners (it has been available for only a week), and it is working fairly well for a release where I had to take some design risks (i.e., removing known device table, moving towards full automatic display detection, etc.). This, along with the fact that I spent some of my own money to buy Wyse C00X for testing purpose specifically because you really wanted this bug fixed, I do not think I will be the only one who might think that my effort is not being totally appreciated. Christopher, please remember that since November 2015, I probably spent the most time fixing your bug than fixing other bugs like standby mode resume bug with VIA IGP laptops I wanted to fix for myself and another person. There are other bugs other people want fixed. > You don't need a network stack to follow my instructions as provided, except > to download packages and code to a flash drive on another, > Internet-connected system that is not the target machine. All you need as > far as the Wyse Cx0 is concerned are -- my instructions, a bootable drive > with Puppy, and either a folder on that drive or a second drive containing > current openchrome code, the "devx" for Puppy, and the additional packages > that satisfy build deps. The Wyse client itself need never connect to a > network for these purposes, and indeed mine has not yet done that in the > time I've owned it. > Please remember that while Puppy Linux is a unique platform as far as Linux goes, it is also different in terms of GUI operation and network stack support compared to other Linux based OSes I have used in the past (i.e., Lubuntu, Xubuntu, etc.). As a developer, it is very draining to have to spend my own precious time figuring out how to operate the OS itself just to do some basic things like connecting to the Internet or copying files. What might be intuitive to you might not be intuitive to me as a first time Puppy Linux user. > Nevertheless, as reported previously, I've ordered another WYSE Cx0 from > eBay -- specifically, a C90LEW. I believe that the only changes in the > design between C90LE and C90LEW relate to internal Disk-On-Module and RAM > capacity when shipped... we will see what happens with that when it arrives. > I am sorry to hear that you need to spend more of your own precious money on validation when you have publicly mentioned that you could not really afford to. > If it is my environment, I suspect I know what the issue is and replacing > the client will fix that. At some point I replaced the thermal material > under the heatsink with much better stuff, which is unfortunately somewhat > conductive -- it could be a short there, or it could be the one single > surface-mount passive I knocked off in the process of undoing one of the > spring-pins for the heatsink. I did not previously report this damage, > because the client operates 100% fine in every other respect that I have > tested it with. Usually, in my experience, motherboard damage is either > inconsequential or fatal. > > Nevertheless -- testing is the only way to know for sure; I will do the > testing, since you've made it clear that you will not. > The only logical conclusion I can come up with after all the tests I have done and all the feedback I received from other people is that either 1) you are not compiling OpenChrome correctly, 2) you did not install OpenChrome correctly, 3) there is a bug in the particular Puppy Linux version you are using, or 4) hardware failure with your equipment. As far as my own testing is concerned, a DVI to VGA adapter is now working with Wyse C00X and Puppy Linux 5.7.1 with the latest OpenChrome. If you try Puppy Linux 5.7.1 with the latest OpenChrome, and it is working, then you will need to suspect hardware failure or a bug of Puppy Linux, not OpenChrome. I am not responsible for a Puppy Linux bug (in general), and you need to get their developers to deal with that. You sound like you are blaming me or OpenChrome code, and I prefer if you do not do this since I do perform quite a bit of testing using my own 10+ VIA silicon hardware equipment at my place. I fixed a regression that seems to have occurred 2 weeks prior to the Version 0.4.0 release (The one Xavier Bachelot appears to be making an issue out of it right now. I am not trying to criticize him here.), and all other known bugs are disclosed in the README file that came with the release (I will post this on the mailing list soon.). Theoretically, I can do what I proposed in the past with Puppy Linux 6.0.x. I can compile OpenChrome using an older version of Lubuntu 14.04 (Canonical did a kernel upgrade to Linux 4.2 kernel from 3.13 or 3.14 it used in the past. Puppy Linux 6.0.5 uses Linux 3.14 kernel, so I should probably stick with an older kernel.), and then copy the compiled OpenChrome to Puppy Linux 6.0.x. I will need to find some time to do this, but if OpenChrome works with this configuration, then I just wasted my time trying to prove something I did not really wanted to spend my time on. > Again -- I do appreciate all of what you've done. "It's been a long road, > getting from there to here..." ;) and I honestly cannot thank you enough for > all of the help you've given me. > > When I can next report back with a logfile, I will do so... until then I > will probably be silent. It may be a week or two... but I'm not gone yet, > I'm just resting ;) Yes, from now on, please upload Xorg.0.log after you conduct your own test. I no longer will take "it didn't work" alone as a valid answer considering that I consider this bug technologically closed. Again, many users are now reporting that DVI to VGA is working, and I, myself, has seen that OpenChrome works with VX855 chipset. I am repeating myself again, but in the long run, you need to get Puppy Linux developers to replace old OpenChrome with the latest one. OpenChrome Version 0.3.3 has so many problems that it needs to be retired for good. I will still devote some of my time on your bug from time to time (i.e., I will not ignore your bug report or you.), but I will need to reduce my time resources dedicated to your bug since I have many more pressing issues I need to work on, and from a technological perspective, the bug was fix with the release of OpenChrome Version 0.4.0. External TMDS transmitter (DVI) support is planned for the next release of OpenChrome. It will likely be called Version 0.5.0 since I just adopted X.org version numbering scheme. (In reply to John Friend from comment #322) Hi John, > Hi Frank > Did you check T510 (VX900) VGA port from DVI-I using an LCD or CRT (tube) > monitor ? Because I still can not get signal from T5550 using CRT monitor > and I will file a new bug upon Kevin's suggestion. Thank you very much for filing the report, and I will start analyzing what I can do over there. (In reply to HuangRan from comment #321) Hi Frank, > By the way, I have verified OpenChrome UMS 0.4.0 driver on HP T510(VX900) > platform. And on this platform, VGA from DVI-I port is working fine. > > So, to sum up, for OpenChrome UMS driver, both HP T510 and Wyse > C90LE(VX855) platforms, VGA port from DVI-I is working. But DVI-D from DVI-I > is not working. > > But for OpenChrome KMS driver plus DDX 0.4.0, DVI-D from DVI-I is working > fine for HP T510 and Wyse C90LE. > > So I believe Kevin will fix DVI-D port issue for next step. And obviously > KMS mode setting for DVI-D port is a good reference to fix this issue. > > > Thanks, > Frank I am glad VGA from DVI to VGA adapter is working with at least one VX900 chipset HP thin client. I will elaborate more on that matter over at John's bug report. (In reply to John Friend from comment #322) > Hi Frank > Did you check T510 (VX900) VGA port from DVI-I using an LCD or CRT (tube) > monitor ? Because I still can not get signal from T5550 using CRT monitor > and I will file a new bug upon Kevin's suggestion. Hi John, Yup. T510 VGA port from DVI-I is working for 0.4.0 UMS driver. I replied with you more detail on your 94863 thread. Thanks, Frank (In reply to HuangRan from comment #326) Hi Frank What I mean was if you tested it only with LCD or did you have opportunity to test it with crt monitor too. (I will also reply your and Kevin's messages at Bug 94863. If you mind, lets continue VX900 discussions there.) (In reply to John Friend from comment #327) > (In reply to HuangRan from comment #326) > > Hi Frank > What I mean was if you tested it only with LCD or did you have opportunity > to test it with crt monitor too. (I will also reply your and Kevin's > messages at Bug 94863. If you mind, lets continue VX900 discussions there.) Hi John, I am sorry that at my hand, only several LCD monitors are present for me to test. So currently I have no chance to test old crt monitor with my T510 platform. Yup, let's discuss on your new thread 94863. Thanks, Frank This will probably be my last comment here -- at least, I hope, for a very long time ;) A very nice fellow, Eric Kudzin, contacted me off-list and offered me a free Wyse client to replace my current one. Having done that, I discovered that my SD-to-IDE adapter was not functioning -- I had somehow been sent a faulty one by the eBay seller. A local friend of mine, who also happens to run the town's tech shop, kindly lended me an older SD-to-IDE adapter. Although I'm still having problems with grub4dos, that is an issue for them and not here ;) and extlinux works just fine. I can, today, report honestly for the first time that the current Git version of OpenChrome runs successfully on my Wyse Cx0. I'm staring at the X-Tahr 1b3 desktop right now, as thrown from that system onto my HP vs17c monitor, and I will tell you right now that looking at that screen gives me a good feeling indeed! I will note that the new client is marked as a Wyse C00X, rather than a C90LE -- but the motherboard inside, as I suspected it would be, is 100% identical to that of the C90LE. Thank you, Kevin. Thank you, Xavier. Thank you, Eric. For that matter -- thank you to /everyone/ who has contributed to this bug being fixed, be it through writing code or testing or reporting or anything. I am a happy fellow to be able to finally mark this as RESOLVED/FIXED. As I said before -- this is a good feeling indeed ;) (In reply to Christopher from comment #329) Hi Christopher, > This will probably be my last comment here -- at least, I hope, for a very > long time ;) > > A very nice fellow, Eric Kudzin, contacted me off-list and offered me a free > Wyse client to replace my current one. Having done that, I discovered that > my SD-to-IDE adapter was not functioning -- I had somehow been sent a faulty > one by the eBay seller. > > A local friend of mine, who also happens to run the town's tech shop, kindly > lended me an older SD-to-IDE adapter. Although I'm still having problems > with grub4dos, that is an issue for them and not here ;) and extlinux works > just fine. > > I can, today, report honestly for the first time that the current Git > version of OpenChrome runs successfully on my Wyse Cx0. I'm staring at the > X-Tahr 1b3 desktop right now, as thrown from that system onto my HP vs17c > monitor, and I will tell you right now that looking at that screen gives me > a good feeling indeed! > > I will note that the new client is marked as a Wyse C00X, rather than a > C90LE -- but the motherboard inside, as I suspected it would be, is 100% > identical to that of the C90LE. > > Thank you, Kevin. Thank you, Xavier. Thank you, Eric. For that matter -- > thank you to /everyone/ who has contributed to this bug being fixed, be it > through writing code or testing or reporting or anything. > > I am a happy fellow to be able to finally mark this as RESOLVED/FIXED. As I > said before -- this is a good feeling indeed ;) I had a hunch that this was your PATA to SD card problem, not OpenChrome Version 0.4.0 or later problem since I got Puppy Linux 5.7.1 and OpenChrome Version 0.4.0 working with my own Wyse C00X (it cost me $20 to obtain one, but I do not mind a small amount like this). Plus, the code was working with Ubuntu 10.04 LTS all the way to 14.04 LTS. I am glad that you were able to see yourself that the code was fixed some time ago. Although this is not crucial to you, I still plan to fix the code path that initializes VT1632A TMDS transmitter for DVI display output. I still have not figured out the exact cause of why it does not work with VX855 chipset, and this is the reason I still have not committed the changes to repository yet. When I see some good results, I will make code commits. I am still not a fan of Puppy Linux, but I will keep a copy in one of my USB flash memory sticks for testing purposes. While trying to install Slacko 6.3.2 on an Igel thin client, I ran into the same problem: black screen with only a cursor. Hardware details: Igel D210 with 1GB RAM and 1GB compact flash drive Monitor: Philips Brilliance 150P2, 15" LCD monitor (1024*768), connected via DVI. Running lspci shows the "VX855/VX875 Chrome 9 HCM integrated Graphics" detected. The logfile Xorg.0.log (from Xorgwizard) contains: " [ 1558.284] (==) CHROME(0): LVDS-0 : DVI Center is disabled. [ 1558.285] (==) CHROME(0): LVDS Panel will not be forced. [ 1558.285] (==) CHROME(0): Panel size is not selected from config file. [ 1558.285] (II) CHROME(0): Output VGA-1 using monitor section Monitor0 " (In reply to Igeluser from comment #331) > While trying to install Slacko 6.3.2 on an Igel thin client, I ran into the > same problem: black screen with only a cursor. > > Hardware details: > > Igel D210 with 1GB RAM and 1GB compact flash drive > > Monitor: Philips Brilliance 150P2, 15" LCD monitor (1024*768), > connected via DVI. > > Running lspci shows the "VX855/VX875 Chrome 9 HCM integrated Graphics" > detected. > > The logfile Xorg.0.log (from Xorgwizard) contains: > > " > [ 1558.284] (==) CHROME(0): LVDS-0 : DVI Center is disabled. > [ 1558.285] (==) CHROME(0): LVDS Panel will not be forced. > [ 1558.285] (==) CHROME(0): Panel size is not selected from config file. > [ 1558.285] (II) CHROME(0): Output VGA-1 using monitor section Monitor0 > " Since this case was closed, please open a new case. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I have a WYSE C90LE (a member of the WYSE Cx0 series) 'thin client' that I am booting Puppy Linux off of using a USB stick. I am using the second-most-recent version of the most recently released official Puppy, namely TahrPup 6.0.2 -- it is made with, and is (generally) compatible with, packages from Ubuntu 14.04 LTS Trusty Tahr. The WYSE system in question has two gigs of RAM (a single DDR2 SODIMM) and a VIA Eden 1GHz CPU. Chipset is VX855 and there are no expansion slots such as PCI/PCIe or PCMCIA/CardBus/ExpressCard or similar. (Nor is there room for them; the computer is quite literally the size of a common paperback novel!) If I had a USB2 graphics card I could use that... I don't think such things exist, though. The system has a DVI-I port for combined VGA and DVI output (more on that in a few paragraphs). Detailed information about the hardware can be found here --> parkytowers.me.uk/thin/wyse/cx0/index.shtml Puppy uses a text-mode boot (I'm not sure if it's framebuffered or not, honestly) and works a customized xorgwizard setup system to generate /etc/X11/xorg.conf and then start X. When X starts on my hardware, the screen I'm using (VGA connection, see below for DVI behavior) actually goes into power-save mode. No signal, as far as I can tell, is actually sent to the monitor. The screen turns black, shuts off, and the little green power LED turns amber. Screen in question is a known-good Dell 17" LCD that has a native 1280x1024 resolution. I don't know how relevant this is, but if I use the 'modesetting' or 'vesa' drivers, the symptom is the same, except that additionally the system freezes upon attempting to return to text mode. Puppy defaults to the assumption that 24-bit color is able to be put out by the graphics system; manually correcting this in /etc/X11/xorg.conf to 15, 16, or even 8 bits, however, does not affect the result. Nor does dropping the resolution. I have tried 640x480, 800x600, and 1024x768; it will not function. I have also turned DRI off, as well as GLX -- Option "DRI" "off" [and] Option "GLX" "disable" -- it still does not work. If I use the DVI output, and a passive ("just wires") DVI->HDMI adapter, with my really nice Dell ST2010 monitor, the behavior is subtly different. The screen does not go into power save / no signal mode, but rather an unblinking underscore-for-a-cursor presents itself with no further action occurring. If I press CTRL+ALT+BKSP within about five seconds of seeing that cursor, I can get back to text mode. After that, the system is hung and must be shut off by way of holding down the power button, or by way of unplugging the cord from the rear of the system. I believe that the time limit is the same for VGA -- but I don't recall at the moment if I've tested that, so don't hold me to it on that one... I compiled the openchrome driver myself as well, just to eliminate the issue of a failed/damaged compile at the time Puppy was made, or a very slightly doofy download of the ISO. This was my first time compiling a driver, and my third or fourth time compiling *anything at all*. It was also my second success, although it took me four tries (I was missing deps for each of the first three). Results were identical. Running X --configure in text mode, results in a segfault in all cases. I can post my config.log from compilation, if that's anything noteworthy; I'm afraid I didn't create a log when I ran 'make' on that configuration and I've since discarded everything but the *.so and *.la produced in that effort. I can also post an xerrs.log and an Xorg.0.log, if you want me to generate those. ...I will also note that the same USB drive with the same install of the same OS and the same driver, boots fine on a different thin client, an HP t5630w that contains a VX800 chipset. A lot must've changed with those two digits... I'm happy to test whatever you guys want to throw at me by way of patches, but if it involves compilation, I'm going to need dummy instructions -- when it comes to that stuff, I really *am* a dummy!