On Mon, Jun 15, 2015 at 11:19:13PM +0200, Riccardo Mottola wrote: > Hi, > > for the same laptop for which I just posted a full dmesg about the > battery problem, which reports this video card: > > vga1 at pci1 dev 0 function 0 "NVIDIA GeForce 8400M GS" rev 0xa1 > > I get a super-slow X11. Dragging an xterm may take half a second, up to > the point where X11 looses track of the mouse move events. Scrolling > XTerm is unusably slwo too. > > Using a larger editor like Emacs or Firefox... even worse. It looks > totally unacelercated. > > Should the 8400 work? IN the Xorg log I see this: > [ 5902.005] (II) VESA: driver for VESA chipsets: vesa > [ 5902.005] (--) NV: Found NVIDIA GeForce 8400M GS at 01@00:00:0 > [ 5902.005] (WW) Falling back to old probe method for vesa > [ 5902.006] (II) Loading sub module "int10" > [ 5902.006] (II) LoadModule: "int10" > [ 5902.007] (II) Loading /usr/X11R6/lib/modules/libint10.so > [ 5902.017] (II) Module int10: vendor="X.Org Foundation" > [ 5902.017] compiled for 1.16.4, module version = 1.0.0 > [ 5902.017] ABI class: X.Org Video Driver, version 18.0 > [ 5902.017] (II) NV(0): Initializing int10 > [ 5902.017] (II) NV(0): Primary V_BIOS segment is: 0xc000 > [ 5902.018] (--) NV(0): Console is VGA mode 0x3 > [ 5902.018] (II) NV(0): Creating default Display subsection in Screen > section > "Default Screen Section" for depth/fbbpp 24/32 > [ 5902.018] (==) NV(0): Depth 24, (--) framebuffer bpp 32 > > so the "nv" driver loaded.. but then further below: > [ 5902.185] (**) NV(0): Driver mode "1280x800": 71.0 MHz (scaled from > 0.0 MHz), 49.3 kHz, 59.9 Hz > [ 5902.185] (II) NV(0): Modeline "1280x800"x59.9 71.00 1280 1328 > 1360 1440 800 803 809 823 -hsync -vsync (49.3 kHz eP) > [ 5902.185] (==) NV(0): DPI set to (96, 96) > [ 5902.185] (II) Loading sub module "fb" > [ 5902.185] (II) LoadModule: "fb" > [ 5902.185] (II) Loading /usr/X11R6/lib/modules/libfb.so > [ 5902.200] (II) Module fb: vendor="X.Org Foundation" > [ 5902.200] compiled for 1.16.4, module version = 1.0.0 > [ 5902.200] ABI class: X.Org ANSI C Emulation, version 0.4 > [ 5902.200] (II) Loading sub module "xaa" > [ 5902.200] (II) LoadModule: "xaa" > [ 5902.208] (WW) Warning, couldn't open module xaa > [ 5902.208] (II) UnloadModule: "xaa" > [ 5902.208] (II) Unloading xaa > [ 5902.208] (EE) NV: Failed to load module "xaa" (module does not exist, 0) > [ 5902.208] (II) Loading sub module "ramdac" > [ 5902.208] (II) LoadModule: "ramdac" > [ 5902.208] (II) Module "ramdac" already built-in > [ 5902.208] (II) UnloadModule: "vesa" > [ 5902.208] (II) Unloading vesa > [ 5902.208] (--) Depth 24 pixmap format is 32 bpp > [ 5902.224] (--) NV(0): 120.69 MB available for offscreen pixmaps > [ 5902.228] (==) NV(0): Backing store enabled > [ 5902.228] (==) NV(0): Silken mouse disabled > [ 5902.230] (II) NV(0): RandR 1.2 enabled, ignore the following RandR > disabled message. > [ 5902.237] (==) NV(0): DPMS enabled > [ 5905.804] (--) RandR disabled > [ 5905.856] (II) AIGLX: Screen 0 is not DRI2 capable > [ 5905.856] (EE) AIGLX: reverting to software rendering > [ 5906.010] (II) AIGLX: Loaded and initialized swrast > [ 5906.010] (II) GLX: Initialized DRISWRAST GL provider for screen 0 > [ 5906.011] (II) NV(0): Setting screen physical size to 338 x 211 > > I suppose the "reverting to software rendering" is the final error and > clue to the problem: no kind of acceleration at all. >
Acceleration is not needed on "modern" machines to get fast 2D display. The CPU speed and memory bandwidth are largely sufficient to make desktop very responsive and watch full-screen movies. Probably what you observe is that the video memory is setup in a very restricted mode, making it extreamly slow. For instance on my system, I measured 70MB/s with BIOS settings (i.e. memory was slower than a hard disk, ridiculous), and 7500MB/s when properly initialized. This is for intel chipset, but I remember similar stories about nvidia chips. If you manage to get the address of the video frame buffer, you could try to use the memconfig(8) utility to see if write-combining is enabled for the frame buffer, and possibly enable it. This might make things less worse. I'm not sure if setting mtrrs with memconfig is still enough nowadays, maybe someone would have a better insight.
