Up until X.org 7.2 the screen resolution could be set with a "ModeLine" definition in the "Monitor" section in xorg.conf. With 7.3 the ModeLine is ignored. X starts in a lower resolution and flickers badly. Fix: Workaraound: Create a subdirectory /etc/X11/xinit/xinitrc.d and put a (executable) text file in it containing something like this: xrandr --newmode "1200x960@83" 131.00 1200 1204 1324 1588 960 961 964 992 xrandr --addmode VGA "1200x960@83" xrandr --output VGA --mode "1200x960@83" However, I'm experiencing several issues when using RANDR to set the resolutions: - It only works on the session, i.e. after you log in with xdm / gdm. Xdm itself is still displayed in the wrong resolution and flickers badly. - In the session, mplayer no longer works with XV video output. Instead you get a blue window now. X11 output still works, but sucks. - In QEMU, when starting Windows, the mouse pointer disappears when you click on the desktop which makes it unusable. How-To-Repeat: Put something like this in the "Monitor" section of xorg.conf: ModeLine "1200x960@83" 131.00 1200 1204 1324 1588 960 961 964 992 Option "PreferredMode" "1200x960@83" And repeat the identifier "1200x960@83" as Modes in the "Screen" section, "Display" subsections. Start X and see it come up in 1152x768 at 55Hz or something.
Responsible Changed From-To: freebsd-ports-bugs->freebsd-x11 Over to maintainer (via the GNATS Auto Assign Tool)
Responsible Changed From-To: freebsd-x11->stas I'll take it.
It seems that the port has been updated to the wrong snapshot (from the incorrect branch). Can you try the following patch? -- Stanislav Sedov ST4096-RIPE
What's the additional patch for exactly? -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer
flz 2008-01-02 13:23:52 UTC FreeBSD ports repository Modified files: x11-drivers/xf86-video-mga Makefile distinfo Added files: x11-drivers/xf86-video-mga/files patch-1.4.7-master-20080102 Log: Rollback to xf86-video-mga 1.4.7 (and patches from master as of today). Dual-head doesn't work properly with this version but at least most single-head setups will work correctly. PR: ports/117726 Submitted by: Bernd Strauß Discussed on: x11@ Revision Changes Path 1.4 +2 -1 ports/x11-drivers/xf86-video-mga/Makefile 1.4 +3 -3 ports/x11-drivers/xf86-video-mga/distinfo 1.1 +151 -0 ports/x11-drivers/xf86-video-mga/files/patch-1.4.7-master-20080102 (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Committed. Thanks!
Hi folks, problem analyzed. This seems to be more or less a "works as designed" issue. There seems to be a new style of video drivers, and they work a little different, and also the configuration (and some of the concepts of the configuration) is different. Also, this code seems rather new, and maybe it will still take some time to mature out. What we can notice: the video drivers get smaller: there is less things each video driver does on its own, and more things are done in a standardized way within the main Xserver. And that is the reason why with unchanged Xserver the mga-1.4.7 behaves as we are used to it, while the 1.9.100 behaves a bit different. Now for the differences in the new driver: 1. We are used to declare a couple of screen resolutions in the "Display" SubSection of the "Screen" Section, labelled "Modes", like this: > Section "Screen" > ... > SubSection "Display" > Modes "2032x1480" "1800x1300" "1600x1200" "1480x1024" > EndSubsection > EndSection With the new driver, this line seems to be completely ignored and can be left away. The only usefulness it ever had seems to be that one could change resolution inflight by means of CtrlAlt+-, and I understand if we want to do this we are now supposed to learn to use xrandr(1). 2. There was a thing called "Virtual". This represented the actual size of the "canvas" - the total number of known pixels in the graphics card, even if the display would only show part of it - then the display would move when the cursor would reach its border. This "Virtual" would be automatically set to the biggest resolution given in the beforementioned Modes list - but one could also set it explicitely, like here: > Section "Screen" > ... > SubSection "Display" > Virtual 2048 1536 > Modes "2032x1480" "1800x1300" "1600x1200" "1480x1024" > EndSubsection > EndSection This function seems no longer to exist. Instead, the "Virtual" now simply defines the upper limit of possible modelines. A modeline with a bigger (X- or Y-) resolution than the "Virtual" will not be used. 3. If You take a look at the logfile that the Xserver creates (usually in /var/log/Xorg.*.log), then You may recognize that the Xserver does already automatically define for You the "Virtual" and the "Mode": > (II) MGA(0): Output VGA using initial mode 1152x768 > (--) MGA(0): Virtual size is 1600x1024 (pitch 0) I have not bothered finding out how the Virtual is decided upon, but the "initial mode" is made up in a way that should give best viewing results considering the measurements of Your monitor. So, You have not configured the size of Your monitor? Well, then thats possibly the problem... Now, the bad thing is: there is no way to configure that data. Actually there is an option "DisplaySize", but this seemingly does something different - that does not work. 4. Now concerning the "Virtual" the matter is easy: it can (and possibly should) be changed; by entering it into the "Display" SubSection of the "Screen" section, like shown above. It need to be at least as big as the resolution of the modeline you want to use! 5. The Mode can also be changed, but this is now done in the Monitor section where the Modelines are defined. There You can enter an Option "PreferredMode", and this is the mode with which the Xserver will start up: > Section "Monitor" > Identifier "SilGraph" > ... > HorizSync 30-109 # Monitor erkennt limit selbst! > VertRefresh 48-160 > Option "PreferredMode" "1480x1024" > EndSection You do not necessarily need to provide a "Modeline" at all. There is a whole bunch of predefined "Default modes". (You can see them in the Xserver log.) If You like one of these, it is enough to give that name. Of course You can still craft Your own Modeline, give it a name, and call that name the "PreferredMode". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now there are two caveats, or, so to say, bugs in the game (or at least these two I have found): 6. There are a couple of duplicate "Default modes" - modes with the same resolution (and therefore the same name) but different timings. Like these here: > (**) MGA(0): Default mode "1400x1050": 155.8 MHz, 81.5 kHz, 74.8 Hz > (II) MGA(0): Modeline "1400x1050"x74.8 155.80 1400 1464 1784 1912 1050 1052 1064 1090 +hsync +vsync (81.5 kHz) > (**) MGA(0): Default mode "1400x1050": 122.0 MHz, 64.9 kHz, 60.0 Hz > (II) MGA(0): Modeline "1400x1050"x60.0 122.00 1400 1488 1640 1880 1050 1052 1064 1082 +hsync +vsync (64.9 kHz) If You call one of those, the Xserver may not know which one to choose, and therefore goes into an endless loop brooding. This is unfunny, as You only get it out there with "kill -9", and that likely renders Your display unuseable. Solution: copy the modeline into Your monitor section, give it a really unique name, and then call that: > Section "Monitor" > ... > Modeline "myfavourite" 155.80 1400 1464 1784 1912 1050 1052 1064 1090 +hsync +vsync > Option "PreferredMode" "myfavourite" > EndSection 7. Some crafted modelines, which used to work, show now alignment errors. This is the case with one of my favourites: > ModeLine "1800x1300" 256 1800 1864 2056 2360 1300 1301 1304 1350 +hsync +vsync This one will work fine on first server start, but after logging out and in again it gives a profound alignment error. Over all, I am not sure which of these things are to be considered as "works as designed" or are to be considered bugs. And it seems none of them are FreeBSD problems. HTH rgds, PMc