Fedora 10 laptop keyboard problem

[Anger]

Hi
I have fedora 10 in my laptop (Dell Vostro 1310). When the boot process finish the keyboard and the touchpad don't work. But if i reboot the laptop in windows and then reboot in fedora the keyboard an the touchpad start working.
Anyone have an idea what is the problem?
Thank

[balkrishna]

I am facing the same problem . Please can someone from Dell comment on the same

[pedromatiello]

There is a bugzilla record against this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=474357

I have a Dell Vostro 1310 also. Same issue.

Perhaps some of you could help the devs with some more information.

[Arka]

try booting with acpi=off that wrkd fr me... gudluck!

[YL_tbird]

I installed the FC10 on a Dell Inspiron 1100 with intel 810 gfx and was able to get X working with the xorg.conf by adding the line:

Option "AccelMethod" "XAA"

to the device section. I had to use the "Driver intel". The keyboard works fine in single user mode but after startx the mouse works but not the keyboard. Tried a USB keyboard with no luck. After going back to single user the keyboard works again. Has anyone seen a way to key X from stealing the KB resource needed to work? Using the standard xorg.conf keyboard mouse section.

acpi=off results in no display starting X

[gonev]

Hi
I have the same problem with my Fedora 10 !?
acpi=off options used to boot the kernel does not work.

My /etc/sysconfig/keyboard is...
KEYBOARDTYPE="pc"
#KEYTABLE="us-acentos"
KEYTABLE="us"
LAYOUT="us"
MODEL="pc104"
OPTIONS=""
VARIANT="intl"

Regards

[Library Eye]

I'm having similar problems on my compaq in Fedora 10 x86_64- sometimes on startup or after a sleep the "mouse" buttons on trackpad don't work- nor will buttons on an actually attached mouse. i have to reboot…

[kquizak]

same problem here (keyboard does not work after startx) ... Any workaround in xorg.conf for this?

[FeRDNYC]

I can't help with this directly (don't have said laptop), but I suspect a determined individual may be able to at least isolate the problem with your unrecognized input devices using a combination of the X server logs (at /var/log/Xorg.0.log, for the first/only session logged in through gdm) and the xinput command.

For example, on my Acer desktop, the X server log contains messages pertaining to the discovery of each input device available to it via evdev, as they're configured. (I've included a complete listing of the relevant lines at the end of this post, a it's quite long and would interrupt the flow to include it here.)

For any devices the server has CORRECTLY recognized (working or otherwise), the command 'xinput' can be used to examine and even test their configuration and functionality.

For the desktop session which produced the log messages included farther down, 'xinput' provides me with a (mercifully) more concise inventory of what input devices are available to interact with the X server:

% xinput list --short
"Virtual core keyboard"	id=0	[XKeyboard]
"Virtual core pointer"	id=1	[XPointer]
"Microsoft Microsoft Wireless Optical Desktop? 2.10"	id=2	[XExtensionKeyboard]
"SOLID YEAR SOLIDYEAR USB"	id=3	[XExtensionKeyboard]
"Power Button (CM)"	id=4	[XExtensionKeyboard]
"Acer IR  Receiver"	id=5	[XExtensionKeyboard]
"Power Button (FF)"	id=6	[XExtensionKeyboard]
"Macintosh mouse button emulation"	id=7	[XExtensionPointer]
"Microsoft Microsoft Wireless Optical Desktop? 2.10"	id=8	[XExtensionKeyboard]
"SOLID YEAR SOLIDYEAR USB"	id=9	[XExtensionPointer]

If I want to get information on what events a particular device can generate, I'll select one and get the full detail:

% xinput list 8
"Microsoft Microsoft Wireless Optical Desktop? 2.10"	id=8	[XExtensionKeyboard]
	Num_keys is 248
	Min_keycode is 8
	Max_keycode is 255

...That'll be the my Microsoft wireless keyboard, which is identified and attached as a device generating keyboard events. (Which doesn't mean it has 248 keys, or that evdev THINKS it does. The input device is set up able to handle UP TO 248 distinct key symbols (and 7 modifiers) -- both far more than this keyboard requires, so we're fine.)

Another device:

% xinput list 2
"Microsoft Microsoft Wireless Optical Desktop? 2.10"	id=2	[XExtensionKeyboard]
	Num_keys is 248
	Min_keycode is 8
	Max_keycode is 255
	Num_buttons is 32
	Num_axes is 2
	Mode is Relative
	Motion_buffer is 256
	Axis 0 :
		Min_value is -1
		Max_value is -1
		Resolution is 1
	Axis 1 :
		Min_value is -1
		Max_value is -1
		Resolution is 1

