[gentoo-amd64] kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[gentoo-amd64] kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

New thread, since the topic wandered from what it was on the old one.

Beso <givemesugarr@gmail.com> posted
d257c3560811221559h2762345eq6e13c03bf0e6588@mail.gmail.com, excerpted
below, on  Sat, 22 Nov 2008 23:59:53 +0000:

> 2008/11/22 Duncan <1i5t5.duncan@cox.net>:

>> FWIW, I tried the kde3 krandr-tray applet and it appears to be
>> outdated, only handling randr-1.0 commands.  I suppose kde4 has an
>> updated version with the 1.1 and 1.2 commands.  I do have kde4 merged
>> now, but it's still broken in enough ways I don't use it for everyday
>> yet.
>>
>>
> well, the system-settings one seems to work quite well for me. it's true
> that dual head is a little tricky with kde (most of the time makes
> plasma crash without setting the dual head). also i'm using the 4.2
> development brach (plaudis kdebuild overlay) that seems to be
> a little better in terms of usability and functionality than the portage
> 4.1.3 version.

Yes.  I think their choice of versioning sucked.  For quite some time I 
and others have argued 4.0 should have been 3.8 (developer base and 
technology preview for 4.0), 4.1 should have been 3.9 (public release 
preview for 4.0), and what is 4.2 should finally make the first decent 
4.x full release, what should have been 4.0.

But all that and just how far it's going to deflate KDE's momentum has 
been rehashed and rehashed over and over in the various blogs and 
Internet forums.  Meanwhile, we have the versioning we have.

I've chosen not to try the not-full-releases since I gave up on the betas 
earlier.  Additionally... well let's just put it this way, paludis, no 
way, no how, so that has been another encouragement not to do the KDE SVN 
stuff since the Gentoo/KDE folks started requiring paludis for it.  Thus, 
I'm sticking with 4.1.x since that's what's released.

But with 4.1, once I got the dual panels setup correctly with randr, it 
hasn't been a problem.  It was a problem with earlier 4.x and the merged 
framebuffer, and 4.1 doesn't seem to take well to them changing on it, 
but once I got xorg.conf setup to use randr to layout the dual panels as 
I wanted when it started, 4.1 was able to handle it after that.

But you're right on plasma.  It still isn't working quite right, in 
general.  It's supposed to let one zoom the desktops, and I can sort of 
do that, but once they get zoomed out, getting them to zoom back in 
/reliably/ has been a problem.  Sometimes plasma crashes, sometimes they 
zoom in but only on one panel's display, sometimes they zoom in but get 
stuck half on and half off the display... it's a mess!

Add that to the fact that I haven't seen a working ksysguard panel applet 
or the like for 4.x yet.  (ksysguard works, but I need something I can 
put always on top at the top of the combined display, without anything 
else ending up underneath it... like it works when set as a panel applet 
in kde3.)

Add /that/ to the fact that khotkeys seems to be broken, or at least 
trying to assign anything but default hotkeys to anything fails to work, 
AND that khotkeys is the main way I launch stuff in kde3.

Add /that/ to the fact that most of the fancy new effects require opengl, 
they don't work with composite and etc, the other option, but 
unfortunately they don't disable or otherwise indicate the ones that 
don't work, and opengl is limited to 2048x2048 on the radeon 92xx series 
and I'm running 1920x2400 so opengl doesn't work well, or at all in the 
lower 352 px of display, and kde4 has so far been too broken to seriously 
use.

Hopefully with 4.2 enough of that is fixed to at least be worth working 
around the issues that may remain.

>> 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 of
>> 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 very practical.
>>
> if you could post the script it would be interesting.

I'll post the script in a separate reply...

>> The point being that yes, dual-panel works with the freedomware xf86
>> ati/ radeon driver, at least for my hardware, once it's configured to
>> do so. However, there are some limitations.
>>
> i'll try out to see these days how the fglrx driver works with dual
> head. i've read that it does behave in quite a good manner. also,
> now that it has uvd and basic xvmc included i could also think to go
> back with it. the only problem is xorg compatibility.

As you know I won't even consider the proprietary drivers, here.  I had 
my fill with nVidia, and vowed never again.  Plus, every time xorg adds 
something new, it's the proprietaryware folks that hold it back, by 
months, nearing a year sometimes, from stabilizing.  I /do/ believe KDE 
got it right on that one, not waiting up for nVidia to catch up, simply 
telling folks using the nvidia driver that they'd have a seriously broken 
experience due to their choice of hardware and proprietaryware driver 
that couldn't keep up.

