# keyboard looses light [SOLVED]

## freifunk_connewitz

hi,

for a year now, I'm using a Logitech Illuminated Keyboard via USB. It has a decent backlight you can adjust with a special key.

everything (except some of the function keys) worked fine until recently. I really can't reconstruct what triggered the new behaviour (xorg-server or any other update, the plugging of a faulty USB HDD...), but for a while now the keyboard performs some kind of unsolicited power save: 3 sec after the last keystroke it switches off the backlight. this can be really annoying when working in a dark room.

I did sort of an elimination of error procedure:

- it's not the keyboard hardware that broke: tried the keyboard with another linux computer (running ubuntu), worked fine there

- it's not the USB port hardware of my PC: when I fire up VMWare Player and click in that window, the light stays ON

so I assume it must be the keyboard driver or something connected, right? 

does anybody have an idea what could cause this nasty little problem? xorg-server or -driver? hal? udev? some kernel driver?

I'm running KDE on xorg-1.8.2, here's my config:

 *Quote:*   

> 
> 
> # emerge --info
> 
> Portage 2.1.8.3 (default/linux/amd64/10.0/desktop/kde, gcc-4.3.4, glibc-2.11.2-r0, 2.6.34-gentoo-r6 x86_64)
> ...

 

 *Quote:*   

> 
> 
> # eix xorg-server
> 
> [I] x11-base/xorg-server
> ...

 

(hal useflag deactivated via package.use)

 *Quote:*   

>  # eix xorg-driver
> 
> [I] x11-base/xorg-drivers
> 
>      Available versions:  1.6 1.7 (~)1.8 {input_devices_acecad input_devices_aiptek input_devices_citron input_devices_elographics input_devices_evdev input_devices_fpit input_devices_hyperpen input_devices_joystick input_devices_keyboard input_devices_mouse input_devices_mutouch input_devices_penmount input_devices_synaptics input_devices_tslib input_devices_virtualbox input_devices_vmmouse input_devices_void input_devices_wacom video_cards_apm video_cards_ark video_cards_ast video_cards_chips video_cards_cirrus video_cards_dummy video_cards_epson video_cards_fbdev video_cards_fglrx video_cards_geode video_cards_glint video_cards_i128 video_cards_i740 video_cards_impact video_cards_intel video_cards_mach64 video_cards_mga video_cards_neomagic video_cards_newport video_cards_nouveau video_cards_nv video_cards_nvidia video_cards_r128 video_cards_radeon video_cards_radeonhd video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_sunbw2 video_cards_suncg14 video_cards_suncg3 video_cards_suncg6 video_cards_sunffb video_cards_sunleo video_cards_suntcx video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_via video_cards_virtualbox video_cards_vmware video_cards_voodoo video_cards_xgi}                                                               
> ...

 

I have no xorg.conf anywhere.Last edited by freifunk_connewitz on Fri Sep 24, 2010 8:37 am; edited 4 times in total

----------

## BradN

Does the problem still occur when not running X?

----------

## adramalech707

