The distro is Dragora 2, which is the first completely libre distro I have used. My video chip is a Via 9chrome and X uses openchrome to run it. It seems fine except for the absence of dri (which I don't really need as I don't do demanding things like game play). But I have the following problem:

I can switch out of X to a virtual console. I can switch between virtual consoles. But I can't switch from a virtual console to X. When I try, the screen goes black and the keyboard seems to lock up. I've tried ctrl-alt-Fn, ctrl-alt-del and sysreq-reisub; nothing works and I have to switch off manually.

Well that is a nuisance but I can live with it. You don't have to use VCs after all; you can always use XTerms instead. What is much more serious is that it makes suspending impossible. When I resume from suspend, I initially get some printout from the system console. Then it tries to switch back into X and triggers this bug.

I suspect that it's a video driver problem; nvidia chips are known to do this kind of thing. But with nvidia, you can install a proprietary driver that behaves better. Via has a proprietary driver called via-agp, but they don't seem to do a Linux version any more, though they definitely used to.

Has anyone else got this to work on a Samsung?

i subscribed to this thread a while ago, but didn't use LQ for... over a week.
sorry to see you didn't seem to get anywhere with this.
all i can say is that via video chips (that's SiS, right?) are bad news for linux and the openchrome driver i think is one of those retro-engineered affairs, and development is probably zero these days

anyhow, a belated welcome to LQ!

If anyone wants to know how this ended, here is the saga of my attempts to find an alternative driver to openchrome:

1) Vesa. This causes the X server to segfault. I have no idea why.

2) fbdev. This doesn't cause a crash, but the screen becomes covered with a crazy patchwork of colours. Virtual consoles become unusable too. The only escape is to reboot.

3) Proprietary driver. Via used to produce one of these, but haven't updated it for years. The versions I found were all binary (and 32-bit at that). Even if the architecture had been right for my system, they would only have worked with the X server they were built against.

So it looks like I'm stuck with openchrome which, apart from this bug, works just fine.

Hallelujah! I found a more up-to-date version of Openchrome (0.4) and built it. At first I didn't see any difference because it had gone into /usr/lib/xorg/modules/drivers, and Dragora uses /usr/lib64/xorg/modules/drivers. So I was still actually using the old buggy driver. But when I twigged that and put the new version where it should be, the bug was gone!

congrats!
mind posting the source, and maybe some tips for compiling?
others might benefit.
it (sheeety via gpus & openchrome) does come up every now and then.

There's a repository of xorg drivers (both input and video) at http://ftp.x.org/pub/individual/drivers, with multiple versions. Some other drivers that I tested came from that site too. The good version of openchrome is xf86-video-openchrome-0.4.0. It's only just come out.

When configuring it, I used "--prefix=/usr", which I always do for libraries because /usr/lib is where programs expect to find them. But for Dragora, which has separate /usr/lib and /usr/lib64, I should have used "--libdir=/usr/lib64" as well. I didn't, so I had to move some files about afterwards.

You learn by doing, don't you!

wot!
still in development! i thought the hardware was obsolete.

anyhow, thanks on behalf of whoever.