[kde-linux] Re: Panel widgets alwais to the left
- Date: Sun, 24 Apr 2011 21:05:43 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: [kde-linux] Re: Panel widgets alwais to the left
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
>> 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
>> 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'
> 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
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
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
>> 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
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.