i forget because i am running a `amd64 build but aren't u suppose to move to udev?? i think it might alleviate ur issue...because soon hal is going bye bye and everyone will need to migrate to udev....which suxs because half of my packages still have hal as a depends to run....meaning they haven't recoded for udev.... like my thunar volume manager doesn't work well without hal....but i believe u cannot run hal and udev on the same system or u might have issues where hal and udev are both running and trying to do the same thing...

http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml

it specifically states...

 *Quote:*   

> 
> 
> Xorg can detect input devices using udev, deprecating its HAL support. Users are strongly encouraged to migrate to udev. 
> 
> Enabling udev just requires building xorg-server with USE="udev
> ...

 

----------

## BradN

HAL and udev can both be on the same system, but probably you want the programs using one or the other (preferably udev if hal is going the way of the dinosaurs)

----------

## freifunk_connewitz

thanks for your replies!

BradN,

when I encounter the problem, it persists too if I switch to the console via ctr-alt-F[1-5]. 

EDIT: also if I stop X from console and stay in console: same effect.

adra,

as Brad said, hal and udev can reside on the same system. until yesterday my xorg-server even was running with hal and udev USE-flag at the same time (then I remerged it with -hal).

BTW, during the first minutes of my X session the light is working normal.

----------

## BradN

Ok, then it seems this is somehow related to the kernel, but it would be good to remove xdm from startup, shut down, disconnect and reconnect keyboard, then boot up only to the text prompt and see if the keyboard still does it (this way we know X had no chance to configure something on it, or even to change a configuration in the input layer of the kernel).

If the problem still persists, you have the option of tracking down what kernel version initially exhibits the problem (there is a procedure called a bisection test where you must download and compile and test 10 or so kernels to narrow down exactly what change introduced the problem).  It's a pain to wait for it all to compile but it enables you to make a much better bug report to the developers, and you will have a better chance of the problem being fixed.

A workaround might be turning off the full usb HID input driver and using the boot protocol usb input driver (this may not be an option if you use joysticks or other unusual usb input devices) - this interfaces with keyboards/mice in a simpler transmission mode that might not exhibit the same issue.

Or the "money is no obstacle" solution, just buy a different keyboard and use this one on another system  :Smile: 

----------

## Hu

As a related test, since you see the problem with a USB keyboard, try using a PS/2 keyboard instead.  This should tell us whether the problem is related to USB or to something playing with keyboard settings.

----------

## Etal

Hmm... If you have it, try increasing the value of /sys/module/usbcore/parameters/autosuspend and see if it does anything.

----------

## BradN

 *Hu wrote:*   

> As a related test, since you see the problem with a USB keyboard, try using a PS/2 keyboard instead.  This should tell us whether the problem is related to USB or to something playing with keyboard settings.

 

This problem is related to the keyboard's backlight and probably he doesn't have a PS/2 version of the same.  The keyboard works fine, but its backlight is turning off when it's wanted to stay on.  If the keyboard came with a USB->PS/2 adapter, it's worth a shot trying that.

----------

## freifunk_connewitz

thanks a lot for your help and apologies for me not answering for so long (have been away from my computer for a week).

the situation is in a way both trickier and easier now: the keyboard works again as expected without me having changed anything. all that has changed since last week is that x-server and -drivers have been updated to 1.9.0.

if the problem occurs again, I will have a closer look on the possible trigger and try your advices.

thanks again!

----------

## freifunk_connewitz

and here we go:

happened again, and now at least the trigger is somehow tracked down. the keyboard showed the weird backlighting behaviour again after I plugged in an USB HDD. and now I remember: like it was the last time. logging out/in or switching to console didn't help. then, I did like Brad suggested and removed xdm from default runlevel, shutdown, switched off, un-/replugged keyboard, switched on and restarted into the console: still, keyboard switched off its backlight 2 seconds after the last keystroke, already during the boot process. didn't change when I started xdm again. 

BUT, and here it seems like X (or KDE) has a rather positive influence on the whole thing: at a certain point of the KDE starting process (after logging in in kdm and quite at the end, when the splash screen disappears and the desktop shows up) the backlight smoothly came back without having touched any key! but unfortunately, after some time, between 10 seconds and several minutes, in most cases it falls back to the weird behaviour and switches the light off.

it obviously is a kernel related issue - I am running 2.6.34-gentoo-r6 now that I'm having the problems. as a test I just booted into the last kernel that is still installed on my system (2.6.34-gentoo-r1). and: with that version the backlight stayed on all the time, also during boot or anytime within the console. so there must have been some changes in the USB system between 2.6.34-r1 and -r6. 

about bisection tests: the problem is that no kernel versions between -r1 and -r6 are in the portage tree, according to eix. and BradN, do you think kernel maintainers will bother to dig into this even if it is about a piece of hardware the manufacturer officially offers only Windoze support for? (BTW: shame on Logitech to build such an almost perfect keyboard and ignoring compatibility issues.)

best,

----------

## aCOSwt

This is definitely a 2.6.34-r6 bug. Many USB HID devices get into trouble with this version in various ways.

https://forums.gentoo.org/viewtopic-t-844438-start-0-postdays-0-postorder-asc-highlight-.html

(follow the link in the last post for the explanation)

You should go with at least 2.6.34-r7 and considering miscellaneous security patches commited since, 2.6.34-r10 is a better choice.

----------

## BradN

Unfortunately you need access to a git tree to do the bisection test, which probably means you have to duplicate the problem in the vanilla kernels (there's a git server for vanilla kernel.org).

It actually traces the problem not just to a certain release, but to the actual commit (single change or set of changes) that causes it.

Kernel maintainers care about anything that makes hardware misbehave, especially if it was already working in a past version, even if the manufacturer doesn't support it.

----------

## freifunk_connewitz

aCOSwt,

you are right - installed kernel 2.6.34-r10 and the problem disappeared. thanks to all for your hints. setting it to finally solved now.

----------

