Keyboard Input Vanishes Seconds After Loading GNOME

T

tmp

So far, I have
  1. Installed the FreeBSD v9.0 RELEASE operating system for the x86-64 platform
  2. Installed xorg
  3. Installed gnome2

In order to enable both the loading of xorg and gnome(2), I have edited my /etc/rc.conf file. Here is what cat reports:

Code: 
#cat /etc/rc.conf
hostname= "Mephisto"
ifconfig_re0="DHCP"
sshd_enable="YES"
moused_enable="YES"
#Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
hald_enable="YES"
dbus_enable="YES"
gnome_enable="YES"
gdm_enable="YES"

After entering in my password at the GNOME GDM login, I am able to get to my desktop and have access to my programs. However, if I were to open say Gedit and type for any period of time, my keyboard input will disappear and I will either be unable to type anything or it will infinitely type the last character I typed (e.g. the letter "k").

Has anyone else faced this situation and if so, how do I go about solving this?
 
New? Be sure you go through /etc/dbus SGML files can allow anyone to log in or, say, use your internet connection.
Code: 
dbus_enable="YES"
Or - don't expect the thing is secure ;)

If you haven't read all the code it isn't secure, though XSecurity is likely set up. Note I'm also "new" to FreeBSD.

Ok. You don't show much evidence this occurs. In fact you may just have a corrupted download, compile, or even the wrong keyboard configured (check the simplest things first). Also gnome has settings and macros for keys - so ensure you're not typing "magic sequences". Also note a smashed keyboard key (physical) can do this. Or even memory errors / overheadting. Tell me you don't plug and unplug a physical keyboard while the machine is on on an old PC.

Your clue is the application's edit widget gets keystokes from X (maybe indirectly through a gnome value added function). The "keys waiting" signal is received and when the buffer is read it always gets a 'k'. So that means all but the last key was read and removed from buffer, the last is 'stuck' and nothing new gets in. That's unusual / rare. Or even your libraries aren't properly installed. It's not a "usual problem" it's rare anyone gets that ever.

You say this happens in gedit, but what if you open xedit after or during the gedit session? Please say.

Try GnuStep desktop or what else and see if that has the same problem with other X editors (like xedit).

Yes, others work? Look into gnome, or for X's xmodmap (noting "xfree.org" changed some things and has some issues with gnome and messes up xmodmap - though keyconfig works).

No? Try changing keyboards (again, with PC off).

No? Maybe when you boot the wrong keymap is read - far before light.
 
You down with *BSD? Yah, you know me!

debguy said:
NEW? Be sure you go through /etc/dbus sgml files can allow anyone to log in or , say, use your internet connection. dbus_enable="YES". or - don't expect the thing is secure ;)
Click to expand...

Okay; I'm coming from a Debian GNU/Linux background, so FreeBSD's method of doing things is still somewhat new to me.

debguy said:
ok. you don't show much evidence this occurs. infact you may just have a corrupted download , compile , or even the wrong keyboard configured (check the simplest things first). also gnome has settings and macros for keys - so insure your not typing "magic sequences".
Click to expand...

I literally was typing "All work and no play makes Jack a dull boy." when the letter "k" was infinitely repeated.

debguy said:
also note a smashed keyboard key (physical) can do this. or even memory errors / overheadting. tell me you don't plug and unplug a physical keyboard while the machine is on on an old pc !
Click to expand...

No, I haven't. Also, this is an almost brand-new motherboard (AMD AM3) with an unlocked hex-core CPU. I don't believe the unlocked CPU would be the culprit.

debguy said:
your clue is the application's edit widget gets keystokes from X (maybe indirectly through a gnome value added function). the "keys waiting" signal is received adn when the buffer is read it always gets a 'k'. so that means all but the last key was read and removed from buffer, the last is 'stuck' and nothing new gets in.

That's unusual / rare.
Click to expand...

Hmm... That is definitely peculiar. I've safely restarted and logged in several times and keep either facing this problem or I cannot type at all following log-in.

debguy said:
Or even your libararies aren't properly installed. It's not a "usual problem" it's rare anyone gets that ever.
Click to expand...

In an odd way, I'll be happy if I stumbled upon a strange bug; learning how *BSD systems work and how to identify and fix bugs was the whole reason I installed FreeBSD in the first place :)

debguy said:
you say this happens in gedit, but what if you open xedit after or during the gedit session? please say.
Click to expand...

I know that when I attempt to use xterm I can't even type. Could this be because this error/bug/general sillyness is derived from an Xorg problem?

debguy said:
TRY GnuStep desktop or what else and see if that has the same problem with other X editors (like xedit).
Click to expand...

Can-do. I'll look up how to configure FreeBSD for said environment (I'm still so used to the "apt-get install..." method of doing things)

debguy said:
Yes others work? look into gnome, or for X's xmodmap (noting "xfree.org" changed some thigns (ughg!!!) and has some issues with gnome and messes up xmodmap - though keyconfig works)
Click to expand...

I just hope I can get this working; the whole reason I wanted GNOME was to recreate the Apple Mac OSX interface to troll my Apple using workmates.

debguy said:
No? try changing keyboards (again, with pc off)
Click to expand...
Should I try using an older PS/2 keyboard? I don't think I have any other USB keyboards around.
 
Yes, try a different keyboard. Some wireless keyboards and mice are problematic in particular. Also check xorg.conf for instances of AllowEmptyInput. There should be none.
 
wblock@ said:
Yes, try a different keyboard. Some wireless keyboards and mice are problematic in particular. Also check xorg.conf for instances of AllowEmptyInput. There should be none.
Click to expand...

Currently posting from my Debian GNU/Linux system; I've just verified this same issue with an older PS/2 keyboard. This time I was able to use DuckDuckGo (Google search alternative) once before I lost keyboard input. I am going to shutdown Debian GNU/Linux (it is running on the exact same hardware that FreeBSD is on; both operating systems have their own hard disks) and check out xorg.conf
 
wblock@ said:
Yes, try a different keyboard. Some wireless keyboards and mice are problematic in particular. Also check xorg.conf for instances of AllowEmptyInput. There should be none.
Click to expand...

I did not see any AllowEmptyInput in xorg.conf. Also, when I tried to start a vanilla session of x with startx, I could not use my PS/2 keyboard, and later, my USB keyboard. The weird part is that I can still hit keys such as Caps Lock, Num Lock or Scroll Lock, or even shut down the system with [CMD="ctrl"]alt delete[/CMD] and the system still reboots.
 
It's a problem within X, then. ctrl-alt-f1 should switch to a console. So either something is wrong with X or HAL, or there is something running that is eating keystrokes.

Ideas:

Install sysutils/bsdadminscripts, run pkg_libchk(1) to see if libraries are missing.
Disable all the Gnome stuff and start twm(1) to see if X is okay.
 
  • Thanks
Reactions: tmp
You must log in or register to reply here.
Back
Top