As for ATI/Radeon, at some point the new freedomware drivers should in 
general catch up, now that AMD has opened the specs.  I've been waiting, 
as I'd really like to upgrade this 9200.  Apparently the r5xx chips have 
a 4096x4096 virtual 3D area, and it'll be nice getting dual DVI dual-
link, too, instead of settling for the single single-link DVI and single 
analog that my current 92xx series has.

>> We should probably start a new thread on that if people want to discuss
>> the config and how I got it to work.
>>
> this would be really interesting.

That'll be another post as well.

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

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> I've chosen not to try the not-full-releases since I gave up on the betas 
> earlier.  Additionally... well let's just put it this way, paludis, no 
> way, no how, so that has been another encouragement not to do the KDE SVN 
> stuff since the Gentoo/KDE folks started requiring paludis for it.  Thus, 
> I'm sticking with 4.1.x since that's what's released.

The paludis requirement has been completely dropped at this point - to
get the >=4.1.79 or SVN versions of KDE, you just need to use the
kde-crazy overlay, which works with any EAPI-2-compatible PM. (-4.1.79
is keyworded ~arch, -9999 needed to be keyworded "**" in p.kewords, and
- -4.1.80 is p.masked until it is released upstream)

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkpLm8ACgkQOypDUo0oQOpXPACghooSyqU9xfJY63YrFl9WdXlm
AS4AoM9/NH8pjLnAxeHn424YYn5On6DQ
=oa4L
-----END PGP SIGNATURE-----

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ABCD wrote:
> Duncan wrote:
>> I've chosen not to try the not-full-releases since I gave up on the betas
>> earlier.  Additionally... well let's just put it this way, paludis, no
>> way, no how, so that has been another encouragement not to do the KDE SVN
>> stuff since the Gentoo/KDE folks started requiring paludis for it.  Thus,
>> I'm sticking with 4.1.x since that's what's released.
> 
> The paludis requirement has been completely dropped at this point - to
> get the >=4.1.79 or SVN versions of KDE, you just need to use the
> kde-crazy overlay, which works with any EAPI-2-compatible PM. (-4.1.79
> is keyworded ~arch, -9999 needed to be keyworded "**" in p.kewords, and
> -4.1.80 is p.masked until it is released upstream)
> 
...I meant 4.1.73, not .79...

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkpN8gACgkQOypDUo0oQOpDEQCcCOjCjf183jrXU+ATdvlCS0/d
ARkAnR07OWuJ2Jji0Fin11+Gcm21pLoM
=tfcu
-----END PGP SIGNATURE-----

Re: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Beso]

2008/11/23 ABCD <en.ABCD@gmail.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Duncan wrote:
>> I've chosen not to try the not-full-releases since I gave up on the betas
>> earlier.  Additionally... well let's just put it this way, paludis, no
>> way, no how, so that has been another encouragement not to do the KDE SVN
>> stuff since the Gentoo/KDE folks started requiring paludis for it.  Thus,
>> I'm sticking with 4.1.x since that's what's released.
>
> The paludis requirement has been completely dropped at this point - to
> get the >=4.1.79 or SVN versions of KDE, you just need to use the
> kde-crazy overlay, which works with any EAPI-2-compatible PM. (-4.1.79
> is keyworded ~arch, -9999 needed to be keyworded "**" in p.kewords, and
> - -4.1.80 is p.masked until it is released upstream)
>
this is not the genkde overlay based on kdebuild system. this system
is still usable only
on paludis. i can say that in some way it's a little better than the
old eapi system but
still, the non ability for binpkg of paludis is bad when you have
issues mainstream,
and in a development svn you'll most likely to have them at least once
every two weeks.
so paludis forces you to manually resync for a previous version and
hope it works. sometimes
you might end up doing more than one resync per package, and for big
ones like amarok, k3b
kdepim is meaning a lot of headache. at lest with binpkgs you can
always revert back when
something is not working.




-- 
dott. ing. beso

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

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 of
>>> 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 very
>>> practical.
>>>
>> if you could post the script it would be interesting.
> 
> I'll post the script in a separate reply...

OK, here it is, as a UUEed attachment below the sig, filenamed 
"set-display".  As I do the list as a newsgroup thru gmane using pan, 
which doesn't handle posting attachments, I use a script setup as pan's 
external editor to do the encoding and attaching.  Unfortunately, that 
limits the encoding choices to UUE and "identity" (which means simply 
attach it as text).  I hope gmane takes small attachments.  If not, I'll 
retry with it inline.

