On 07/10/11 15:21, Harry Putnam wrote: > Scott Ferguson <prettyfly.producti...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8ea2ad.70...@gmail.com
