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

[bugzilla-daemon at freedesktop.org]

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

            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 at lists.freedesktop.org
          Reporter: laserhawk64 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openchrome-devel/attachments/20150910/4ceb1e53/attachment.html>