Re: `Xorg -configure' failure
On 07/10/11 15:21, Harry Putnam wrote:
> Scott Ferguson <prettyfly.productions@gmail.com> writes:
>
>> On 07/10/11 02:44, Harry Putnam wrote:
>>> [NOTE: This post or very similar was also posted to
>>> gmane.comp.freedesktop.xorg.]
>>
>> It's considered bad manners to cross post - why waste more peoples
>> time?
>
> 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.
Nice attitude.
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
own problems.
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:-
http://cgit.freedesktop.org/xorg/xserver/commit/?id=d45f5b2493bc0a2882bf972849b5c9c50cd533ca
Until the upstream fixes trickle down you might find this useful:-
http://sourceforge.net/projects/xcursorclamp/
Or patch with this:-
http://lists.x.org/archives/xorg-devel/2010-November/015495.html
or:-
http://lists.x.org/archives/xorg-devel/2011-June/023715.html
> Where is the waste?
Time I could have spent on other things rather than trying to follow
these posts and threads.
<snipped>
>
> 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
> complaint.
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
>> VGA).
>
> 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
> estate.
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
>>> problem
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
>
> https://bugzilla.redhat.com/show_bug.cgi?id=655212
>
> 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
/root/xorg.conf.new /etc/X11/xorg.conf
> [...]
>
>>> [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)
>> <snipped>
>>
>>
>> ^^^^^^^^^^^^^^Is this a vmware machine??
>
> No
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
>>> "Monitor2"
>>
>> ^^^^^^^^^*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.
Good luck
Reply to: