[kde-linux] Re: Panel widgets alwais to the left

[Duncan]

Alex Schuster posted on Sun, 24 Apr 2011 04:43:35 +0200 as excerpted:

> Duncan writes:
> 
>> Alex Schuster posted on Wed, 20 Apr 2011 16:49:01 +0200 as excerpted:
>> 
>>> KMS, right... another thing to try. So I did, I built an identical
>>> kernel, except that KMS was off. BTW, is there an option to toggle
>>> this by a boto parameter, like 'nomodeset' to diable the gallium
>>> stuff?
>> 
>> There is, assuming "boto" means boot...

FWIW when I first saw that, I thought it was an untranslated word from 
some other language or dialect, thus the comment.  Now that I look again, 
it was probably just a typo.  Sorry for making it a bigger deal than it 
was/is.

>> Actually, nomodeset is it, AFAIK.  That turns of kernel-modesetting.

> Yes, I got it wrong. KMS is deactivated with nomodeset, while I toggle
> gallium usage for the various drivers with Gentoo's 'eselect mesa'
> command.
> 
> I made progress. Tried KMS again, that is, without nomodeset kernel
> parameter. And with a new kernel, where I deselected all framebuffer
> stuff I could. there was not much activated, only vga16 I think.
> This time, I got no crash at startup. Instead, I got a nice small font
> instead of the normal text mode. Nice!

You got it working, then!  The bit about unsetting the kernel's radeon 
framebuffer option to get kms is rather counterintuitive, to the point 
that I found it difficult to do (to the point that I was resisting impulse 
and intuition to do it) even understanding that kms uses its own 
framebuffer mechanism for CLI mode and thus doesn't need the radeon 
framebuffer, but if it works...

> I had some weird effects. Like, after X started, I switched back to the
> text console, and no longer had the small font console, but a screenshot
> of how it looked just before the mode switched. This went away after a
> little switching to and back from X.

Yeah, that sort of minor "texture" artifacting is typical of acceleration 
done correctly, but missing a repaint trigger somewhere.  In normal 
operation, only the changed areas of the buffer get updated, and switching 
between X and a CLI /should/ trigger a repaint of the entire buffer, since 
it has all changed, but sometimes the change detection gets missed and the 
buffer isn't repainted until the next change.

The reason for the "texture" bit above is that in modern 3D hardware, even 
traditional 2D and text graphics are handled as emulation by the 3D 
hardware, as opposed to the previous 2D dedicated hardware.  In games, 
etc, small areas are mapped as 2D bitmapped textures, with effects 
overlaid and motion, changing of viewing angle, etc, accomplished by 
matrix manipulation of the 2D textures.  (OpenGL and RandR zooming, 
scaling, and "keystoning" (think an old overhead projector image on a 
screen at an angle, the near side is projected smaller than the far side 
-- "keystoning" is adjusting for that in software/hardware, in this case 
using the 3D hardware to manipulate the 2D texture using matrix math) are 
all accomplished using the same hardware matrix manipulation methods used 
millions of times a second on much smaller textures, to render the 3D 
effects in games.  Compositing is then the process of rendering several 
layers of these things, some occluding parts of others, with scene point-
lighting processed as yet more layers to render shadows, shading, etc, 
into a composite whole, which can then either be block-transferred to the 
main framebuffer, or in yet another bit of acceleration, "page-flipped", 
so the screen is now drawn off of the just rendered new buffer instead of 
the old one (which is now the buffer being rendered into for the next 
frame).

That's a very basic description of the rather more complicated process 
going on, but it should be reasonably accurate at the level described.

What's fascinating for me is to see all the clever ways hardware 
originally intended for one use, accelerated 3D, is now being put to a 
rather different use, window-on-window transparency by using the same 
compositing hardware, blur effects, inverting (used for explosion strobe 
effects in games), scaling as used in the grid and zoom effects, scaling 
and rotation as used in the cube effect, shading and shadows as simply 
another layer in the composite, keystoning and rotation using the same 
matrix math effects as used to process 2D textures into a 3D object such 
that the view angle changes as the object rotates, etc.  I understand none 
of this at the low level, but just the high level glimpse of how it's all 
done is fascinating enough!

Meanwhile, I've not seen the whole-framebuffer screenshotting effect you 
mention, but I do use the zoom effects rather regularly, and sometimes see 
a bitmap/texture originally from a zoom, show up later as a new app starts 
up, when its frame is first painted before the app has actually rendered 
into it, thus erasing the previous content.  The most common app for this 
is plasma-desktop, which I terminate and restart occasionally, because 
it's easier to do that to fiddle with turning off the always-on-top on one 
of my panels, temporarily.  But with the two wallpapers (dual monitor) and 
all the widgets, including several yasp-scripted system-monitor type 
widgets that must initialize and gather their first data sample before 
they can properly render, plasma takes a bit to fully initialize, and for 
a second or two, the system paints the old content of that video memory, 
often previously zoomed content (but chopped up and line inter-mixed as 
the pitch, that is, the width of the bitmaps is different).  It really 
/should/ force-zero the new memory before rendering it to screen, as that 
could get a bit uncomfortable if the previous content isn't appropriate 
for the current audience, but it's so distorted and line-mixed that 
probably only the one who viewed the previous content will recognize it.

> Compositing was disabled, because of missing firmware. I had to install
> x11-drivers/radeon-ucode and enable some firmware options in the kernel
> (mnore detail in the bug report [*]), and now it is working. With less
> CPU usage for X than I had with the fglrx driver. Working KDE desktop
> effects, and no crashes.

You forgot your footnote. =:^( It's a common thing to do.  I finally 
developed the habit of paging thru the quote to the bottom and typing the 
footnote immediately, then paging back up, so as not to forget it.  Same 
with attachments, BTW, except that some clients (kmail =:^) are now smart 
enough to scan for the word "attachment" and warn you if you try to send 
the message without one, if they see it.  You can of course override the 
warning if the word was used in discussion, as here.)

Yeah.  I remember when the firmware was first required.  The first kernel 
or two with radeon kms (back when the option was still in staging) didn't 
require the firmware, and when it became a requirement, I had to go dig it 
up.  But rather than install a package, I simply googled the firmware the 
kernel complained about missing, copied just that file into the 
appropriate directory, and then experimented with the kernel options 
(being the first one, I didn't have the kernel options set for it before) 
until I got it to build-in.

Actually, there's two files required.  One had shipped with the kernel for 
quite awhile, tho they're gradually moving firmware out of the kernel and 
either have or will with it too at some point, the other was new, a bit of 
firmware I didn't have and that had never shipped with the kernel.  That 
was the one I had to google up.

> One problem remains: Quake3 is very slow, so opengl acceleration does
> not work correctly yet. That's bad, Quake3 is about the only game I
> play, but at least I have no graphics corruption like with Xorg 1.7, no
> crashes, no memory problem like with fglrx.

Yeah, the native kernel radeon-drm module isn't yet upto the performance 
levels of fglrx.  But it's coming.  FWIW, Michael Larabel at phoronix.com 
is the person/site that seems to follow developments there, the closest.  
lxer.com follows the entire Linux community rather well, including 
phoronix, and I in turn follow lxer via akregator feed, so even tho I'm 
not a gamer and won't touch non-freedomware drivers (but I draw the line 
at firmware and unlike Stallman and the FSF, don't worry too much about 
firmware, so have no problems with that required for KMS, for instance), I 
keep relatively informed on the status of both the closed and freedomware 
drivers for nvidia, ati and intel, all three.

As I said, they're getting closer, tho.  Making phoronix headlines 
recently was the fact that the newer freedomware nouveau drivers have 
actually caught up and in some cases surpassed the performance of nvidia's 
servantware drivers, for older nvidia hardware.  That's a /significant/ 
milestone, altho they're not close yet for newer hardware, nor for radeons. 
But the gap is beginning to narrow and that they've now pretty much 
matched performance for older nvidia hardware is a SIGNIFICANT milestone 
indeed! =:^)  (Regardless, I'd not buy nvidia on principle, until they 
actually start cooperating with the freedomware guys, but then, I'm not a 
gamer either, so...  But that's why I've only considered radeons for my 
main machine here, and have a well supported intel in my pre-poulsbo 
netbook.)

