[gentoo-user] X broken; keyboard for sure, maybe dri
fe...@crowfix.com
the beginning of the X log. Unfortunately, I didn't save the previous
working log. This is ~amd64 under 2.6.30-gentoo-r1 and -r2.
I learned a while back I could get by without an X config. It swapped
a couple of the menu / alt / menu keys, but I adapted. Now X fills
its log with these "expected keysym, got XF86*" messages, and I have
no idea what causes them. Without X, it's hard to search the forums
and bugzilla to see how others have coped.
I suspect I have emerged or unmerged something I shouldn't have, but I
don't remember anything particular on this update / reboot cycle other
than LVM and the kernel change (2.6.30-gentoo-r1 to -r2), and reboot
with either -r1 or -r2 makes no difference that I can see.
There are two other problems. The "fb0" complaint has been there for
a while; I have to "sudo rm /dev/fb0" for X to work. The kernel has
the framebuffer configured, but I haven't investigated much because I
can get X working without /dev/fb0.
The "dri" line seems new, but might not matter. The display works.
The mouse works. It seems to be only the keyboard which is hosed.
But if someone knows how to fix the "dri" complaint, thanks.
=========== begin X log
X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.27-gentoo-r7 x86_64
Current Operating System: Linux crowfix 2.6.30-gentoo-r2 #1 SMP PREEMPT Sat Jul 4 14:07:08 PDT 2009 x86_64
Build Date: 20 December 2008 04:18:31PM
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Jul 4 17:47:02 2009
(EE) Unable to locate/open config file
New driver is "ati"
(==) Using default built-in configuration (30 lines)
(EE) Failed to load module "dri" (module does not exist, 0)
(EE) open /dev/fb0: No such file or directory
error setting MTRR (base = 0xfd000000, size = 0x00800000, type = 1) Invalid argument (22)
expected keysym, got XF86Battery: line 59 of inet
============= end X log
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe...@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
fe...@crowfix.com
> There are two other problems. The "fb0" complaint has been there for
> a while; I have to "sudo rm /dev/fb0" for X to work. The kernel has
> the framebuffer configured, but I haven't investigated much because I
> can get X working without /dev/fb0.
The log entry is
=====
Fatal server error:
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
=====
And I never investigated further because I didn't know where they
would be specified without a config file, and it works if I rm /dev/fb0.
walt
I started getting the same 'expected keysym' messages recently but my
X continues to work okay anyway, so I think that's a red herring.
I'd say check the dates on everything in /usr/lib/xorg and re-emerge
anything that's not very recent, especially evdev (which I assume you
use if you got rid of xorg.conf?).
You should have a /usr/lib/xorg/modules/extensions/libdri.so -- that's the dri
module that your X can't find. It's a symlink on my machine because I have
both the xorg and nvidia versions of opengl on my machine. The 'eselect opengl'
function is what creates the symlink to the correct version of libdri.so.
Is the 'ati' driver correct for your video card? Be sure to re-emerge that if
it is truly the right driver for you.
fe...@crowfix.com
> I started getting the same 'expected keysym' messages recently but my
> X continues to work okay anyway, so I think that's a red herring.
Everything else works, just the keyboard is hosed, and those keysym
messages sure seem suspiciously coincidental.
I did remerge things, and it made no apparent difference.
> You should have a /usr/lib/xorg/modules/extensions/libdri.so -- that's the dri
> module that your X can't find. It's a symlink on my machine because I have
> both the xorg and nvidia versions of opengl on my machine. The 'eselect opengl'
> function is what creates the symlink to the correct version of libdri.so.
I have no libdri.so anywhere on my system. Eselect shows nvidia and
xorg-x11; I tried both, it did change some symlinks, but never created
one for libdri.so. I didn't see any ebuilds for that. I also didn't
see any kernel modules for it. I also tried rebooting with 2.6.29-r5
and that made no difference.
> Is the 'ati' driver correct for your video card? Be sure to re-emerge that if
> it is truly the right driver for you.
Yep, some kind of Radeon on this server.
I figure my best bet is figure out when the last boot was and check
emerge.log to see what changed since then. Maybe something will pop
out and look likely.
Or, when I get to work and have a GUI again, google around some.
walt
> On Sun, Jul 05, 2009 at 08:25:53AM -0700, walt wrote:
>
>> I started getting the same 'expected keysym' messages recently but my
>> X continues to work okay anyway, so I think that's a red herring.
>
> Everything else works, just the keyboard is hosed, and those keysym
> messages sure seem suspiciously coincidental.
Yes, I was worried the first time I saw them (just a few days ago) but
on my system they seem harmless.
> I did remerge things, and it made no apparent difference.
>
>> You should have a /usr/lib/xorg/modules/extensions/libdri.so -- that's the dri
>> module that your X can't find. It's a symlink on my machine because I have
>> both the xorg and nvidia versions of opengl on my machine. The 'eselect opengl'
>> function is what creates the symlink to the correct version of libdri.so.
>
> I have no libdri.so anywhere on my system. Eselect shows nvidia and
> xorg-x11; I tried both, it did change some symlinks, but never created
> one for libdri.so...
I'd be more worried about this than the keysym errors. I have xorg-server-1.6.1.902
which installs these two (and of course much more):
/usr/lib64/opengl/xorg-x11/extensions/libdri.so
/usr/lib64/opengl/xorg-x11/extensions/libdri2.so
When I use eselect to set the opengl version to xorg-x11, it sets a symlink:
/usr/lib/xorg/modules/extensions/libdri.so -> /usr/lib64/opengl/xorg-x11/extensions/libdri.so*
If you don't have these libs and links then I'd say as your first chore you should
figure out why they're missing.
Roy Wright
I have no libdri.so anywhere on my system. Eselect shows nvidia andxorg-x11; I tried both, it did change some symlinks, but never createdone for libdri.so...
I'd be more worried about this than the keysym errors. I have xorg-server-1.6.1.902
which installs these two (and of course much more):
/usr/lib64/opengl/xorg-x11/extensions/libdri.so
/usr/lib64/opengl/xorg-x11/extensions/libdri2.so
When I use eselect to set the opengl version to xorg-x11, it sets a symlink:
/usr/lib/xorg/modules/extensions/libdri.so -> /usr/lib64/opengl/xorg-x11/extensions/libdri.so*
If you don't have these libs and links then I'd say as your first chore you should
figure out why they're missing.
walt
Interesting link, thanks. I see that for some ATI cards kernel support
is needed, as you say. It doesn't seem to involve nvidia cards though.
because nvidia has their own kernel modules.
Now that you got me thinking, I notice that I have the dri USE flag set
in make.conf, so that might be a consideration too.
fe...@crowfix.com
The DRM options were set in the kernel config. I started a make, but
it won't do me any good until the end of the weeke when I get a chance
to try that machine again. I also have dri in make.conf.
Thanks for all your help. I'll try again end of the week and see what
happens.
Zheng Guoqiang
fe...@crowfix.com
> the beginning of the X log. Unfortunately, I didn't save the previous
> working log. This is ~amd64 under 2.6.30-gentoo-r1 and -r2.
I tried many things, eventually got desperate and unmerged every X
package, then remerged everything. Basically made a list by
cd /usr/portage
ls x11*/* >/tmp/xwoes
edited that to remove the metadata etc, ran
emerge -C `cat /tmp/xwoes` >/tmp/xwoes-log 2>&1
edited that to collect only the ones that had actually been unmerged,
and remerged all those.
I have no idea what was broken, but it is working again. The only
truly annoying hiccup other than the time and hassle was having to
temporarily remerge emacs with no GUI support, then having to remerge
again after. The same probably applies to vim, but I use nvi or one
of the other "true" vi clones, not the bloated pretender :-) When I
want light and fast, I want light and fast, not emacs with modal crap.
I may have been wrong about the "dri" complaint being unimportant and
the "expected keysym, got XF86Battery: line 59 of inet" lines being
significant. The "dri" complaint is gone but the keysym complaints
remain. But I do not know with any certainty what either complaint
really meant, whether either one was really a problem, or whether
either one is now really fixed.
It's running xorg 1.6.2 if anybody cares :-)
What a pain.