If you're familiar with xrandr, it should be pretty easy to follow and 
modify as necessary for your setup.  The default no-parameter action is 
to set both panels to 1920x1200, stacked, my native resolution, so unless 
your monitors can handle that, don't try running it as-is without a 
parameter.  If you feed it a parameter it doesn't recognize, or the usual 
-h or --help, it'll spit out some help.

Taking a look at the script code, you can see several of the possible 
settings commented.  These were valid back on my old CRTs, but aren't 
valid on my current setup.

As I said, if you're familiar with xrandr, changing it for your setup 
should be pretty simple.  I didn't bother with a config file for it, but 
the main variables are all set at the top and reasonably abstracted.  
Beyond that, you'd need to change the resolutions themselves, but the way 
it's setup that's fairly easy.  I've already done it once myself, when I 
switched to the dual LCD panals from my former CRTs.  Given the 
abstraction, it shouldn't even be /that/ hard to alter it to deal with 
two monitors side by side instead of stacked, tho I obviously designed it 
with stacked in mind.

If it worked the way the xrandr documentation says it should, those lines 
of fancy math would set the position origins to always center the 
viewport, which would grow or shrink in a constant framebuffer.  That is, 
with stacked monitors and given my constant framebuffer size ($fb) of 
1920x2400,the midline separating the two monitors would always remain the 
same, x,1200, with the horizontal midpoint of the monitors also remaining 
constant at 960,y, thus the constant midpoint, regardless of chosen 
resolution, would remain 960,1200.

As I said in my initial post, however, the viewport positioning code 
doesn't seem to work on at least my radeon 92xx series video card with 
the xf86-video-ati radeon driver.  The resolution changes work, but the 
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 
way, if I run it from a terminal window (konsole, of course, since I'm a 
KDE guy, situated far enough to the upper left that when I change 
resolution I can still see it!!), I can see what the actual xrandr 
commands issued are, along with the results, since I set verbose as 
well.  That's fine since I don't normally run it from konsole anyway, but 
rather from the kmenu, as invoked by hotkey.  (As I said, I hotkey invoke 
nearly /everything/ I use regularly enough to remember a sequence for, in 
kde3, thus its brokenness in kde4 in practice means the entirety of kde4 
is broken, so far.  But that's supposed to be fixed for 4.2...)  So when 
I run it from konsole and get the output, it's because I'm 
troubleshooting and /want/ the output.

If you run the script with -h (or look at the code), you can see the 
<size> parameter in both short and long forms corresponds to the x 
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 
four corners (with the crystal icon theme at least).

The hotkey would be XF86HomePage,F8 (XF86HomePage just because it's one 
of the extra buttons on this Logitech keyboard, used here to launch a 
menu with a bunch of different secondary key options, in this case F8, to 
launch set-display to set 800 width).

The set-display 19-6 option is set with a kmenu title of 
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 
knew about the above positioning bug), was after I got this script 
switching and centering correctly, I'd create another script that I could 
invoke to incrementally pan position, say 100 px at a time in the desired 
direction.  (I intended to experiment with the increment, but obviously 
when the positioning failed to work, I never got that far.)  Then I could 
have invoked the panning script (hotkeys again!) to move the viewport 
around the framebuffer as necessary, giving me back at least a crude 
version of the panning ability the old merged framebuffer driver had, 
before the switch to xrandr.

Hopefully the positioning code will work either on newer radeon hardware, 
or at least on other brands and therefore other drivers.  If it does and 
someone wants those panning scripts, I could probably whip them up 
without too much trouble.

