Archive

Posts Tagged ‘xwindows’

nVidia Overscan Correction fixed in Latest Drivers

April 1st, 2010

My solution for fixing overscan on nvidia cards is obsolete! I did find out just a few days ago that my solution does actually work.

The person that I was originally helping with this problem decided to give Linux another shot. He tested it out and reported that it did indeed fix his overscan problems.

However… for no particular reason I decided to check out the nVidia settings control panel again. When I opened it up in Ubuntu 10.04, I noticed this (and tested it to make sure it works, which it does):

Screenshot-NVIDIA X Server Settings

General , , ,

DVI to HDMI overscan (screen edge cutoff) on an HDTV

July 3rd, 2009

Update – 4/1/2010: Latest nVidia drivers have overscan correction built in

Well I learned something new recently. I have a friend that’s making the Ubuntu switch and he called me up with a bizarre problem. He’s using an nVidia card (although other cards have the same issue) with a DVI out port to a DVI->HDMI converter to an HDMI input on a 26″ HDTV that he uses as a monitor.

He called me up and described the problem and I confessed that I had never heard of this before. All 4 sides of his sides of his screen were getting cut off. He could only see part of his menu bars at the top and bottom and the left/right edges were cut off as well. After some Googling, I at least found the name for the problem: overscan.

And once I figured out the name, that’s when my Google searches became eye openers. There are a lot of people out there with overscan problems and there are very few solutions in Linux. The Windows nVidia drivers allow dynamic overscan correction inside of their driver toolbox. The X server nVidia drivers have no options (for DVI out… for TV out there apparently are).

The problem, as I understand it, is that the PC is sending a DVI PC style output, but the TV is reading a HDMI TV style input. As such, the TV thinks it’s receiving a TV signal and acts accordingly. If your TV has a DVI input, it should treat that as a PC input and give you 1:1 pixel mapping (which is what you’re looking for). If not, you’ll need to adjust for the overscan on the PC side. Some TVs even have an option to treat an HDMI signal as if it were PC. Check your TV’s manual.

Anyhow, there are a lot of people asking for help for this issue but is very hard to find any actual information.

Option 1 – Manually

I don’t know if this works, but it looks like good info. If you’re looking for a way to fix this (and you’re ready to spend quite a while doing it), you should read this:

Ubuntu Forums: Nvidia, Modelines, Overscan…8.10

Basically it’s trial and error to get the correct X server config’s Modeline. It’s mindboggling that no one (especially nVidia, which seems to care about Linux a little bit) has put out any definitive information on this topic.

Option 2 – A little less manually

I definitely don’t know if this works. I don’t know if anyone has even tried it. If this works/doesn’t work for you, post in the comments.

You can see if the Xfree modeline generator will give you something that works. I don’t really understand what all the modeline timings mean, but here’s a shot in the dark (You’re probably desparate at this point anyway… and I have no way of testing this so I don’t know if it even works at all). Also, I’ll give the same warning everyone gives on this… I take no responsibility at all of this damages your television. Try this at your own risk.

First things first, back up your xorg.conf file (/etc/X11/xorg.conf) somewhere safe (like your home directory).

I wrote a quick program that will help you determine your visible screen size:

Source: findcoords.c (source)
Binary: findcoords (compiled on Ubuntu 9.04)

If the binary doesn’t work for you or you’d prefer to compile from source, you’ll need the libx11 development packages installed (as well as the standard stuff like gcc and whatnot). On Ubuntu, running “sudo apt-get install build-essentials libx11-dev” should do the trick. To compile it run: gcc -lX11 -o findcoords findcoords.c

Now run it by typing ./findcoords

It’ll tell you to click the upper left and bottom right corners of the screen. Get as close as possible. You want the very point of the cursor as close to the edge as possible. That means in the bottom right, you should only be able to see about 1 pixel of your cursor. When you’ve done that it’ll calculate your viewable screen size. It will output something like this:

