Re: `Xorg -configure' failure
On 07/10/11 15:21, Harry Putnam wrote:
> Scott Ferguson <firstname.lastname@example.org> writes:
>> On 07/10/11 02:44, Harry Putnam wrote:
>>> [NOTE: This post or very similar was also posted to
>> It's considered bad manners to cross post - why waste more peoples
> Why is that wasting anyones time. Some people read it here some
> there, if they don't like the subject or content they move on.
Some people read things - that takes time.
Not counting this post - there are 26 posts in the three threads you
have on this subject (panning) including three xorg logs - without
reading all of them I can't determine what *isn't* relevant. If you're
so certain about what it costs other people maybe you should fix your
The problem you are having (and there is a problem) is complex.
The panning I'm able to do is just up and down (1024x600 display inside
a 1024x768 virtual screen) is on different hardware and software (ASUS
PC Eeee 701SDs running Squeeze with Trinity KDE - it's also done with
xorg.conf - not xrandr.
When I try and pan using a similar setup to you I run into a problem
with insufficient space left in the virtual screen (I "suspect").
When I disable those unused screens I get "BadRRCrtc (invalid Crtc
parameter)" errors. I don't know whether those errors apply to later
Xorg releases (I only use stable).
There are a number of work-arounds - within the above constraints I am
able to get limited panning by enlarging the borders.
Gnome 3 "apparently" gets around the problem using this patch:-
Until the upstream fixes trickle down you might find this useful:-
Or patch with this:-
> Where is the waste?
Time I could have spent on other things rather than trying to follow
these posts and threads.
> I don't understand you. What settings are you speaking of. I've
> tried to supply any information you requested. Please say plainly
> what information you want, instead of contained obliquely in a
I spent time this morning feeding three different xorg logs through a
screen reader, multiple times - and you argue nothing has changed.
You may be correct - but my ears disagree.
If nothing has changed all logs would be almost identical.
> My current setting haven't changed at all. I'm talking here about
> trying to come at the problem from a little different angle.
> Although I actually doubt it will work, because I suspect the same
> bug that is preventing it working with xrandr will prevent xorg.conf
> using a Virtual parameter too.
> Further more, we have already hit upon commands that have done what
> I wanted. It no longer requires testing. The problem is that the
> mouse is not being allowed to wander out into the Virtual size.
Then you don't need the work-around I tested.
>>>> From Section "Screen"
>>> Subsection "Display" Depth 24 Modes "1280x1024"
>>> #"1024x768" "800x600" "640x480" Virtual 2048 1536 ViewPort
>>> 0 0 EndSubsection
>>> Its the virtual size I'm after.
>> Then change the virtual size - not the *display* size. That
>> section refers to the display size for the default monitor (not
>> even the monitor you currently use).
> No, you are wrong there... but it's my fault for not fully
> explaining the origin of that piece of xorg.conf. That very
> xorg.conf was used on a CRT, but when I changed to a 25.5 lcd that
> same section worked there too when running Gentoo.
You were running nouveau on Gentoo?
> So what I said about it being the same hardware is true.
>> If those are the setting you want, and they are supported by the
>> *different display* - then that's all that needs to be in
>> /etc/X11/xorg.conf - X will deal with everything else. However you
>> will need to use xrandr to disable your other screens (TV and
> What is all I need of xorg.conf? Do you mean just what is printed
> above between the elisions? The subsection of the sub section. Do
> you mean it could just say:
> Subsection "Display" Depth 24 Modes "1280x1024"
> #"1024x768" "800x600" "640x480" Virtual 2048 1536 ViewPort 0
> 0 EndSubsection
>>> Its worked on this same hardware in the past under Gentoo linux.
>> Perhaps you "mean" the video card is the same...
>> A CRT monitor is *not* a LCD monitor. So you *don't* have the same
>> hardware. Monitors *are* hardware.
> See above. And sorry for misleading in previous posts. That xorg
> conf began life on a 17 inch CRT but was later used on the very
> hardware including the 25.5 inch lcd monitor that I am using now.
CRTs and your LCD do not have the same aspect. While x no longer causes
CRTs to catch fire - it can ruin LCDs (rare, but it can happen).
>> Gentoo doesn't use Nouveau - you do. So don't expect the same
>> results when software and hardware have changed.
> So is Nouveau incompatible with the ability to pan?
That I don't know - for the life of me I can't understand why anyone
other than a developer would use Nouveau. I buy 3D video cards to use
3D. The problem is Nvidia - not Nouveau, but it doesn't change that
Nouveau has problems (Nvidia proprietary drivers also have problems).
> Do I need to change drivers, scrap Nouveau?
>>> And using xrandr to attain the virtual size has been discussed at
>>> some length in another thread...
>> Not on this list. Virtual size was discussed in passing. Panning
>> was discussed at length.
> Now I'm really confused. When you speak of panning, what is being
> panned into? Is that not virtual size out beyond the monitors real
Without diverting into amphibolic argument - "virtual size and *setting
virtual size* was discussed in passing - *not in detail*"
>From memory I said "I haven't done the math" - I got you to use cvrt to
see what modes were possible, and xrandr to see had outputs and modes
were set - but hadn't done the math as to what was "feasible". It may
seem simple to you - it's not to me.
Read further down - I'm trying to keep the structure of you emails
intact for other readers.
>>> so far it hasn't worked. It appears to be because of a bug
>>> caused by certain code that prevents the mouse from panning out
>>> into the virtual size.
More precisely (I suspect)- a bug that prevents changes in virtual size
made by xrandr being communicated to the x server - when set by
xorg.conf it may well work.
Using the same video card as you, and a similar display (Squeeze) I had
to change the view port to allow a margin and disable VGA out - but it
did pan though I lose some screen. (with Xrandr).
>> AFAIK there is no such bug.
>>> I'm trying to sneak up on that bug by setting a virtual size in
>>> xorg.conf... It seem doubtful it will work but I'm not sure what
>>> the details of the mouse panning bug are.
I suspect that may be the correct approach.
>>> I'm not sure there is an actual Debian bug about the mouse
It would appear that there is - though it may only occur in later
releases (it's an upstream problem).
>>> but I see several other OS's are reporting such a bug. Ubuntu
>>> and Redhat specifically.
>> Please post links to these bugs.
> At least one (from redhat) was already mentioned in the previous
> thread: Subject: wrestling with xrandr
> Note especially comment 22
Noted. Thank you.
> Seems to describe exactly what I see when for example I run one of
> the commands you suggested:
> xrandr --output DVI-I-1 --mode 1440x900 --panning 1680x1050
> I can see the screen enlarge quite a lot by watching the picture I'm
> using as background grow quite noticeably, and the mouse can then
> partially disappear at the monitor boundary... a slight bit more
> than it could prior to running the command. Further, a fluxbox
> panel that was placed at the bottom of my screen has now moved clear
> out of site and cannot be accessed with the mouse because it is not
> allowed to pan.
That is part of a "bug" (the display is not centered automatically in
the centre of the virtual screen).
I don't use Fluxbox - but a work-around in KDE is Alt+F3 and select Move
from the Window menu.
You could also try Ctrl+Alt++ or Ctrl+Alt+- to cycle through modes and
try and force a new Crtc parameter.
>>> I haven't been able to generate xorg.conf so far because `Xorg
>>> -configure' fails without generating a file.
>> For future reference you can't generate an xorg.conf from within a
>> X session using "Xorg -configure" (you can generate one from
>> /var/log/Xorg.0.log though).
> I was aware of that requirement and in fact ran Xorg -configure
> after closing X which drops me into a text console.
Strange - it's how I generated the xorg.conf this morning.
> How do you go about generating one from /var/log/Xorg.0.log? Do you
> mean by hand or what?
With x shutdown:-
# cp /var/log/Xorg.0.log /var/log/Xorg.1.log;Xorg -configure :1;cp
>>> [177036.474] (II) UnloadModule: "vmwlegacy" [177036.474] (II)
>>> Unloading vmwlegacy [177036.474] (II) Failed to load module
>>> "vmwlegacy" (already loaded, -1219177616) [177036.474] (EE)
>>> vmware: Unexpected failure while loading the "vmwlegacy" driver.
>>> Giving up. [177036.474] (II) UnloadModule: "vmware" [177036.474]
>>> (II) Unloading vmware [177036.474] (EE) Failed to load module
>>> "vmware" (a required submodule could not be loaded, 136110067)
>> ^^^^^^^^^^^^^^Is this a vmware machine??
I'm confused - perhaps it's just that it's the end of a long week, and
that there is so much to read/listen to in these threads...
If nothing has changed why are you now loading vmware drivers?
Or do we have different understandings of "nothing"? :-)
>>> [177036.520] (==) ServerLayout "X.org Configured" [177036.521]
>>> (**) |-->Screen "Screen0" (0) [177036.521] (**) | |-->Monitor
>>> "Monitor0" [177036.521] (**) | |-->Device "Card0" [177036.521]
>>> (**) |-->Screen "Screen1" (1) [177036.521] (**) | |-->Monitor
>>> "Monitor1" [177036.521] (**) | |-->Device "Card1" [177036.521]
>>> (**) |-->Screen "Screen2" (2) [177036.521] (**) | |-->Monitor
>> ^^^^^^^^^*Those* screens fit within the "virtual screen".
> I don't understand what you mean, and obviously do not understand
> what `virtual screen' is supposed to be.
Those screens take up space in the virtual screen - a rectangle with
other rectangles within it. You can't "pan" from one into another. The
area taken by your three screens is larger than your virtual screen.
That won't work.
> I took it to be the part of the screen that is out where you can't
> see it. The part I'm trying to pan into.
It is - it's also the area used by the "other" screens (TV-out & VGA)
> Are you able to pan around on your setup?
Yes - it's one rectangle (the display screen) within a larger virtual
screen - the difference between the two is the "panning" area.
The X Strike Force (Debian x packagers) have an article on
wiki.debian.org which covers much of xrandr and is a good starting
point. I would suggest that if you are posting to another list - give
the other list a chance to answer the problem - your "idea" of rules for
cross-posting is not shared by everyone.