Meanwile, as I believe I mentioned, I was scanning the xorg mailing list 
and saw a discussion of the schedule and features for the next xorg 
release. (BTW, the latest xorg-server release, 1.5.3, isn't in the Gentoo 
tree yet, even masked.  It's probably in the xorg overlay...)  It's 
supposed to finally have panning again, which will be nice.  Then the 
xrandr viewport positioning won't matter so much since you can just pan 
it to where you want.

Once again, don't run this without either the -h/--help option or 
modifying it to fit your dispaly hardware, first.

Now... will the attachment post?

-- 
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)A<V@*<STD>S$Z+3!]"0DC(')E<75E<W1E9"!S:7IE(&9A8W1O
M<B!O<B!H96QP('1R:6=G97(L(&1E9F%U;'0@:7,@(C`B"F9B/3$Y,C!X,C0P
M,`D)(R!T;W1A;"!F<F%M96)U9F9E<B!S:7IE"FUT/59'02TP"0DC(&UO;FET
M;W(M=&]P"FUB/41622TP"0DC(&UO;FET;W(M8F]T=&]M"F\]+2UO=71P=70*
M;3TM+6UO9&4*<#TM+7!O<PIV/2TM=F5R8F]S90IF/2TM9F(*8STB)'8@)&8@
M)&9B("1O(@DC(&-O;6UO;B!P87)T:6%L(&-O;6UA;F1L:6YE"@IH96QP='AT
M*"D@>PH)96-H;PH)96-H;R!5<V%G93H@(B1[,",C*B]](%LM:'PM+6AE;'!\
M/'-I>F4^72(*"65C:&\*"65C:&\@(E-E=',@6"!D=6%L+61I<W!L87D@<VEZ
M92!W:71H:6X@82!F<F%M96)U9F9E<B!O9B`D9F(N(@H)96-H;R`B56YL97-S
M(&]T:&5R=VES92!S=&%T960L(&UO;FET;W(@;W)I96YT871I;VX@:7,@<W1A
M8VME9"PB"@EE8VAO(")M;V1E<R!D=7!L:6-A=&5D+"!A;F0@<&]S:71I;VX@
M8V5N=&5R960@:6X@=&AE(&9R86UE8G5F9F5R+B(*"65C:&\*"65C:&\@(CQS
M:7IE/B!M87D@8F4@;VYE(&]F.B(*"65C:&\@(B`@("`Q.7PQ.3(P?#`Z("`@
M("`@("`@("`@(#$Y,C!X,3(P,"!E86-H+"`@(#$Y,C!X,C0P,"!T;W1A;"`H
M9&5F875L="DB"@EE8VAO("(@("`@,39\,38P,#H@("`@("`@("`@("`@("`Q
M-C`P>#$R,#`@96%C:"P@("`Q-C`P>#(T,#`@=&]T86PB"B,)96-H;R`B("`@
M(#$R?#$R.#`Z("`@("`@("`@("`@("`@,3(X,'@Y-C`@(&5A8V@L("`@,3(X
M,'@Q.3(P('1O=&%L(@H)96-H;R`B("`@(#$P?#$P,C0Z("`@("`@("`@("`@
M("`@,3`R-'@W-C@@(&5A8V@L("`@,3`R-'@Q-3,V('1O=&%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>#<V."`@=&]T86PB
M"B,)96-H;R`B("`@("`T?#0P,#H@("`@("`@("`@("`@("`@(#0P,'@S,#`@
M(&5A8V@L("`@(#0P,'@V,#`@('1O=&%L(@HC"65C:&\@(B`@("`@,WPS,C`Z
M("`@("`@("`@("`@("`@("`S,C!X,C0P("!E86-H+"`@("`S,C!X-#@P("!T
M;W1A;"(*"65C:&\*"65C:&\@(B`@,3DM-GPQ.3(P+38T,#H@("`@("`@("`@
M(#$Y,C!X,3(P,"`@=&]P+"`@("`V-#!X-#@P("!B;W1T;VT@*'!O<VET:6]N
M960@;&5F="DB"@EE8VAO"@EE>&ET"GT*"B,@;71M/21M="UM;V1E+"!M='`]
M)&UT+7!O<VET:6]N+"!M8FT])&UB+6UO9&4L(&UB<#TD;6(M<&]S:71I;VX*
M(R!D969A=6QT<R!B=70@9F]R(&UT;2!S970@8F5L;W<*8V%S92`D<R!I;@H)
M,3E\,3DR,'PP*0EM=&T],3DR,'@Q,C`P.SL)"2,@9&5F875L=`H),39\,38P
M,"D);71M/3$V,#!X,3(P,#L["B,),3)\,3(X,"D);71M/3$R.#!X.38P.SL*
M"3$P?#$P,C0I"6UT;3TQ,#(T>#<V.#L["B,).7PY-C`I"0EM=&T].38P>#<R
M,#L["@DX?#@P,"D)"6UT;3TX,#!X-C`P.SL*"39\-C0P*0D);71M/38T,'@T
M.#`[.PHC"35\-3$R*0D);71M/34Q,G@S.#0[.PHC"31\-#`P*0D);71M/30P
M,'@S,#`[.PHC"3-\,S(P*0D);71M/3,R,'@R-#`[.PH),3DM-GPQ.3(P+38T
M,"D);71M/3$Y,C!X,3(P,#MM8FT]-C0P>#0X,#MM='`],'@P.VUB<#TP>#$R
M,#`[.PH)*BD)"6AE;'!T>'0[.PIE<V%C"@HC(%-E="!T:&4@9&5F875L=',@
M8F%S960@;VX@)&UT;2!I9B!N96-E<W-A<GD*(R`D;71P+VUO;FET;W(M=&]P
M+7!O<VET:6]N(&1E9F%U;'1S('1O(&)O='1O;2!C96YT97(@;V8@=&]P(&AA
M;&8*(R!O9B!F<F%M96)U9F9E<BP@<V\@8V]M8FEN960@9&5F875L="!P;W-I
M=&EO;B!W:6QL(&)E(&-E;G1E<F5D+@HC('@H*'@@;V8@)&9B(&UI;G5S('@@
M;V8@)&UT;2D@+S(I(")X(B!Y*'D@;V8@)&9B("\R(&UI;G5S('D@;V8@)&UT
M;2D*6R`D;71P(%T@?'P@;71P/20H*"`D*"@@)'MF8B5X*GT@+2`D>VUT;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=&]R+6)O='1O;2UM;V1E(&1E9F%U;'1S('1O("1M=&T*
M6R`D;6)M(%T@?'P@;6)M/21M=&T*"B,@)&UB<"]M;VYI=&]R+6)O='1O;2UP
M;W-I=&EO;B!D969A=6QT<R!T;R!B96QO=R`D;70*(R!X*'@@;V8@)&UT<"D@
M(G@B('DH>2!O9B`D;71P('!L=7,@>2!O9B`D;71M*0HC("AS:6YC92!O=F5R
M86QL('!O<VET:6]N(&1E9F%U;'1S('1O(&-E;G1E<F5D+"!Y('=I;&P@9&5F
M875L="!T;R!C;VYS=&%N="D*6R`D;6)P(%T@?'P@;6)P/21[;71P)7@J?7@D
M*"@@)'MM='`C*GA]("L@)'MM=&TC*GA]("DI"@IS970@+7@*>')A;F1R("1C
M("1M="`D;2`D;71M("1O("1M8B`D;2`D;6)M"F5C:&\*>')A;F1R("1C("1M
M="`D<"`D;71P"F5C:&\*>')A;F1R("1C("1M8B`D<"`D;6)P"F5C:&\*>')A
B;F1R("1C("1M="`D<"`D;71P("1O("1M8B`D<"`D;6)P"@``
`
end

Re: [gentoo-amd64] kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Beso]

2008/11/23 Duncan <1i5t5.duncan@cox.net>:
> New thread, since the topic wandered from what it was on the old one.
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560811221559h2762345eq6e13c03bf0e6588@mail.gmail.com, excerpted
> below, on  Sat, 22 Nov 2008 23:59:53 +0000:
>
>> 2008/11/22 Duncan <1i5t5.duncan@cox.net>:
>
>>> FWIW, I tried the kde3 krandr-tray applet and it appears to be
>>> outdated, only handling randr-1.0 commands.  I suppose kde4 has an
>>> updated version with the 1.1 and 1.2 commands.  I do have kde4 merged
>>> now, but it's still broken in enough ways I don't use it for everyday
>>> yet.
>>>
>>>
>> well, the system-settings one seems to work quite well for me. it's true
>> that dual head is a little tricky with kde (most of the time makes
>> plasma crash without setting the dual head). also i'm using the 4.2
>> development brach (plaudis kdebuild overlay) that seems to be
>> a little better in terms of usability and functionality than the portage
>> 4.1.3 version.
>
> Yes.  I think their choice of versioning sucked.  For quite some time I
> and others have argued 4.0 should have been 3.8 (developer base and
> technology preview for 4.0), 4.1 should have been 3.9 (public release
> preview for 4.0), and what is 4.2 should finally make the first decent
> 4.x full release, what should have been 4.0.
>
well, 4.0 wasn't even half usable, but only something for bugtesting.
it has been
really awful. the 4.0.x serie has been a real mess. i can see them only as
alpha previews. the 4.1 series in my opinion look like a beta version with a
lot of lacking or not working stuff. now i can see that the 4.2 is almost there.
kwin opengl effects work quite well, most of the apps have been transferred or
are on their way, finally khotkwys works a little more (this one
pissed me off quite
a lot). this way of versioning has also made some kde users to migrate to other
guis like gnome of xfce.

> I've chosen not to try the not-full-releases since I gave up on the betas
> earlier.  Additionally... well let's just put it this way, paludis, no
> way, no how, so that has been another encouragement not to do the KDE SVN
> stuff since the Gentoo/KDE folks started requiring paludis for it.  Thus,
> I'm sticking with 4.1.x since that's what's released.
>
well, i've been back with portage 4.1.2 and 4.1.3 but it lacks stuff
and i don't have
time to set up the ebuilds for what i need. also the 4.2 plasma is a
little more stable
than the 4.1.3 one. what i really lack is koffice that doesn't really
have an ebuild.

> But you're right on plasma.  It still isn't working quite right, in
> general.  It's supposed to let one zoom the desktops, and I can sort of
> do that, but once they get zoomed out, getting them to zoom back in
> /reliably/ has been a problem.  Sometimes plasma crashes, sometimes they
> zoom in but only on one panel's display, sometimes they zoom in but get
> stuck half on and half off the display... it's a mess!
>

sincerely i haven't really understood that zoom function. if you try
to place something
outside the desktop area, when plasma doesn't crash you won't be able
to find it on
any of the virtual desktops you have. also the dashboard looks good
but when you put
a widget on it and then you close it the widget sticks on your
desktop. the ideas behing
are good but i think they've put too many features together without
finishing them.

> Add /that/ to the fact that khotkeys seems to be broken, or at least
> trying to assign anything but default hotkeys to anything fails to work,
> AND that khotkeys is the main way I launch stuff in kde3.
>
this is really true. in fact at some point the hotkeys totally
disappeared... :-(

> Add /that/ to the fact that most of the fancy new effects require opengl,
> they don't work with composite and etc, the other option, but
> unfortunately they don't disable or otherwise indicate the ones that
> don't work, and opengl is limited to 2048x2048 on the radeon 92xx series
> and I'm running 1920x2400 so opengl doesn't work well, or at all in the
> lower 352 px of display, and kde4 has so far been too broken to seriously
> use.
>
the kwin effects now work quite well and don't really crash very
ofthen. the only
problem i find out is i need strigi installed. and if you have it
running it will kill
processor, ram and disk space and you'd have kwin crash sometime.

> I'll post the script in a separate reply...
>
ok, thanks.

>>> The point being that yes, dual-panel works with the freedomware xf86
>>> ati/ radeon driver, at least for my hardware, once it's configured to
>>> do so. However, there are some limitations.
>>>
>> i'll try out to see these days how the fglrx driver works with dual
>> head. i've read that it does behave in quite a good manner. also,
>> now that it has uvd and basic xvmc included i could also think to go
>> back with it. the only problem is xorg compatibility.
>
> As you know I won't even consider the proprietary drivers, here.  I had
> my fill with nVidia, and vowed never again.  Plus, every time xorg adds
> something new, it's the proprietaryware folks that hold it back, by
> months, nearing a year sometimes, from stabilizing.  I /do/ believe KDE
> got it right on that one, not waiting up for nVidia to catch up, simply
> telling folks using the nvidia driver that they'd have a seriously broken
> experience due to their choice of hardware and proprietaryware driver
> that couldn't keep up.
>
well, after merging it today i found out that it still doesn't support
xorg 1.5.2
(it's a blocker for it) so it seems that for now i cannot have that compare.

> As for ATI/Radeon, at some point the new freedomware drivers should in
> general catch up, now that AMD has opened the specs.  I've been waiting,
> as I'd really like to upgrade this 9200.  Apparently the r5xx chips have
> a 4096x4096 virtual 3D area, and it'll be nice getting dual DVI dual-
> link, too, instead of settling for the single single-link DVI and single
> analog that my current 92xx series has.
>
well, radeon is quite reliable and speedy. radeonhd instead it doesn't seem very
good, at least on playing video content. to have the best radeon
experience you'd
have to go with the git version of xorg and drivers. the x11 overlay
is very good
and stable, but it seems that it has some problems wih kde4, especially with
semantic-desktop enabled (which is now about mandatory to have plasma-workspace
to compile).

>>> We should probably start a new thread on that if people want to discuss
>>> the config and how I got it to work.
>>>
>> this would be really interesting.
>
> That'll be another post as well.
>
by the way i'm still waiting for the kernel upgrade script post... :-)

-- 
dott. ing. beso

Re: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Beso]

2008/11/23 Duncan <1i5t5.duncan@cox.net>:
> 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 of
>>>> 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 very
>>>> practical.
>>>>
>>> if you could post the script it would be interesting.
>>
>> I'll post the script in a separate reply...
>
> OK, here it is, as a UUEed attachment below the sig, filenamed
> "set-display".  As I do the list as a newsgroup thru gmane using pan,
> which doesn't handle posting attachments, I use a script setup as pan's
> external editor to do the encoding and attaching.  Unfortunately, that
> limits the encoding choices to UUE and "identity" (which means simply
> attach it as text).  I hope gmane takes small attachments.  If not, I'll
> retry with it inline.
>
the script came out well. you just have to selct the part from begin
to end, copy it
in an external file and then do an uudecode on it. i'm now having a look at it.
if you put your fb as a line input for the script it would be more adaptable
than is now. but it's a good script. i think i'll attach it over a
hotkey. if i manage to
have it attached to a hal event it would be even better...
thanks for it.

-- 
dott. ing. beso

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811230303g48cd3972mab017762f95ee51@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 11:03:36 +0000:

> non ability for binpkg of paludis

I've wondered about that.  binpkg is a seriously used feature here, even 
with just a single machine (well two now, but the second isn't running 
Gentoo yet), as it plays a big part in both my backup and troubleshooting 
routines.  I've long argued that FEATURES=buildpkg is one of the most 
undersold great features of portage, particularly since at its core it's 
a simple bzip2ed tarball with a bit of extra data tacked on the end, so 
it's easily worked with using virtually any *ix based archiver tools you 
might prefer for exploration and/or extraction, emergency or otherwise.

But as I've always said, he who writes the code, calls the shots, and 
those writing the paludis code obviously don't consider binpkgs that 
important, so the feature has yet to be implemented.

Of course that has nothing to do with why I won't let it touch my system, 
despite my extremely high respect for the devs' technical abilities.  I'm 
trying my best to stay nice here...

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

Re: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Beso]

2008/11/23 Duncan <1i5t5.duncan@cox.net>:
> Beso <givemesugarr@gmail.com> posted
> d257c3560811230303g48cd3972mab017762f95ee51@mail.gmail.com, excerpted
> below, on  Sun, 23 Nov 2008 11:03:36 +0000:
>
>> non ability for binpkg of paludis
>
> I've wondered about that.  binpkg is a seriously used feature here, even
> with just a single machine (well two now, but the second isn't running
> Gentoo yet), as it plays a big part in both my backup and troubleshooting
> routines.  I've long argued that FEATURES=buildpkg is one of the most
> undersold great features of portage, particularly since at its core it's
> a simple bzip2ed tarball with a bit of extra data tacked on the end, so
> it's easily worked with using virtually any *ix based archiver tools you
> might prefer for exploration and/or extraction, emergency or otherwise.
>
> But as I've always said, he who writes the code, calls the shots, and
> those writing the paludis code obviously don't consider binpkgs that
> important, so the feature has yet to be implemented.
>
> Of course that has nothing to do with why I won't let it touch my system,
> despite my extremely high respect for the devs' technical abilities.  I'm
> trying my best to stay nice here...
>
well, i don't want to start up a flame, but with portage i had very often issues
with having the deps discovered in the right way. of course when the system
is up and running this isn't so much of a trouble, but when you set it
up or when
you do an upgrade that still has quite some deps discovered then the problem
is to be seen. of course the hour it takes paludis to build a dual core with 4
compilation jobs is to be considered. portage only takes less than 30secs to
upgrade. well, anyway, i always find good having at least 2 working package
installers on my system so that i can see out bugs for one or the
other. also not
using the binpkg feature if one of then fails then the problem is quite big.

-- 
dott. ing. beso

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811230324r6f2d2a31p74a546e8be289cd2@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 11:24:23 +0000:

> by the way i'm still waiting for the kernel upgrade script post... :-)

Well, I had made an assumption that proved true for changing kernel 
versions at the time, but invalid over the longer term.  Specifically, I 
had the scripts copying over the outputdir (which I set so the sources 
themselves stay clean, everything I've done is in the outputdir), so a 
new build would only have to rebuild where the code had changed.  Well, 
all that broke early in the 2.6.27 series, between rc1 and rc2, when x86 
moved its headers around.  For several rcs I was unable to compile at 
all, until I figured out it was still trying to use the old headers 
from .26, mixed up with the ones from .27!  That was NOT working!

So, I had to figure out the problem (which early on I thought might be 
the scripts, it was, but not quite as I expected), then fix the scripts 
so they cleared the outputdir properly (while still saving and 
transferring the .config in the same dir), then test my changes thru 
several rcs...

Meanwhile I found a real bug late in the .27 development cycle and was 
pressed to bisect it, learning a bunch about git and git bisect in the 
process... and updating my scripts with git versions... all within only a 
couple weeks before target release, since I hadn't been able to test 
earlier since I couldn't compile.

Oh, and along in there I typoed a variable name and a script that was 
supposed to clean the outputdir in my git version, instead tried to 
"clean" /!  Yes, I brown-bag-errored a rm -rf /!  Fortunately I caught it 
before it got thru with /home, but unfortunately after it killed /bin, 
/dev, /etc...  But fortunately my backups weren't too out of date.  
Still, I had to recover in the middle of that already time-pressed bisect 
cycle.  But I did, and I finished the bisect, thereby tracing the problem 
to a single commit, and they figured out the problem and patched it 
before 2.6.27 release.

And I found a bug to bisect in the .28 rc series as well.  It was keeping 
my machine from properly hibernating, which meant after every failed test 
during the bisect cycle, there was a good chance the RAID-6 wasn't synced 
at the crash, and I had it doing the resync when I rebooted.

But it's all working relatively good again now... and I'm getting back to 
trying to catch-up on all these things! =:^)

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

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811230338m78e3f60bg40754ac934ea0025@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 11:38:54 +0000:

> if you put your fb as a line input for the script it would be more
> adaptable than is now. but it's a good script.

Well, there's a balance between simple and adaptable.  One of my goals 
was to keep the number of parameters to a minimum.  However, if I had 
really intended it for public use (as I've basically setup my kernel 
scripts to be, now), I'd have setup a config file and read the 
framebuffer size from it.  Of course, I'd have the various resolution 
choices setup in the config file as well, if I were doing it that way, as 
well as the various xrandr output interface names (VGA1, DVI1, etc).  I'd 
have abstracted out the stacked relationship to the config file as well, 
making side-by-side and option, and may have allowed setting the default 
position to the four corners and centered on the four edges (much like 
kde3's kicker panel positions), as well as centered and possibly 
arbitrary, as well.

But when the positioning thing didn't work I kind of lost my motivation, 
as I could neither fully debug it nor use it as intended, so I didn't do 
much to it after that, except update the hard-coded resolutions for my 
pair of LCDs, when I got them.

But... it's a reasonable start (proof of concept, working demo) for 
someone with reasonable bash skills, who has a system where the xrandr 
position functionality works as documented, so he can test and debug if 
necessary that bit of it.  Feel free! =:^)

BTW, I didn't document it when I posted, but consider that script to be 
in the public domain.  That gives anyone who wishes to improve it the 
freedom to choose whatever license they want (preferably freedomware, of 
course, maybe MIT, since that's the license xorg uses and it'd be rather 
pointless without that), for their improved version.

> i think i'll attach it over a hotkey. if i manage to
> have it attached to a hal event it would be even better... thanks for
> it.

I hadn't thought about a hal event... Interesting idea, tho my 
configuration here is a reasonably stationary desktop, so there's little 
reason to think of the hal trigger.  But maybe when I get my netbook 
(Acer Aspire One) setup with Gentoo... we'll see.

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

[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811230356l13b249cfm8fd974dfc493b094@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 11:56:36 +0000:

> with portage i had very often issues with having the deps discovered
> in the right way. of course when the system is up and running this
> isn't so much of a trouble, but when you set it up or when
> you do an upgrade that still has quite some deps discovered then the
> problem is to be seen.

Hmm... I've never had a major problem in that regard.  At least not since 
my initial from-stage-one installation back with 2004.0 (first try) 
and .1 (actual success).  But portage is so changed since then it's 
really not worth considering, and it could have just as easily been my 
goofs, I know I was learning a quite a bit as I went, or bad ebuilds.  
Other than that, there has been perhaps an occasional minor niggle, but 
nothing someone running ~arch shouldn't expect from time to time and be 
able to work out or revert to a working version (perhaps the known 
working version on the rootbak image, snapshot taken when the system was 
in known bootable and reasonably stable condition) should it be necessary.

Personally, however, I suspect that stable isn't really that much more 
stable than ~arch, and the fact that my portage stub-scripts for @world 
and @system all use -aNuDv so I get a preview, deep dependencies don't 
get behind and USE flag changes get managed right away, plus routine use 
of revdep-rebuild and --depclean, possibly none of which those on stable 
are likely to do regularly let alone religiously, has a lot to do with my 
relatively smooth ride, even on ~arch.

> well, anyway, i always find good having
> at least 2 working package installers

I saw that point made a few days ago and thought it was a good one.  Of 
course, if I were to do it given my stated position, I'd be merging 
pkgcore instead.  However, I've a decent enough familiarity with portage 
that in some cases at least, it's easier to actually work the problem, 
than it would be to learn my way around a second PM.

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