From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L4Cnv-00077U-Bh for garchives@archives.gentoo.org; Sun, 23 Nov 2008 11:07:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3D47E03E5; Sun, 23 Nov 2008 11:07:02 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 32BE7E03E5 for ; Sun, 23 Nov 2008 11:07:02 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L4Cnq-0000W2-AA for gentoo-amd64@lists.gentoo.org; Sun, 23 Nov 2008 11:06:58 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 11:06:58 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 11:06:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display Date: Sun, 23 Nov 2008 11:06:52 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f4088d02-77ad-497b-8e37-2c7466e4e035 X-Archives-Hash: f163d8bf42ed779e31740b5eebb8b779 Duncan <1i5t5.duncan@cox.net> posted pan.2008.11.23.07.23.44@cox.net, excerpted below, on Sun, 23 Nov 2008 07:23:44 +0000: >>> So I scripted up a solution using xrandr, put the entries in my kmenu= , >>> and can use them to switch resolutions. But there's still a problem. >>> The origin coordinates portion appears to be broken, so when I >>> downgrade resolution, the viewport is always the upper left portion o= f >>> the full size version. There's no mouse panning with randr yet >>> (that's supposed to be added for xorg-server 1.5.3 or possibly later >>> if what I read is correct), and with origin coordinates broken at >>> least on the radeon driver on my hardware, upper left (still stacked >>> at least, but still just upper left) is all I get, and that's not ver= y >>> practical. >>> >> if you could post the script it would be interesting. >=20 > I'll post the script in a separate reply... OK, here it is, as a UUEed attachment below the sig, filenamed=20 "set-display". As I do the list as a newsgroup thru gmane using pan,=20 which doesn't handle posting attachments, I use a script setup as pan's=20 external editor to do the encoding and attaching. Unfortunately, that=20 limits the encoding choices to UUE and "identity" (which means simply=20 attach it as text). I hope gmane takes small attachments. If not, I'll=20 retry with it inline. If you're familiar with xrandr, it should be pretty easy to follow and=20 modify as necessary for your setup. The default no-parameter action is=20 to set both panels to 1920x1200, stacked, my native resolution, so unless= =20 your monitors can handle that, don't try running it as-is without a=20 parameter. If you feed it a parameter it doesn't recognize, or the usual= =20 -h or --help, it'll spit out some help. Taking a look at the script code, you can see several of the possible=20 settings commented. These were valid back on my old CRTs, but aren't=20 valid on my current setup. As I said, if you're familiar with xrandr, changing it for your setup=20 should be pretty simple. I didn't bother with a config file for it, but=20 the main variables are all set at the top and reasonably abstracted. =20 Beyond that, you'd need to change the resolutions themselves, but the way= =20 it's setup that's fairly easy. I've already done it once myself, when I=20 switched to the dual LCD panals from my former CRTs. Given the=20 abstraction, it shouldn't even be /that/ hard to alter it to deal with=20 two monitors side by side instead of stacked, tho I obviously designed it= =20 with stacked in mind. If it worked the way the xrandr documentation says it should, those lines= =20 of fancy math would set the position origins to always center the=20 viewport, which would grow or shrink in a constant framebuffer. That is,= =20 with stacked monitors and given my constant framebuffer size ($fb) of=20 1920x2400,the midline separating the two monitors would always remain the= =20 same, x,1200, with the horizontal midpoint of the monitors also remaining= =20 constant at 960,y, thus the constant midpoint, regardless of chosen=20 resolution, would remain 960,1200. As I said in my initial post, however, the viewport positioning code=20 doesn't seem to work on at least my radeon 92xx series video card with=20 the xf86-video-ati radeon driver. The resolution changes work, but the=20 viewport is always originated at 0,0, the top left corner. As you can see, I left the set -x in there for troubleshooting. That=20 way, if I run it from a terminal window (konsole, of course, since I'm a=20 KDE guy, situated far enough to the upper left that when I change=20 resolution I can still see it!!), I can see what the actual xrandr=20 commands issued are, along with the results, since I set verbose as=20 well. That's fine since I don't normally run it from konsole anyway, but= =20 rather from the kmenu, as invoked by hotkey. (As I said, I hotkey invoke= =20 nearly /everything/ I use regularly enough to remember a sequence for, in= =20 kde3, thus its brokenness in kde4 in practice means the entirety of kde4=20 is broken, so far. But that's supposed to be fixed for 4.2...) So when=20 I run it from konsole and get the output, it's because I'm=20 troubleshooting and /want/ the output. If you run the script with -h (or look at the code), you can see the=20 parameter in both short and long forms corresponds to the x=20 resolution. Thus, my kmenu entries are along the lines of Name: SetDisplay-8 Comment: Sets the display to 2x800x600, stacked for 800x1200 Command: set-display 8 I use the "fullscreen" action icon, which is a window with arrows in the=20 four corners (with the crystal icon theme at least). The hotkey would be XF86HomePage,F8 (XF86HomePage just because it's one=20 of the extra buttons on this Logitech keyboard, used here to launch a=20 menu with a bunch of different secondary key options, in this case F8, to= =20 launch set-display to set 800 width). The set-display 19-6 option is set with a kmenu title of=20 SetDisplay-Orion, since that's what I use it for, playing Master of Orion= . What I /intended/ to do, when I was designing the script (thus before I=20 knew about the above positioning bug), was after I got this script=20 switching and centering correctly, I'd create another script that I could= =20 invoke to incrementally pan position, say 100 px at a time in the desired= =20 direction. (I intended to experiment with the increment, but obviously=20 when the positioning failed to work, I never got that far.) Then I could= =20 have invoked the panning script (hotkeys again!) to move the viewport=20 around the framebuffer as necessary, giving me back at least a crude=20 version of the panning ability the old merged framebuffer driver had,=20 before the switch to xrandr. Hopefully the positioning code will work either on newer radeon hardware,= =20 or at least on other brands and therefore other drivers. If it does and=20 someone wants those panning scripts, I could probably whip them up=20 without too much trouble. Meanwile, as I believe I mentioned, I was scanning the xorg mailing list=20 and saw a discussion of the schedule and features for the next xorg=20 release. (BTW, the latest xorg-server release, 1.5.3, isn't in the Gentoo= =20 tree yet, even masked. It's probably in the xorg overlay...) It's=20 supposed to finally have panning again, which will be nice. Then the=20 xrandr viewport positioning won't matter so much since you can just pan=20 it to where you want. Once again, don't run this without either the -h/--help option or=20 modifying it to fit your dispaly hardware, first. Now... will the attachment post? --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman begin 740 set-display M(R$O8FEN+V)AS$Z+3!]"0DC(')E<75EPH)96-H;PH)96-H;R!5F4^72(*"65C:&\*"65C:&\@(E-E=3D',@6"!D=3D6%L+61I#$R,#`@96%C:"P@("`Q-C`P>#(T,#`@=3D&]T86PB"B,)96-H;R`B("`@ M(#$R?#$R.#`Z("`@("`@("`@("`@("`@,3(X,'@Y-C`@(&5A8V@L("`@,3(X M,'@Q.3(P('1O=3D&%L(@H)96-H;R`B("`@(#$P?#$P,C0Z("`@("`@("`@("`@ M("`@,3`R-'@W-C@@(&5A8V@L("`@,3`R-'@Q-3,V('1O=3D&%L(@HC"65C:&\@ M(B`@("`@.7PY-C`Z("`@("`@("`@("`@("`@("`Y-C!X-S(P("!E86-H+"`@ M("`Y-C!X,30T,"!T;W1A;"(*"65C:&\@(B`@("`@.'PX,#`Z("`@("`@("`@ M("`@("`@("`X,#!X-C`P("!E86-H+"`@("`X,#!X,3(P,"!T;W1A;"(*"65C M:&\@(B`@("`@-GPV-#`Z("`@("`@("`@("`@("`@("`V-#!X-#@P("!E86-H M+"`@("`V-#!X.38P("!T;W1A;"(*(PEE8VAO("(@("`@(#5\-3$R.B`@("`@ M("`@("`@("`@("`@-3$R>#,X-"`@96%C:"P@("`@-3$R>#&ET"GT*"B,@;71M/21M=3D"UM;V1E+"!M=3D'`] M)&UT+7!O###0X,#MM=3D'`],'@P.VUB<#TP>#$R M,#`[.PH)*BD)"6AE;'!T>'0[.PIEVUT;25X M*GT@*2D@+R`R("DI>"0H*"`D>V9B(RIX?2`O(#(@+2`D>VUT;2,J>'T@*2D* M"B,@)&UB;2]M;VYI=3D&]R+6)O=3D'1O;2UM;V1E(&1E9F%U;'1S('1O("1M=3D&T* M6R`D;6)M(%T@?'P@;6)M/21M=3D&T*"B,@)&UB<"]M;VYI=3D&]R+6)O=3D'1O;2UP M;W-I=3D&EO;B!D969A=3D6QT2!O9B`D;71P('!L=3D7,@>2!O9B`D;71M*0HC("AS:6YC92!O=3DF5R M86QL('!O')A;F1R("1C M("1M=3D"`D;2`D;71M("1O("1M8B`D;2`D;6)M"F5C:&\*>')A;F1R("1C("1M M=3D"`D<"`D;71P"F5C:&\*>')A;F1R("1C("1M8B`D<"`D;6)P"F5C:&\*>')A B;F1R("1C("1M=3D"`D<"`D;71P("1O("1M8B`D<"`D;6)P"@`` ` end