That's the corresponding wireless MOUSE, on the same receiver (hence the identical device description) -- it's allowed to send keyboard events as well (and also lists itself as a "XExtensionKeyboard" type device, for the sake of confusion) since many mice now have features with "media key"-type properties ("Back" and "Forward" browsing controls, etc), but additionally it can deliver motion on the traditional two mouse axes (X and Y), and can generate up to 32 _MOUSE_ "button" events. (Which are different than "Back"-key "buttons", they're the actual button functions of the pointing device. Technically anything but X/Y motion on a mouse is a button, even scrolling -- after the 3 major buttons (L,R,M), each spin of the scroll wheel up/down is a press of button 4 or 5, then horizontal scrolling and thumb buttons, etc... Which is all somewhat interesting, and explains the generous allocation of 32 "BUTTON" inputs, but for right now all those details are largely unimportant.)

What *IS* important is that 'xinput' can also be used to INSPECT the communication between each input device and the input system. If everything is working properly, then when I issue an 'xinput test 2' command (passing the id#, 2, of my wireless mouse), then fiddling with that mouse should produce output like:

% xinput test 2
motion a[0]=636 a[1]=634 
motion a[0]=637 a[1]=633 
motion a[0]=638 a[1]=632 
motion a[0]=638 a[1]=631 
motion a[0]=639 a[1]=630 
motion a[0]=639 a[1]=629 
motion a[0]=641 a[1]=627 
motion a[0]=643 a[1]=625 
motion a[0]=649 a[1]=619 
button press   1 
button release 1 
button press   3 
motion a[0]=614 a[1]=630 
button release 3 
motion a[0]=574 a[1]=622 
motion a[0]=573 a[1]=622 
motion a[0]=572 a[1]=621 
button press   1 
button release 1 
button press   5 
button release 5 
button press   4 
button release 4

The really important (and useful) point to all this is that *ONLY* events from the SPECIFIC input device being tested will show up. No matter what I do to the wired mouse that's ALSO attached to this computer (input device id#9 -- it's connected to a PS/2 port on my "SOLID YEAR" USB keyboard, for extra wackiness), or any other input device, only events from the Microsoft Wireless Desktop receiver's mouse component will register under 'xinput test 2'. Similarly, 'xinput test 9' would only respond to events from the wired mouse.

So, using the device-specific inspection and testing functionality of the 'xinput' command, it SHOULD be possible to identify the input device configuration of your laptops' touchpad, when it IS working, and then compare that to how things look when it's NOT working. That should hopefully at least point the way to the location of the problem.

FIXING whatever's getting messed up is another matter -- 'xinput' isn't actually a tool for performing input-device configuration. (It has some settings-related commands, but don't let that fool you -- I doubt they'd have any effect with a totally non-functioning device.) Whatever adjustments are necessary to the device configuration would have to be made via .fdi files in the HAL configuration.

I don't have a very good understanding of HAL configuration, or writing custom .fdi file definitions -- thankfully I haven't had to delve that far into this stuff yet. But anyone who's pinpointed the issues with your laptop's input device configuration and wants to learn how to make the necessary fixes in HAL may find the following blog postings helpful:

http://who-t.blogspot.com/2008/07/in...-nutshell.html
http://who-t.blogspot.com/2008/10/ne...-handling.html
http://who-t.blogspot.com/2008/07/in...roperties.html
http://who-t.blogspot.com/2008/12/ev...other-fud.html

...Just a bunch of stuff I've stumbled into over the past few months, hope it's useful/enlightening! Good luck getting the problem sorted out!

-FeRD

(As promised, the -- long -- server log output follows. ...Actually, I got hit with the post-length limit, I'll include it as an attachment; it's not really necessary to look at the server logs, just a possibly-interesting point of comparison vs. what's shown via 'xinput', in discovering how this stuff all fits together.)

[FeRDNYC]

Attachment-posting seems to be silently failing for me, so here's what I was trying to upload:

# Selected lines from /var/log/Xorg.0.log on FeRD's desktop box.
# (Items relevant to input-device discovery and configuration)
#
# 
# (Note: there would be MANY other messages in addition to, and
# indeed intermixed with, what I've reproduced here. Also, many of 
# these messages are IRRELEVANT or spurious -- "Macintosh mouse emulation"
# is always there and should be ignored, my machine DOESN'T actually have
# an IR receiver, etc... any "phantom" devices are generally best
# disregarded and left alone, messing with them is unlikely to affect
# the functionality of other devices (one of the great things about
# evdev). Those lines are only included here to demonstrate the strong
# correlation between the server log output and what's available through
# the xinput tool, since they're effectively showing the same information.)
#
(II) Cannot locate a core pointer device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.
(WW) Disabling Keyboard0
(II) config/hal: Adding input device Microsoft Microsoft Wireless Optical Desktop? 2.10
(II) LoadModule: "evdev"

(II) Loading /usr/lib64/xorg/modules/input//evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 2.1.3
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.1
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: always reports core events
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: Device: "/dev/input/event6"
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Found 6 mouse buttons
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Found x and y relative axes
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Found x and y absolute axes
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Found keys
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Configuring as mouse
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Configuring as keyboard
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: YAxisMapping: buttons 4 and 5
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Microsoft Microsoft Wireless Optical Desktop? 2.10" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device SOLID YEAR SOLIDYEAR USB
(**) SOLID YEAR SOLIDYEAR USB: always reports core events
(**) SOLID YEAR SOLIDYEAR USB: Device: "/dev/input/event3"
(II) SOLID YEAR SOLIDYEAR USB: Found keys
(II) SOLID YEAR SOLIDYEAR USB: Configuring as keyboard
(II) XINPUT: Adding extended input device "SOLID YEAR SOLIDYEAR USB" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Power Button (CM)
(**) Power Button (CM): always reports core events
(**) Power Button (CM): Device: "/dev/input/event1"
(II) Power Button (CM): Found keys
(II) Power Button (CM): Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button (CM)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Acer IR  Receiver
(**) Acer IR  Receiver: always reports core events
(**) Acer IR  Receiver: Device: "/dev/input/event7"
(II) Acer IR  Receiver: Found 1 mouse buttons
(II) Acer IR  Receiver: Found keys
(II) Acer IR  Receiver: Configuring as keyboard
(**) Acer IR  Receiver: YAxisMapping: buttons 4 and 5
(**) Acer IR  Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Acer IR  Receiver" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Power Button (FF)
(**) Power Button (FF): always reports core events
(**) Power Button (FF): Device: "/dev/input/event0"
(II) Power Button (FF): Found keys
(II) Power Button (FF): Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button (FF)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Macintosh mouse button emulation
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event2"
(II) Macintosh mouse button emulation: Found 3 mouse buttons
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Configuring as mouse
(**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
(**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) config/hal: Adding input device Microsoft Microsoft Wireless Optical Desktop? 2.10
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: always reports core events
(**) Microsoft Microsoft Wireless Optical Desktop? 2.10: Device: "/dev/input/event5"
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Found keys
(II) Microsoft Microsoft Wireless Optical Desktop? 2.10: Configuring as keyboard
(II) XINPUT: Adding extended input device "Microsoft Microsoft Wireless Optical Desktop? 2.10" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105+inet"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device SOLID YEAR SOLIDYEAR USB
(**) SOLID YEAR SOLIDYEAR USB: always reports core events
(**) SOLID YEAR SOLIDYEAR USB: Device: "/dev/input/event4"
(II) SOLID YEAR SOLIDYEAR USB: Found 3 mouse buttons
(II) SOLID YEAR SOLIDYEAR USB: Found x and y relative axes
(II) SOLID YEAR SOLIDYEAR USB: Configuring as mouse
(**) SOLID YEAR SOLIDYEAR USB: YAxisMapping: buttons 4 and 5
(**) SOLID YEAR SOLIDYEAR USB: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "SOLID YEAR SOLIDYEAR USB" (type: MOUSE)

[eufordia]

I've a Dell Vostro 1510 and i've the same problem: sometime, after startup the keyboard and mouse of the laptop are dead.

I don't understand well what i can do with xinput. I can use this command only when all are ok(keyboard and mouse are on)... but maybe i don't understand at all!

did someone find a solution?

[FeRDNYC]

@eufordia: It's true that you wouldn't be able to use the laptop keyboard for testing, since the idea is to run commands to determine why it's in a failed state WHEN IT IS. I would suggest attaching a usb keyboard (and possibly mouse) to the laptop in order to test with xinput, sorry I didn't make that clear.

Granted, that's not a perfect setup -- since you're altering the very system you're trying to test just by plugging in that keyboard. (It's even possible that attaching a USB keyboard could make the PRIMARY laptop keyboard magically come to life; I've seen stranger things. That would seem lucky, but actually would be bad; it would prevent testing and diagnosis of the real underlying problem.) If attaching a keyboard after-the-fact does make the boot-failure problem harder to diagnose, you could try booting with it already attached, until you experience a main-keyboard-nonfunctional boot which you can then examine.

I thought about suggesting an SSH session from another computer, as another alternative. But since you're debugging x.org subsystems, not being attached to the local console would make it orders of magnitude more difficult to properly examine the input-device information. Or you'd have to jump through a bunch of extra hoops with setting $DISPLAY and possibly fiddling with xauth. Not worth it.

Good luck!

[ukaizen]

I have a vostro 1320 and the same problem .... I hope this can be fixed soon.

[ukaizen]

I found this Link in the Fedora forums: http://forums.fedoraforum.org/showthread.php?t=208269
After apply the line described in my grub.conf my Fedora 10 is more than alive