But speed isn't everything.  Stability counts for something too.  And if 
the fglrx driver was giving you issues there, plus holding you back on X 
upgrades...

>> Since unlike kms/ums, the difference between gallium and classic but
>> kms drivers is entirely X config, that can be set after boot, from
>> userspace, while kms cannot.  Presumably, you'd have xorg.conf.d
> 
> Hmm, is there anything I have to enable for gallium to be used? I
> thought with Gentoo I only have to 'eselect mesa 64bit r600 gallium'?
> Seems so, glxinfo reports Gallium being used or not, according to what I
> set. But it makes no difference here.

I expect that I miswrote, there.

With the r300-r5xx series radeons, the gallium driver is supposed to be 
superior to the classic driver now, but with the r600-r7xx series, 
including the rv730 powering my hd4650, gallium /was/ lagging.  I've been 
sort of waiting for a phoronix article covering 2.6.38 and the most recent 
xorg/mesa/ddx (ddx referring the xorg component of the driver, perhaps 
short for device-driver-X, basically xf86-video-ati in this context; it 
took me awhile to figure that out when I first saw the term) with r7xx 
series, to see how gallium compares now, but AFAIK as late as the 2.6.37 
era, it was behind classic for the r600-r7xx series.

As such and due to a problem I had with my first gallium experiments (I 
forgot what it was now, but it was enough to immediately quit X and eselect 
back to classic), I've not done that much with gallium and thus know 
rather less about it.  So while I knew it was a userspace config toggle 
not a kernel toggle, I wrongly placed its config where one would normally 
configure anything x related, in xorg.conf(.d).

It has been on my mental list to try gallium again, tho, and just now, I 
added to the list, to either find documentation online or examine the 
eselect mesa code to see what it's actually doing to switch between them, 
as I really don't know, but being the type of control and customization 
freak I am when it comes to computers, I'd certainly be FAR more 
comfortable knowing.

Actually, that probably has a lot to do with why I've not done more 
gallium experimenting already, too.  The eselect mesa mechanism is too 
obscure and mysterious for me, and I don't quite trust it as I don't know 
what sort of config changes it's actually making to my system, so as to 
recover from them if it screws up!  As such, my instinct is to leave 
what's working well enough alone, rather than risk a world of trouble in 
an area I don't understand well enough to be comfortable trying to recover 
from issues in.

But I have a kernel bug (something in the 2.6.39 pre-release series 
doesn't like my system... login/logouts and or tty/pty operations are VERY 
slow and often appear to hang) I've been chasing down, to finish chasing 
first, before I start screwing with my config somewhere else.  One thing 
at a time! =:^)

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