Xorg modelines and Xv

[byuu]

Seems there's a fun new bug or something with Xorg ...

I start things up on my 22" LCD flatpanel (LCM-22w2) and get 1400x1050, and not 1680x1050. Great, black bars on the side of the monitor. Ok, add a custom modeline.

All the online generators are for CRT monitors, but I finally track down a good, clear modeline:

Code: Select all

Modeline "1680x1050"  146.36  1680 1784 1960 2240  1050 1053 1059 1089

(ref: http://leaf.dragonflybsd.org/mailarchiv ... 00089.html)

Seems to work fine, close to 60hz as I can get. But now, anything using Xv (X video extension) fails to work. When attempting to call XGetGeometry or XShmPutImage, the program crashes with:

Code: Select all

X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  140 (XVideo)
  Minor opcode of failed request:  19 ()
  Serial number of failed request:  117
  Current serial number in output stream:  118

Remove the modeline and go back to 1400x1050 and everything works fine.

xorg.0.log:

Code: Select all

(II) LoadModule: "i2c"
(II) Loading /usr/X11R6/lib/modules/libi2c.so
(II) Module i2c: vendor="X.Org Foundation"
	compiled for 6.9.0, module version = 1.2.0
	ABI class: X.Org Video Driver, version 0.8
...
(II) NV(0): I2C bus "DDC" initialized.
(II) NV(0): Probing for analog device on output A...
(--) NV(0):   ...can't find one
(II) NV(0): Probing for analog device on output B...
(--) NV(0):   ...found one
(II) NV(0): Probing for EDID on I2C bus A...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(II) NV(0):   ... none found
(II) NV(0): Probing for EDID on I2C bus B...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(II) NV(0):   ... none found
(--) NV(0): CRTC 0 is currently programmed for DFP
(II) NV(0): Using DFP on CRTC 0
(--) NV(0): Panel size is 1680 x 1050
(II) NV(0): Panel is TMDS
(--) NV(0): VideoRAM: 131072 kBytes
(==) NV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) NV(0): My Monitor: Using hsync range of 31.50-82.00 kHz
(II) NV(0): My Monitor: Using vrefresh range of 50.00-100.00 Hz
(II) NV(0): Clock range:  12.00 to 400.00 MHz

Without the modeline, I get:

Code: Select all

(II) NV(0): Not using mode "1680x1050" (no mode of this name)

I didn't have this problem on FreeBSD-6.1, it seems to be something new. Ideas are very welcome. I basically have no way of doing hardware accelerated scaling without Xv (which I depserately need), and I really don't see myself continuing to use BSD if I can't even run at my native monitor resolution.

[funkyass]

install the nvidia drivers

the NV driver dosesn't provide any hardware acceleration.

Also, I don't think that version of X.org had support for the 7xxx series.

[byuu]

install the nvidia drivers

the NV driver dosesn't provide any hardware acceleration.

Also, I don't think that version of X.org had support for the 7xxx series.

There is no FreeBSD-amd64 driver. They've been "working on it" for the last three years, and claim the FreeBSD authors need to add tons of extra memory mapping features to the kernel for it to be possible. The FreeBSD developers have even obliged nVidia and added their requests, nVidia then says the features aren't mature enough for their liking. Magically, ATI and Intel didn't have problems making accelerated amd64 drivers; nor did nVidia on other platforms. The obvious reality is that FreeBSD is a niche of a niche, and nVidia just doesn't give a shit about such a small number of customers.

The nv driver provides 2D acceleration, which is more than enough for me. I don't have any intentions of running 3D games.

I'm using a 6600 LE card, and nv supports up to 8XXX.

[funkyass]

try the latest version of Xorg - 7.2

[byuu]

Not possible, there's seriously no chance in hell I'm trying to upgrade X.org, binary packages or otherwise.

I found the problem, however.

http://julipedia.blogspot.com/2006/03/f ... blems.html

Code: Select all

   new_linear = xf86AllocateOffscreenLinear(pScreen, size, 32, 
                                                 NULL, NULL, NULL);

Code: Select all

xf86fbman.c:localAllocateOffscreenLinear(): 
   if(gran && ((gran > pitch) || (pitch % gran))) { 
        /* we can't match the specified alignment with XY allocations */ 
        xfree(link); 
        return NULL; 
   } 

The variable 'pitch' is deceiving, it is pixel resolution width, and not bytes/scanline. 'gran' is granularity in pixels. As you can see, nv driver is always requesting 32-byte granularity, and (1680%32)!=0. I don't know why things worked at 1400x1050, as (1400%32)!=0 either, but whatever.

I do not have X.org sources, and don't even think it's possible to just recompile the nv driver alone on the non-modular 6.9.0 Xorg (I'd edit that and lower the granularity, as apparently 16 works just fine too), so instead I created a custom modeline:

Code: Select all

    Modeline "1664x1040"  143.71  1664 1768 1944 2224  1040 1041 1044 1077

And then added some special options to the device driver section:

Code: Select all

    Option      "FlatPanel" "true"
    Option      "FPDither"  "false"
    Option      "FPScale"   "false"

So that the image is always centered and never scaled.

There is now a slight border around my monitor, but whatever. It works fine, everything looks good. Used that nvidia gtf tool to make the modeline. It's not quite 146.36mhz dot clock, but whatever. Hopefully it won't damage my flatpanel by being off by a little.

Everything works now. Major props to that person in the above link for digging through the driver source to find the bug. It's apparently going to be fixed in the next version of Xorg (7.3 or whatever), which should hopefully trickle down to FreeBSD sometime in 2009, if we are lucky.

People are going to be weirded the hell out if I ever post screenshots again, though.

[funkyass]

modular X is better than non-modular X.

I hope thats is fixed in 7.2

DVI or analog?