http://www.technologicalwanderings.co.uk/taxonomy/term/23 en http://www.technologicalwanderings.co.uk/node/13 <div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Keywords:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/21">x11</a></div><div class="field-item odd"><a href="/taxonomy/term/22">xorg</a></div><div class="field-item even"><a href="/taxonomy/term/23">carpc</a></div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Recently my car PC display started playing up. I couldn't get it to display the native 800x480, although more usual resolutions like 800x600 were working okay (just unreadably small or blurry on a 7" screen in a car!).</p> <p>To cut three weeks short, it appears that Mandriva (2008.0) started listening to the TFT's DDC information - the codes that tell the PC what resolutions the monitor supports. Now it turns out that the CTF700 I have never reports the correct resolution. It reports either 800x600 or 640x480, so Xorg thought it was doing the correct thing.</p> <p>The answer is to turn off DDC in Xorg and set the resolutions manually (or, in my case restore the previously working backup and change that so DDC is ignored).</p> <p>To do this, add:<br /><code><br /> Option "NoDDCValue"<br /></code><br /> to the Device section of /etc/X11/xorg.conf.</p> <p>I actually stumbled on this by looking at the old Via Unichrome driver notes. It does seem quite obvious now I think about the symptoms... I suppose some update I did in December changed something, although Mandriva 2008.0 is still not yet running 100% correctly - the last to work well was 2006.0, but that had poor wireless support for anything but WEP.</p> <p>The last issue I'm trying to sort now is a kernel bug - on each suspend/resume, the event drivers aren't being released properly and continue to count up in /dev/input/eventNN / inputNN. This eventually causes evdev (for the touchscreen) to fail (all slots taken, leaving the machine unusable. The heavy-handed fix I've got for this is to check for my custom udev generated symlink /etc/input/touchscreen every five minutes, and if it's missing to reboot the machine. Hardly the best thing to do.</p> <p>The evdev problem looks like this, notice the high input number, which was normally less than ten:</p> <p><code><br /> Jan 1 17:08:51 localhost kernel: evdev: no more free evdev devices<br /> Jan 1 17:08:51 localhost kernel: input: failed to attach handler evdev to device input72, error: -23<br /></code></p> </div></div></div> Sun, 06 Jan 2008 17:12:55 +0000 techuser 13 at http://www.technologicalwanderings.co.uk http://www.technologicalwanderings.co.uk/node/13#comments