By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1834

Summary:	tdekbdledsync clashes with standard XKB grp_led options and contributes to battery drain.
Product:	TDE	Reporter:	Pavel Pisa <ppisa4lists>
Component:	tdebase	Assignee:	Michele Calgaro <michele.calgaro>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	bugwatch, fatzer2, kb9vqf, michele.calgaro, ppisa4lists, russell, slavek.banko
Priority:	P5
Version:	R14.0.x [Trinity]
Hardware:	All
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Bug Depends on:
Bug Blocks:	3060

Description Pavel Pisa 2014-01-19 17:06:48 CST

It seems that /opt/trinity/bin/tdekbdledsync process is started by tdm_greet unconditionally. When KBD LED behavior is defined by system wide XKB configuration - i.e. /etc/default/keyboard file on Debian to something like

XKBOPTIONS="grp:switch,grp:alt_shift_toggle,grp_led:scroll"

then tdekbdledsync daemon resets LEDs to it wants even if individual TDE XKB and TSAK options are disabled.

The tdekbdledsync is one of major sources of unnecessary wakeup during computer idle according to the powertop as well.

So it is highly desirable to have option to disable its automatic start.

It seems that tdekbdledsync daemon start is controlled by boolean variable "trinity_desktop_synchronize_keyboard_lights" in http://git.trinitydesktop.org/cgit/tdebase/tree/tdm/kfrontend/kgapp.cpp but I have not found if it is possible to change initial true state by some configuration option.

It would be great if it can be at least disabled by option. I have used symlink to /bin/true as workaround for now.

Comment 1 Timothy Pearson 2014-01-19 17:45:56 CST

This daemon was introduced to fix long-standing Bug 427 which affects multiple desktop environments.  The root cause is some sort of bug in Xorg that has not been fixed for many, many years despite repeated attempts to do so.

It would seem reasonable to allow configuration of the daemon in two ways:
1.) Disable the daemon entirely, but with a strong warning that Bug 427 will resurface if the daemon is disabled
2.) Adjust the daemon polling interval.  Effectively, this would adjust the maximum amount of time the keyboard could remain in an inconsistent state.  Reasonable values would be from 1 to 30 seconds, with Bug 427 essentially resurfacing if the delay is set much longer than 30 seconds.

Comment 2 Russell Brown 2019-01-25 11:34:32 CST

I have another use-case where tdekbdledsync fails.

We run a 'traditional' setup with a big powerful server in the middle and 'dumb' x-terminals connecting to it via XDMCP.

tdekbdledsync ends up trying to control the LEDs on the main server's keyboard and not the ones on the remote terminals... so every logged in user has tdekbdledsync opening /dev/ttyX and /dev/input/eventX on the main server.

I don't know if tdekbdledsync can determine if the DISPLAY is remote, and if so ignore it, but if it can't, an 'official' way of disabling tdekdbledsync other than employing rm would be nice.

Comment 3 Pavel Pisa 2019-01-25 12:29:24 CST

Because my XKB global setting is good enough for me, I solve the problem by renaming daemon executable

mv /opt/trinity/bin/tdekbdledsync /opt/trinity/bin/tdekbdledsync-off

and then I am happy with Trinity as it is. There is no problem if executable is not present. But option to control the trinity_desktop_synchronize_keyboard_lights variable would be nice.

Comment 4 Slávek Banko 2019-01-27 13:00:12 CST

I think we can proceed in three steps to solve this problem:

1. Change tdm_greet to make tdekbdledsync not run on remote terminals.

2. Add an option to a configuration file that allows to set the trinity_desktop_synchronize_keyboard_lights value - so far without the GUI.

3. Add a GUI for the trinity_desktop_synchronize_keyboard_lights option.

Steps 1 and 2 would be good if we could get them into R14.0.6. Step 3 then to R14.1.0.

Comment 5 Slávek Banko 2019-02-28 14:29:40 CST

Step 1 is resolved in commits c80e5d45 (master) and 5b65df75 (r14.0.x).

Comment 6 Michele Calgaro 2020-02-07 08:05:11 CST

Step 2 and 3 solved in commit be1c4f22 (R14.1) and d008372a (R14.0).