Frequently asked questions:

General

Where do I complain?

On the unichrome-users mailing list mainly. Logs are useful, but be sure to gzip/bzip2 your logs before mailing them though.

Why isn't my hardware supported?

Driver development depends heavily on the availability of hardware to the relevant developers. It requires extensive testing, not only at the time of initial development, but also later on, when reworking and/or debugging.

After many extensive and expansive remote hacking sessions, be it over mail, irc or ssh, it has become clear that this is far from the most effective method of development. If you depend on others to test for you, you end up spending most of your time waiting.

This might seem very asocial, but those that were on the receiving end of the above will only acknowledge the mutual pain it incurs. Working remotely is acceptable for debugging and fixing, but not for reworking or implementing major parts of a driver. Those claiming differently have never done it.

Also, after a certain level of usability has been reached, people are no longer so keen on spending time testing your code. So, without direct access to hardware, fundamental changes become almost impossible. This type of driver stagnation is the root of most of today's problems with X.

So, if your hardware isn't supported, then that isn't so because I am being obnoxious, but because I don't have the resources to support your hardware in an acceptable manner.

So what hardware is supported?

The hardware I currently own is the following:
• VIA EPIA-M10000: VT3122A (rev 3) with a VT1622 TV encoder.
• VIA EPIA-M10000: VT3122C (rev 18) with a VT1622 TV encoder and LVDS port. (provided by ONELAN).
• Asus A7V400-MX: plain VT7205A (not a testbox, so used 24/7).
• Shuttle SK43G: VT7205A with a CH7011 TV encoder.
• Mitac 8889: VT3108 with 1024x768 TTL panel and VT1623 TV encoder. This is, sadly, not an AMD-64 machine.
This defines the boundaries within which I, as a driver developer, can move. You might get lucky with different combinations of hardware, but I can't provide any solid assurance. If it is close enough, then it might just work or you might want to try complaining :) (see top of page).

How do I use the git repository?

Once you have git installed, you can just run:

> git-clone git://people.freedesktop.org/~libv/xf86-video-unichrome/

This gets you a fully working repository in xf86-video-unichrome/ from which you can build and install your driver.

Later on, when you want to update your tree, you just run:

> git-pull

And your tree will be updated to the latest changes.

If you want to browse the repository you can go to gitweb.freedesktop.org. If you want to browse your local repository, you can just run gitk locally.

For more information on git, check out the main git site.

I use your code, what can I do to help?

Use it! Test it! Complain about it! But be prepared to ride issues out all the way.

If you have code, stick the patches up the tracker or git-send-email them.

If you are using this software commercially, you should consider supporting development. Contact me to find out what I can do for you.

Building

How do I build this code?

There is a README in the tarball/git-repository explaining the basic steps needed.

Where are the packages for my distribution?

Sorry, it is an insane task to provide a package for each and every distribution myself. It is also possible to build the driver against XFree86 4.3 through 4.6 and Xorg versions 6.7 through 7.1. With modular Xorg, it has become very easy to compile this driver yourself, and I will be providing an easier route still for the next unichrome release.

Modesetting

I need a weird mode!

Sure!

In stark contrast to any of VIA's code, this driver can handle any mode you feed it. That is, as long as the memory bandwidth is available, and your CRT supports it.

My panel acts up!

NOTE: if your panel is connected to the analog CRT connection, then, from a driver's point of view, it is just a CRT.

This is a well known problem. I don't have access to VT3122 and VT7205 with panels, and am therefor forced to keep the code relatively untouched. There is not much I can do to fix it currently, except hack around the problem.

On VT3108, your panel should work, albeit without scaling. You can have any mode smaller than native resolution as a centered mode, if the right modeline is provided. When dual-head is tackled, you will get scaling.

I need dual-head!

So do I!

This is a big TODO which i hope to be tackling soon. This is only a driver limitation though, although X needs a lot of work too.

When I use the panel, I can't use the TV!

The timing needed for PAL and NTSC modes are highly specific and usually it is not possible to drive the panel with the same timing. In order to drive them both, dual-head support is needed.

My CRT blanks out when I use the panel or the TV encoder.

The timing of your CRT might not be compatible with the timing of your panel or TV encoder, and the driver has wisely chosen to disable your CRT. The log will contain a (WW) about this. This will get fixed once dual-head support is implemented.

When I use the TV, my CRT runs at 50 or 60Hz only!

You need dual-head.

My TV encoder doesn't accept my modeline!

Currently, the TV encoders only support a limited set of driver-provided modes, the names of which are listed in the manpage. This is often a hardware limitation (of the TV encoder, not the unichrome), but here it is partly a driver limitation. When dynamic configuration is exposed to the user, comprehensive configuration of supported TV encoders will be possible too.

X-Video

Where is XvMC?

Gone.

The current X-side XvMC implementation is a bit of a hack on top of Xv.

The driver-side XvMC implementation that used to be here was an extension of that hack and didn't implement MC nor iDCT, even though the hardware support is available. Instead it implemented the slice decoder, which requires a properly formatted MPEG-2 data stream to function.

What use is this driver without XvMC?

What use is an XvMC implementation that fully depends on an opaque and nasty Xv implementation that has barely seen any clean-up since VIA's original code drop? A house is only as solid as its foundations.

Xv has been almost completely rewritten here. This was quite a gruesome job, but the end result was very much worth it. The unichrome's Xv implementation is clean, highly maintainable and highly debuggable. It is very efficient in both CPU and memory usage.

To showcase the new-found extensibility of this clean code, the unichrome's HW-overlay alpha plane was implemented.

Translucency with an Xv overlay?

All unichromes support a 4-bit alpha plane for their overlay. Due to some hardware issues this isn't always as efficient as it could be, but this is relatively cheap and easy bling.

The current implementation can have all windows on top of the HW overlay show the video translucently. This only requires you to set the XV_OPACITY attribute, and is directly usable on all X versions.

Setting XV_OPACITY.

XV_OPACITY controls the translucency of the top windows. Since it's only 4-bit, the range is from 0 to 15 with 0 a solid window and 15 a solid overlay. A value of 0 disables translucency and re-enables normal colorkey handling.

xvattr can be used to set XV_OPACITY. This utility is not part of X or of most distributions, and will have to be built from source.

Usage:

> xvattr -a XV_OPACITY -v 6

What can I do to reduce Xv CPU usage?

The driver-side Xv implementation is as clean and efficient as it can be. The most CPU-intensive is copying the buffer created by the Xv Client to the framebuffer, and here it is handled by a single memcpy of the whole Xv buffer in one go.

The driver does support Thomas Hellstrom's DMA copy. If a recent drm driver (at least 2.7.5) is loaded, the burden of copying to the FB is largely removed.

To find out whether this is enabled, check the drm initialisation in your X log.

My HW overlay doesn't uncover properly!

This isn't a driver issue, this is an X-side issue. See the X.org bugzilla. X doesn't send an uncover event to the overlay when adjusting the frame back over the Xv window (when using virtual modes). If your Xv client is actively sending PutImages or if you move or resize the window, the problem is (temporarily) remedied.

Xine and autopainted colorkey don't play ball!

Indeed they don't. Blame xine-ui for allowing you to select autopaint.