https://bugs.freedesktop.org/show_bug.cgi?id=91966
Bug ID: 91966 Summary: No signal to monitor with X and openchrome using VX855 chipset graphics Product: xorg Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/openchrome Assignee: openchrome-devel@lists.freedesktop.org Reporter: laserhaw...@gmail.com 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! -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Openchrome-devel mailing list Openchrome-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/openchrome-devel