Hello I think vesa driver allow only built-in resolution of your bios. I saw in my Xorg.0.log: ... (II) VESA(0): Not using mode "1440x900_60.00" (no mode of this name) ... (--) VESA(0): Virtual size is 1024x768 (pitch 1024) (**) VESA(0): *Built-in mode "1024x768" (**) VESA(0): *Built-in mode "800x600" (**) VESA(0): *Built-in mode "640x480" (==) VESA(0): DPI set to (96, 96) (II) VESA(0): Attempting to use 60Hz refresh for mode "1024x768" (118) ... ...
I guess I'm stuck with 1024x768 too :( Le 2013-11-02 16:37, Comète a écrit : > Hello, > I've tried vesa too and it works but it is limited to 1024x768... if you > have any tips to allow 1440x900 with vesa, i take it... > > Thanks > > Morgan > > Le 02/11/2013 16:10, Gilles Cafedjian a écrit : > >> Hello, Indeed, switching to vesa driver in xorg.conf removed all the windows >> lags. I don't need any kind of 3D acceleration, so vesa is just enough to >> run Emacs and resizing some windows. I think the best will be to port >> Nouveau to OpenBSD, but it's not a priority. As I said, vesa is just good >> enough to work with basic 2D, for people stuck with Nvidia. Thanks, Gilles >> Cafedjian. Le 2013-10-30 08:08, Matthieu Herrb a écrit : On Tue, Oct 29, >> 2013 at 05:36:43PM +0100, Gilles Cafedjian wrote: I have the same problem >> but on a dell laptop with integrated NVidia chip. The chip is NVidia Geforce >> 8600M GS and since I upgraded to 5.4 my laptop is unusable (very slow window >> movement). I'm thinking of reinstall 5.3 to have a working laptop. I can't >> change GPU chipset. There is a solution to get a working window manager >> back? If the VESA BIOS on you machine supports the native resolution of the >> panel, then running the vesa driver is probably faster than the nv driver. >> Otherwise, if som e people with development skills want to help, I can see 3 different projects there, with different levels of complexity and interest (I currently miss time to work on these issues.): project 1 - relatively easy get yourself familiar with the shadowfb implementation in the vesa driver and then fix it in xf86-video-nv. xf86-video-nv's shadowfb is currently disabled because it crashes the driver. This would probably bring most of the speed back for a relatively low effort. project 2 - a bit harder get yourself familiar with the EXA acceleration framework, and port the current XAA code in xf86-video-nv to EXA. Bitblt operations should give you a reasonable speed-up back on supported cards. But the XAA code is full of magic numbers (no docs, remember) and since EXA is probably also going to get dropped by X.Org in the future, this is probably not the best choice, but it's still interesting to learn about 2D acceleration in X.Org drivers. project 3 - hard dive into the world of DRI and TTM and port the nouveau kernel driver(s) to OpenBSD. Thanks to jsg@ and kettenis@, OpenBSD has now a Linux kernel kernel 3.8 compatible version of the dri infrastructure (including TTM) for intel and radon chipsets. Getting the corresponding nouveau code is thus possible. This is a multi-months project but it's an exciting one and it will provide the most benefit for people forced to use nVidia cards, and for the project in general since having more people hacking in the dri code is also good for the other drivers.