Root Window Size: 2880x900
Viewable Size: 2764x798
Your screen is cut off by the following number of pixels:
Left  : 31
Right : 85
Top   : 24
Bottom: 78

Armed with the actual visible screen size, head over to the XFree Modeline Calculator (it works for Xorg too).

1. Enter the values under “Monitor Configuration” if you know them. If not leave that section blank.
2. Under “Basic Configuration” enter the viewable size that got output from findcoords.
3. If you know the max refresh rate for your TV, you can enter it here. If not, just use 60Hz.
4. If you know the dot clock frequency enter it as well, otherwise, just leave it blank.
5. IMPORTANT: If you’re TV is interlaced at max resolution (i.e. 1080i), check the interlaced button.
6. Click the “Calculate Modeline” button and it should give you a modeline at the top of the screen.
7. In your xorg.conf file, put the modeline it gives you into the Monitor section
8. And this line to your Monitor section as well:

Option "ExactModeTimingsDVI" "TRUE"

9. Now, to use this, you’ll need to add this line to your Device section:

Option "UseEDID" "FALSE"

10. Then in the Display section, add a line that LOOKS like this, but define the mode specified in the modeline that the generator gave you:

Modes "1960x1080@60i"

In other words, if the modeline generator spit out:

Modeline "1816x980@60i" 65.89 1816 1848 2096 2128 980 1002 1008 1031 interlace

You would put the following in the Display section:

Modes "1816x980@60i"

That text has to match EXACTLY. When it’s all said and done, you should end up with an xorg.conf that looks something like this:

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL S199WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 75.0
    Option         "ExactModeTimingsDVI" "TRUE"
    Modeline "1816x980@60i" 65.89 1816 1848 2096 2128 980 1002 1008 1031 interlace
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 9800 GT"
    Option         "UseEDID" "FALSE"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes       "1816x980@60i"
    EndSubSection
EndSection

Give that a shot and see what you get. Can’t be much worse, can it? If it doesn’t work, just revert back to what you had by replacing your xorg.conf file from the backup. If you get any halfway decent results at all, let me know.

More terms to know:

1-to-1 pixel mapping: If your HDTV (as a monitor) supports this option, chances are this will solve your problem. This means that every pixel sent by the PC will be mapped to a pixel on the screen (i.e. disable overscan).

Full Pixel: This is the same as 1:1 pixel mapping

Modelines: Definitions of video modes that control the display size in the X server

Overscan: Part of standard TV input where a percentage of the edges of the screen are cut off. Not noticeable for normal TV viewing, but very noticeable on a PC desktop.

EDID: Monitor/TV device information telling the PC what modes are supported (stored in the monitor and not configurable)

Good luck.

General , , ,

Detecting Xlib’s Keyboard Auto-repeat Functionality (and how to fix it)

June 23rd, 2009

If you’ve ever messed around with listening for XWindows keyboard events, you may have noticed something that’s odd. XWindows has a very strange way of dealing with keyboard auto-repeating. Let’s take a scenario:

Hold down the “h” key on the keyboard for a few seconds and you’ll get something that looks like this:

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Now, if you try this and watch carefully, you’ll notice a couple of things. The first thing to notice, is that after the first character, there is a slight delay before it starts repeating. That delay is about a half of a second. After that initial delay, it repeats every 30ms. These delays are configurable in X. It may be somewhere in your window manager control panel, but the xset command will tell you everything you need to know:

$ xset q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  auto repeat delay:  500    repeat rate:  30
  auto repeating keys:  00fffffffffffbbf
                        fbdfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff

Now, when you grab the keyboard in X using XGrabKeyboard or XGrabKey (so you’ll get the keyboard events), something strange happens with all those h’s. When holding down a key, you would at first expect to see 2 events. The KeyPress event and the KeyRelease event. But in order for auto-repeat to work, there must be more. For each auto-repeating character, you should get an additional KeyPress event. This solves the auto-repeat problem, because you can write some simple code that can easily detect auto-repeat and ignore it if you just care if the user is holding down a key.
Read more…

General , , ,