On Fri, Apr 17, 2009 at 14:46:58 +1000, Graham Williams wrote:
> Received Wed 15 Apr 2009 5:32am +1000 from Florian Kulzer:
> > On Tue, Apr 14, 2009 at 09:21:11 +1000, Graham Williams wrote:
> > > Received Fri 10 Apr 2009 6:31am +1000 from Florian Kulzer:
> > > > On Thu, Apr 09, 2009 at 18:10:41 +1000, Graham Williams wrote:
> > > > > Have just upgraded
> > > >
> > > > To what? Lenny, Squeeze, or Sid?
> > >
> > > >From etch to lenny, as per Subject.
[...]
> > > 07:00.0 VGA compatible controller [0300]: nVidia Corporation NV43GL
> > > [Quadro FX 550] [10de:014d] (rev a2)
[...]
> > Hmm, no real clues so far. I would like to see the status of certain
> > packages on your system. Please post the output of:
> >
> > dpkg -l udev {,lib}hal\* {,lib}dbus\* xserver-xorg\* libx11\* xkb\* | awk
> > '/ii/{print$2,$3}'
[ output edited ]
> udev 0.125-7
You should upgrade udev to version 0.125-7+lenny1 (security.debian.org).
> xserver-xorg-core 2:1.4.2-10
Rmadison tells me that the current version of this package for Lenny is
2:1.4.2-10.lenny1. I would try to upgrade to that.
Other than those two packages, I did not see anything unusual your list.
> > Another thing to check is which processes are using files in
> > /dev/input/. Ideally, this check should be done after X has started.
> > Using CTRL-ALT-Fn does not work for you, but you could use a simple
> > ~/.xinitrc that runs "sudo chvt 1" in an xterm, which would return you
> > to the text terminal. (You have to configure your system to allow your
> > user to run sudo with this command without password.) Then I would like
> > to the output of:
> >
> > lsof /dev/input/*
> >
> > (You have to run this command as root.)
>
> Nothing is listed.
I think there should be some output. (However, I run Sid and Xorg's
default handling of input devices changed recently, therefore I am not
entirely sure how this is supposed to be on Lenny.) In any case, I think
it is better to do the test like this:
lsof $(find /dev/input/)
Another thing to check is if certain processes are running:
ps -ef | grep -E 'X|hal|dbus|udev'
> Note that I am booting single user mode to do this, so it is logging
> in as root and running startx as root. I modified the .xinitrc to chvt
> 1 and to then xterm. I ran lsof on the console.
I think it would be better to do further tests in the normal runlevel.
I would temporarily uninstall or at least disable [xkg]dm to allow you
to log in at the normal tty prompt.
> I've been playing with xev, looks like it is getting KeyRelease events
> but not the KeyPress events for the keys that actually result in the
> screen resolution being reset. Without knowing how hal and the kbd
> device works, it is almost as if X is capturing these KeyPress events
> and not passing them on, instead treating them as a screen resolution
> change shortcut.
I think the capturing would be normal for real resolution-change key
combinations, but we have to figure out why your system misidentifies
other key press events as this combination.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
