Help: problem with X11 / XFree86-DRI ; who to blame?
by Rob
Hi,
My OS is an up-to-date version of Fedora 7 on a Intel based PC.
I use a particular academic/scientific video rendering software VMD
( http://www.ks.uiuc.edu/Research/vmd/ ).
This software uses GLX/Mesa heavily.
My day-to-day window manager is XFCE. When I use VMD, it immediately
freezes keyboard/mouse on my console as soon as any video rendering
activity occurs. The typical error message in /var/log/messages is:
kernel: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY --
rec: 147447 emitted: 147473
However, when I switch to KDE window manager, all this does not occur.
Obviously I first blamed XFCE, but the developers there are convinced
that the Xorg and/or related X11-video drivers are to be blamed.
Eventually I solved the problem: I disabled XFree86-DRI in the file
/etc/X11/xorg.conf.
Is there anybody who knows about this matter and can help me
understand what's going on?
I'd like to report this problem somewhere, but who is to be blamed?
XFCE ? (they deny)
Xorg ?
Fedora ?
XFree86-DRI ?
Thanks,
Rob.
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
16 years, 3 months
- 3
- 2
How to remove some mounted partition icons?
by Valent Turkovic
Hi,
I have Fedora 8 and on the gnome desktop I see some icons from my
partitions that I don't wan't on my gnome desktop.
I don't have a problem with having my storage partition on my desktop
but I also have also 4 other linux distos on my laptop and I see all
of their system partitions on my desktop!
I know that there is a way to disable ALL partition shortcuts but then
I wouldn't see my usb drives on desktop when I plug in usb flash
drives and I don't want that.
So how do I remove only the shortcuts I don't want from my desktop?
I saw an Ubuntu (which obviously also uses Gnome) trick which doesn't
work on fedora
On ubuntu only drives that are in /media are shown on the gnome desktop.
I edited /etc/fstab so that partitions I don't want on desktop are
mounted in /mnt - that worked on my Ubuntu but it didn't work in
Fedora
And ideas?
Thank you
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic
16 years, 3 months
- 12
- 36
gnome-pilot with Bluetooth sync
by Bastien Nocera
Heya,
I've built Matt Davey's work on gnome-pilot into a package. We (read Red
Hat) provided Matt with a Bluetooth-enabled Palm so he could do this
work, and he e-mailed me a couple of days after the Palm arrived with
patches, and a tarball of stuff to test. Unfortunately, I didn't have my
Palm to test this on holidays, so here it is a bit later than could have
been.
You'll need the latest pilot-link build with Bluetooth enabled:
http://koji.fedoraproject.org/koji/buildinfo?buildID=30826
After that, install those beta gnome-pilot packages:
http://people.redhat.com/bnocera/gnome-pilot-bluetooth/
1. Setup your PC as the BT hotsync device on your Palm:
Bluetooth → Setup Devices → PC Setup → Bluetooth Hotsync, and select
your computer in the list (make sure it's made visible in the Bluetooth
applet's preferences)
2. Add the Palm to the gnome-pilot setup:
Preferences → Hardware → PalmOS Devices
And enable some of the conduits
3. Ready to Sync! Go to Hotsync on the Palm, select your computer in the
drop-down, and click the sync icon.
Voila! You can use a tool like BTSync to make syncing more automated:
http://tinyurl.com/2wgnbf
Note that there is a known security problem with the Bluetooth backend:
http://bugzilla.gnome.org/show_bug.cgi?id=508315
This will hopefully be fixed before F9.
Cheers
16 years, 3 months
- 1
- 0
musings on session service mgmt
by David Zeuthen
Hi,
After investigating (please read the full report including links to
desktop-devel-list)
https://bugzilla.redhat.com/show_bug.cgi?id=427316
I realized what an incredibly poor state session service management is
in and what kind of hoops upstream authors jump through because neither
X11, nor xdg or GNOME has provided them with useful infrastructure. It
looks like KDE has _some_ kind of infrastructure for this.
There are basically two problems that we've been ignoring and hacking
around for as long as I've used Linux on the desktop
1. There is no good way of starting session services that needs to
export environment variables. While one may rightfully argue this is
utter crack in most cases, things like seahorse-agent demonstrates
that this is sometimes needed. Also, you surely need to do this for
the session message bus.
2. I think we've all experienced this one or more times; you log out
of your session and log back in. Wow, now things are weird or maybe
doesn't even work. The reason for this is that processes from your
old session keeps hanging around. In fact, I was bitten by this just
before the holidays; I simply couldn't login. Why? An old gconfd
process was lingering and that blocked login. The solution? Log in
as root on VT1 and do the usual 'killall -9 -u davidz' dance.
The latter problem is, I think, on the level of being a security bug.
The former is just hindering process and is making people build on top
of our platform (speaking in upstream sense here) do really crackful
things like rewriting your .gnupg/gpg.conf file.
I think with a little work we could fix this on the X11 level and
potentially get this upstream too. First, in Fedora we actually got a
rather decent way of solving 1.; see
https://bugzilla.redhat.com/show_bug.cgi?id=427316#c15
for the solution. Unfortunately, this a) isn't upstream; and b) isn't as
perfect as it needs to be. If you follow the flow, basically this
happens
/usr/bin/xinit
sources /etc/X11/xinit/xinitrc
sources /etc/X11/xinit/xinitrc-common
sources /etc/X11/xinit/xinitrc.d/*.sh
sets up SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION
does some weird stuff, then evals three variables above and,
essentially, execs gnome-session or startkde
Observations
a. Ideally SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION would just
use /etc/X11/xinit/xinitrc.d/. I'm told this is to make sure
things are reaped (because of problem 2. above)
b. It's annoying that the session bus is started after the stuff
in /etc/X11/xinit/xinitrc.d/ - no session bus for you.
c. No way to run code once the session is over.
Proposal
Assuming problem 2. will be magically solved for us (see below), we
could nicely rearrange the flow such that SSH_AGENT, DBUS_LAUNCH,
CK_XINIT_SESSION could just use standard constructs
in /etc/X11/xinit/xinitrc.d/.
Another observation is that only stuff using environment variables
should use /etc/X11/xinit/xinitrc.d/ (some man page should spell this
out) - everything else should use the XDG autostart spec (where we have
UI, e.g. gnome-session-properties).
Also, since we're talking about environment variables, we surely need to
care about the ordering; e.g. we want
00-ck-xinit-session.sh
01-dbus-session-bus.sh
10-ssh-agent.sh
10-seahorse-agent.sh
and so forth. Again, the man page should be clear about this. Also,
there should be a README file in /etc/X11/xinit/xinitrc.d/ that points
to the man page.
Instead of exec'ing gnome-session, we run it in the background. When we
are done we run the same scripts in reverse just with 'stop' instead of
'start' as the first positional parameter.
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it
does this is because of the way that ConsoleKit works. It basically will
just kill all the processes where the uid and the environment variable
XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few
seconds, it moves on to SIGKILL (e.g. -9).
(of course, any process can unset XDG_SESSION_COOKIE and then fork and
that way linger on. But no sane process would do that unless it's
hostile.)
All of this only includes modifying xorg-x11-xinit. We surely should get
this upstream.
The benefits?
- Things like seahorse-agent, ssh-agent and so forth now has proper
infrastructure to use. If we make the docs good enough we can point
people to these and hopefully people won't do horrendous things like
e.g. rewriting .gnupg/gpg.conf.
- We solve the decade-long problem of lingering processes after logout.
I think this is a pretty small project that could be done in a few days,
maybe a week. Any takers? Thoughts? Am I on crack?
David
16 years, 3 months
- 14
- 46