[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:-

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 
> 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: